1. TDC561 Network Programming Camelia Zlatea, PhD Email: czlatea@cs.depaul.educzlatea@cs.depaul.edu Week 1: Course Introduction; Socket Application Programming Interface; Examples: C/C++ UNIX/Linux APIs

2. Network Programming (TDC561)Page 2 Winter 2003 TDC561 – Course Summary  Topics: –TCP/IP protocol suite –Socket programming; TCP and UDP sockets; Reliable UDP Communication; –Client-Server Models; –Socket options –Threads; concurrency; locking –Select calls –Non-Blocking I/O –IOCTL –ICMP –Broadcast/Multicast –Programming aspects related to network performance

3. Network Programming (TDC561)Page 3 Winter 2003 Objectives  Upon completion of this course, students will –have a good understanding of the TCP/UDP network programming interface –be able to develop client-server network applications on the Internet, based on UNIX/Linux –know how to apply methods for measuring and tuning the performance of network applications

4. Network Programming (TDC561)Page 4 Winter 2003 Prerequisites  TDC 463, CSC 309  C/C++ will be used to illustrate the concepts presented in the lecture material and for the implementation of the programming assignments and the project.  Basic understanding of UNIX / Linux operating system and programming environment

5. Network Programming (TDC561)Page 5 Winter 2003 Texts  Douglas Comer, David Stevens, Internetworking with TCP/IP : Client-Server Programming, Volume III (BSD Unix and ANSI C), 2nd edition, 1996 (ISBN 0-13-260969-X)  W. Richard Stevens, Network Programming : Networking API: Sockets and XTI, Volume 1, 2nd edition, 1997 (ISBN 0-13-490012-X)

6. Network Programming (TDC561)Page 6 Winter 2003 Other References  L.Peterson, B. Davie. Computer Networks: A System Approach. Morgan Kaufman, 2000. (ISBN 1-55860-514-2)  W. Stallings. Local and Metropolitan Area Networks. Prentice Hall,2000. (ISBN 0130129390)  W. Richard Stevens, Network Programming : Inter-process Communication, Volume 2, 2nd edition, 1999 (ISBN 0-13- 081081-9)  Robertazzi, Thomas G., Computer Networks and Systems - Queuing Theory and Performance Evaluation, second edition, Springer Verlag, 1994

7. Network Programming (TDC561)Page 7 Winter 2003 Class Work and Grading Programming Assignment 1 20% due by January 21 th Programming Assignment 2 20% due by February 4 rd Programming Assignment 3 20% due by February 18 th Programming Assignment 4 20% due by March 4 rd Final Project 20%due by March 18 th

8. Network Programming (TDC561)Page 8 Winter 2003 Programming Environment  All students will get an account on hawk.depaul.edu server (running HP-UX).  Optional, you can use Linux system  Project submissions via COL ( dlweb.cti.depaul.edu ) –use Submit Assignments link  Grading will be done on HP-UX or Linux –An experimental report is required for each programming project »The the report should include the program design description and the test cases and test scenarios for the application.

9. Network Programming (TDC561)Page 9 Winter 2003 TDC561 – Network Programming Instructor: Camelia Zlatea, PhD Office Hours: T 4:45-5:45PM; 9:00-9:30PM Where: Rm. 429, ext. x26149 (during office hours) Email: czlatea@cs.depaul.educzlatea@cs.depaul.edu Web: http://condor.depaul.edu/~czlatea/TDC561/ (*)http://condor.depaul.edu/~czlatea/TDC561/ Note: * In addition, course materials will be available from dlweb.cti.depaul.edu

10. Network Programming (TDC561)Page 10 Winter 2003 Class Communication  COL (dlweb.cti.depaul.edu) will be used primarily for: –Links to course materials/assignments –Grades –Announcements –Email/Communication –Newsgroup  Asking questions –Send me an email at czlatea@cs.depaul.edu ORczlatea@cs.depaul.edu –Use dlweb.cti.depaul.edu and post questions to class forum Anybody may reply (including your classmates) Everyone benefits from common issues

11. Network Programming (TDC561)Page 11 Winter 2003 Socket APIs C/C++ UNIX/Linux Systems Calls (APIs)

12. Network Programming (TDC561)Page 12 Winter 2003 References  Douglas Comer, David Stevens, Internetworking with TCP/IP : Client-Server Programming, Volume III (BSD Unix and ANSI C), 2nd edition, 1996 (ISBN 0-13-260969-X) –Chap. 3,4,5  W. Richard Stevens, Network Programming : Networking API: Sockets and XTI, Volume 1, 2nd edition, 1998 (ISBN 0- 13-490012-X) –Chap. 1,2,3,4  John Shapley Gray, Interprocess Communications in UNIX - - The Nooks and Crannies Prentice Hall PTR, NJ, 1998 –Chap. 10

13. Network Programming (TDC561)Page 13 Winter 2003 Client Server Communication  The transport protocols TCP and UDP were designed to enable communication between network applications Internet host can have several servers running. usually has only one physical link to the “rest of the world” When packets arrive how does the host identify which packets should go to which server? Ports ports are used as logical connections between network applications 16 bit number (65536 possible ports) demultiplexing key identify the application/process to receive the packet TCP connection source IP address and source port number destination IP address and destination port number the combination IP Address : Port Number pair is called a Socket

14. Network Programming (TDC561)Page 14 Winter 2003 Network Host 123.45.67.89 IP Network Network Host 122.34.45.67 Port 122.34.45.67: 65534 123.45.67.89:80 SOCKETS 1 2 3 80 81 82 65536 65535 65534 65533 79 78 1 2 3 80 81 82 65536 65535 65534 65533 79 78 Client Server Communication

15. Network Programming (TDC561)Page 15 Winter 2003 IP Host/ Server Port 1 2 3 80 81 82 65536 65535 65534 65533 79 78 Active Listening Active IP Network IP Host HTTP Server with three active connections (sockets). The HTTP server listens for future connections. Client Server Communication

16. Network Programming (TDC561)Page 16 Winter 2003 Ports  Port - A 16-bit number that identifies the application process that receives an incoming message.  Port numbers divided into three categories Well Known Ports0-1023 Registered Ports1024-49151 by the IANA (Internet Assigned Numbers Authority), and represent second tier common ports (socks (1080), WINS (1512), kermit (1649), https (443)) Dynamic/Private Ports49152-65535 ephemeral ports, available for temporary client usage  Reserved ports or well-known ports (0 to 1023) –Standard ports for well-known applications. –See /etc/services file on any UNIX machine for listing of services on reserved ports. 1TCP Port Service Multiplexer 20File Transfer Protocol (FTP) Data 21FTP Control 23Telnet 25Simple Mail Transfer (SMT) 43Who Is 69Trivial File Transfer Protocol (TFTP) 80HTTP

17. Network Programming (TDC561)Page 17 Winter 2003 Associations  A socket address is the triplet: {protocol, local-IP, local-port} –example, {tcp, 130.245.1.44, 23}  An association is the 5-tuple that completely specifies the two end- points that comprise a connection: {protocol, local-IP, local-port, remote-IP, remote-port} –example: {tcp, 130.245.1.44, 23, 130.245.1.45, 1024}

18. Network Programming (TDC561)Page 18 Winter 2003 Socket Domain Families  There are several significant socket domain families: –Internet Domain Sockets (AF_INET) »implemented via IP addresses and port numbers –Unix Domain Sockets (AF_UNIX) »implemented via filenames (similar to IPC “named pipe”)

19. Network Programming (TDC561)Page 19 Winter 2003 Creating a Socket #include int socket(int domain, int type, int protocol);  domain is one of the Protocol Families (AF_INET, AF_UNIX, etc.)  type defines the communication protocol semantics, usually defines either: –SOCK_STREAM: connection-oriented stream (TCP) –SOCK_DGRAM: connectionless, unreliable (UDP)  protocol specifies a particular protocol, just set this to 0 to accept the default

20. Network Programming (TDC561)Page 20 Winter 2003 The Socket Structure  INET Address struct in_addr { in_addr_t s_addr; /* 32-bit IPv4 address */ }  INET Socket Struct sockaddr_in { uint8_t sin_len; /* length of structure (16) */ sa_family_t sin_family; /* AF_INET */ in_port_t sin_port; /* 16-bit TCP/UDP port number */ struct in_addr sin_addr; /* 32-bit IPv4 address */ char sin_zero[8]; /* unused */ }

21. Network Programming (TDC561)Page 21 Winter 2003 Setup for an Internet Domain Socket struct sockaddr_in { sa_family_t sin_family; unsigned short int sin_port; struct in_addr sin_addr; unsigned char pad[...]; };  sin_family is set to Address Family AF_INET  sin_port is set to the port number you want to bind to  sin_addr is set to the IP address of the machine you are binding to (struct in_addr is a wrapper struct for an unsigned long)  ignore padding

22. Network Programming (TDC561)Page 22 Winter 2003 Stream Socket Transaction (TCP Connection) socket() connect() bind() listen() accept() socket() write() read() close() read() write() read()close() 3-way handshake EOF data Client Server

23. Network Programming (TDC561)Page 23 Winter 2003 Connection-oriented socket connections Client-Server view

24. Network Programming (TDC561)Page 24 Winter 2003 Server Side Socket Details Create socket bind a port to the socket SERVER listen for incoming connections accept an incoming connection read from the connection write to the connection int socket(int domain, int type, int protocol) sockfd =socket(AP_INET, SOCK_STREAM, 0); int bind(int sockfd, struct sockaddr *server_addr, socklen_t length) bind(sockfd, &server, sizeof(server)); int listen( int sockfd, int num_queued_requests) listen( sockfd, 5); int accept(int sockfd, struct sockaddr *incoming_address, socklen_t length) newfd = accept(sockfd, &client, sizeof(client)); /* BLOCKS */ int read(int sockfd, void * buffer, size_t buffer_size) read(newfd, buffer, sizeof(buffer)); int write(int sockfd, void * buffer, size_t buffer_size) write(newfd, buffer, sizeof(buffer));

25. Network Programming (TDC561)Page 25 Winter 2003 Client Side Socket Details Create socket CLIENT connect to Server socket read from the connection write to the connection int socket(int domain, int type, int protocol) sockfd =socket(AF_INET, SOCK_STREAM, 0); int connect(int sockfd, struct sockaddr *server_address, socklen_t length) connect(sockfd, &server, sizeof(server)); /* Blocking */ int read(int sockfd, void * buffer, size_t buffer_size) read(sockfd, buffer, sizeof(buffer)); int write(int sockfd, void * buffer, size_t buffer_size) write(sockfd, buffer, sizeof(buffer));

26. Network Programming (TDC561)Page 26 Winter 2003 Reading From and Writing To Stream Sockets  Sockets, are inter-process-communication mechanism, similar with files: –low level IO: »read() system call »write() system call –higher level IO: »int recv(int socket, char *buf, int len, int flags); blocks on read returns 0 when other connection has terminated »int send(int socket, char *buf, int len, int flags); returns the number of bytes actually sent »where flags may be one of: MSG_DONTROUTE (don’t route out of localnet) MSG_OOB (out of band data (causes interruption)) MSG_PEEK (examine, but don’t remove from stream)

27. Network Programming (TDC561)Page 27 Winter 2003 Closing a Socket Session  int close(int socket); –closes read/write IO, closes socket file descriptor  int shutdown( int socketfd, int mode); –where mode is: »0:no more receives allowed “r” »1:no more sends are allowed “w” »2:disables both receives and sends (but doesn’t close the socket, use close() for that) “rw”

28. Network Programming (TDC561)Page 28 Winter 2003 Byte Ordering  Different computer architectures use different byte ordering to represent/store multi-byte values (such as 16-bit/32-bit integers)  16 bit integer: Low Byte High Byte Low Byte Address A Address A+1 Little-Endian (Intel) Big-Endian (RISC-Sparc)

29. Network Programming (TDC561)Page 29 Winter 2003 Byte Order and Networking  Suppose a Big Endian machine sends a 16 bit integer with the value 2:  A Little Endian machine will understand the number as 512:  How do two machines with different byte-orders communicate? –Using network byte-order –Network byte-order = big-endian order 0000000000000010 0000001000000000

30. Network Programming (TDC561)Page 30 Winter 2003 Network Byte Order  Conversion of application-level data is left up to the presentation layer.  Lower level layers communicate using a fixed byte order called network byte order for all control data.  TCP/IP mandates that big-endian byte ordering be used for transmitting protocol information  All values stored in a sockaddr_in must be in network byte order. –sin_port a TCP/IP port number. –sin_addr an IP address.

31. Network Programming (TDC561)Page 31 Winter 2003 Network Byte Order Functions  Several functions are provided to allow conversion between host and network byte ordering,  Conversion macros ( ) –to translate 32-bit numbers (i.e. IP addresses): »unsigned long htonl(unsigned long hostlong); »unsigned long ntohl(unsigned long netlong); –to translate 16-bit numbers (i.e. Port numbers): »unsigned short htons(unsigned short hostshort); »unsigned short ntohs(unsigned short netshort);

32. Network Programming (TDC561)Page 32 Winter 2003 TCP Sockets Programming Summary  Creating a passive mode (server) socket.  Establishing an application-level connection.  send/receive data.  Terminating a connection.

33. Network Programming (TDC561)Page 33 Winter 2003 Creating a TCP socket int socket(int family,int type,int proto); int mysockfd; mysockfd = socket(AF_INET, SOCK_STREAM, 0); if (mysockfd<0) { /* ERROR */ }

34. Network Programming (TDC561)Page 34 Winter 2003 Binding to well known address int mysockfd; int err; struct sockaddr_in myaddr; mysockfd = socket(AF_INET,SOCK_STREAM,0); myaddr.sin_family = AF_INET; myaddr.sin_port = htons( 80 ); myaddr.sin_addr = htonl( INADDR_ANY ); err= bind(mysockfd, (sockaddr *) &myaddr, sizeof(myaddr));

35. Network Programming (TDC561)Page 35 Winter 2003 Bind – What Port Number?  Clients typically don’t care what port they are assigned.  When you call bind you can tell it to assign you any available port: myaddr.port = htons(0);

36. Network Programming (TDC561)Page 36 Winter 2003 Bind - What IP address ?  How can you find out what your IP address is so you can tell bind() ?  There is no realistic way for you to know the right IP address to give bind() - what if the computer has multiple network interfaces?  Specify the IP address as: INADDR_ANY, this tells the OS to handle the IP address specification.

37. Network Programming (TDC561)Page 37 Winter 2003 Converting Between IP Address formats  From ASCII to numeric –“130.245.1.44”  32-bit network byte ordered value –inet_aton(…) with IPv4 –inet_pton(…) with IPv4 and IPv6  From numeric to ASCII –32-bit value  “130.245.1.44” –inet_ntoa(…) with IPv4 –inet_ntop(…) with IPv4 and IPv6 –Note – inet_addr(…) obsolete »cannot handle broadcast address “255.255.255.255” (0xFFFFFFFF)

38. Network Programming (TDC561)Page 38 Winter 2003 IPv4 Address Conversion int inet_aton( char *, struct in_addr *); Convert ASCII dotted-decimal IP address to network byte order 32 bit value. Returns 1 on success, 0 on failure. char *inet_ntoa(struct in_addr); Convert network byte ordered value to ASCII dotted-decimal (a string).

39. Network Programming (TDC561)Page 39 Winter 2003 Establishing a passive mode TCP socket  Passive mode: –Address already determined. –Tell the kernel to accept incoming connection requests directed at the socket address. »3-way handshake –Tell the kernel to queue incoming connections for us.

40. Network Programming (TDC561)Page 40 Winter 2003 listen() int listen( int mysockfd, int backlog); mysockfd is the TCP socket (already bound to an address) backlog is the number of incoming connections the kernel should be able to keep track of (queue for us). listen() returns -1 on error (otherwise 0).

41. Network Programming (TDC561)Page 41 Winter 2003 Accepting an incoming connection  Once we call listen(), the O.S. will queue incoming connections –Handles the 3-way handshake –Queues up multiple connections.  When our application is ready to handle a new connection, we need to ask the O.S. for the next connection.

42. Network Programming (TDC561)Page 42 Winter 2003 accept() int accept( int mysockfd, struct sockaddr* cliaddr, socklen_t *addrlen); mysockfd is the passive mode TCP socket. cliaddr is a pointer to allocated space. addrlen is a value-result argument –must be set to the size of cliaddr –on return, will be set to be the number of used bytes in cliaddr.  accept() return value –accept() returns a new socket descriptor (positive integer) or -1 on error. –After accept returns a new socket descriptor, I/O can be done using the read() and write() system calls.

43. Network Programming (TDC561)Page 43 Winter 2003 Terminating a TCP connection  Either end of the connection can call the close() system call.  If the other end has closed the connection, and there is no buffered data, reading from a TCP socket returns 0 to indicate EOF.

44. Network Programming (TDC561)Page 44 Winter 2003 Client Code  TCP clients can call connect() which: –takes care of establishing an endpoint address for the client socket. » don’t need to call bind first, the O.S. will take care of assigning the local endpoint address (TCP port number, IP address). –Attempts to establish a connection to the specified server. »3-way handshake

45. Network Programming (TDC561)Page 45 Winter 2003 connect() int connect( int sockfd, const struct sockaddr *server, socklen_t addrlen); sockfd is an already created TCP socket. server contains the address of the server (IP Address and TCP port number) connect() returns 0 if OK, -1 on error

46. Network Programming (TDC561)Page 46 Winter 2003 Reading from a TCP socket int read( int fd, char *buf, int max);  By default read() will block until data is available.  reading from a TCP socket may return less than max bytes (whatever is available).

47. Network Programming (TDC561)Page 47 Winter 2003 Writing to a TCP socket int write( int fd, char *buf, int num);  write might not be able to write all num bytes (on a nonblocking socket).  Other functions (API) –readn(), writen() and readline() - see man pages definitions.

48. Network Programming (TDC561)Page 48 Winter 2003 Example [ from R. Stevens text] Server Client Network Web browser and server FTP client and server Telnet client and server Machine B Machine A Client Server communication

49. Network Programming (TDC561)Page 49 Winter 2003 Example – Daytime Server/Client TCP MAC driver Daytime client IP Network TCP Daytime server IP MAC driver Application protocol (end-to-end logical connection) TCP protocol (end-to-end logical connection) IP protocol (physical connection ) MAC-level protocol (physical connection ) Actual data flow Socket API MAC = media access control

50. Network Programming (TDC561)Page 50 Winter 2003 #include "unp.h" int main(int argc, char **argv) { int sockfd, n; char recvline[MAXLINE + 1]; struct sockaddr_in servaddr; if( argc != 2 )err_quit(“usage : gettime ”); /* Create a TCP socket */ if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) err_sys("socket error"); /* Specify server’s IP address and port */ bzero(&servaddr, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_port = htons(13); /* daytime server port */ if (inet_pton(AF_INET, argv[1], &servaddr.sin_addr) <= 0) err_quit("inet_pton error for %s", argv[1]); Daytime client  Connects to a daytime server  Retrieves the current date and time % gettime 130.245.1.44 Thu Sept 05 15:50:00 2002

51. Network Programming (TDC561)Page 51 Winter 2003 /* Connect to the server */ if (connect(sockfd, (SA *) &servaddr, sizeof(servaddr)) < 0) err_sys("connect error"); /* Read the date/time from socket */ while ( (n = read(sockfd, recvline, MAXLINE)) > 0) { recvline[n] = 0; /* null terminate */ printf(“%s”, recvline); } if (n < 0) err_sys("read error"); close(sockfd); } Daytime client

52. Network Programming (TDC561)Page 52 Winter 2003 Simplifying error-handling [ R. Stevens ] int Socket(int family, int type, int protocol) { int n; if ( (n = socket(family, type, protocol)) < 0) err_sys("socket error"); return n; }

53. Network Programming (TDC561)Page 53 Winter 2003 #include "unp.h" #include int main(int argc, char **argv) { int listenfd, connfd; struct sockaddr_in servaddr; char buff[MAXLINE]; time_t ticks; /* Create a TCP socket */ listenfd = Socket(AF_INET, SOCK_STREAM, 0); /* Initialize server’s address and well-known port */ bzero(&servaddr, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr = htonl(INADDR_ANY); servaddr.sin_port = htons(13); /* daytime server */ /* Bind server’s address and port to the socket */ Bind(listenfd, (SA *) &servaddr, sizeof(servaddr)); Daytime Server  Waits for requests from Client  Accepts client connections  Send the current time  Terminates connection and goes back waiting for more connections.

54. Network Programming (TDC561)Page 54 Winter 2003 /* Convert socket to a listening socket */ Listen(listenfd, LISTENQ); for ( ; ; ) { /* Wait for client connections and accept them */ connfd = Accept(listenfd, (SA *) NULL, NULL); /* Retrieve system time */ ticks = time(NULL); snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks)); /* Write to socket */ Write(connfd, buff, strlen(buff)); /* Close the connection */ Close(connfd); } Daytime Server

55. Background Slides TCP/IP Protocol Suite - Terms and Concepts

56. Network Programming (TDC561)Page 56 Winter 2003 TCP/IP Summary  IP: network layer protocol –unreliable datagram delivery between hosts.  UDP: transport layer protocol - provides fast / unreliable datagram service. Pros: Less overhead; fast and efficient –minimal datagram delivery service between processes. –unreliable, since there is no acknowledgement of receipt, there is no way to know to resend a lost packet –no built-in order of delivery, random delivery –connectionless; a connection exists only long enough to deliver a single packet –checksum to guarantee integrity of packet data  TCP: transport layer protocol. Cons: Lots of overhead –connection-oriented, full-duplex, reliable, byte-stream delivery service between processes. –guaranteed delivery of packets in order of transmission by offering acknowledgement and retransmission: –sequenced delivery to the application layer, by adding a sequence number to every packet. –checksum to guarantee integrity of packet data

57. Network Programming (TDC561)Page 57 Winter 2003  Underlying best-effort network –drops messages –re-orders messages –delivers duplicate copies of a given message –limits messages to some finite size –delivers messages after an arbitrarily long delay  Common end-to-end services –guarantee message delivery –deliver messages in the same order they are sent –deliver at most one copy of each message –support arbitrarily large messages –support synchronization –allow the receiver to apply flow control to the sender –support multiple application processes on each host End-to-End (Transport) Protocols

58. Network Programming (TDC561)Page 58 Winter 2003 UDP Application process Application process Application process UDP Packets arrive Ports Queues Packets demultiplexed

59. Network Programming (TDC561)Page 59 Winter 2003 UDP  Simple Demultiplexor  Unreliable and unordered datagram service  Adds multiplexing  No flow control  Endpoints identified by ports –servers have well-known ports –see /etc/services on Unix  Optional checksum –pseudo header + udp header + data  UDP Packet Format Src Port AddressDst Port Address ChecksumLength of DATA DATA 01631 Header

60. Network Programming (TDC561)Page 60 Winter 2003 TCP  Reliable Byte-Stream  Connection-oriented  Byte-stream –sending process writes some number of bytes –TCP breaks into segments and sends via IP –receiving process reads some number of bytes  Full duplex  Flow control: keep sender from overrunning receiver  Congestion control: keep sender from overrunning network Application process Write bytes TCP Send buffer Segment Transmit segments Application process Read bytes TCP Receive buffer … ……

61. Network Programming (TDC561)Page 61 Winter 2003 TCP  Connection-oriented protocol logical connection created between two communicating processes connection is managed at TCP protocol layer provides reliable and sequential delivery of data receiver acknowledgements sender that data has arrived safely sender resends data that has not been acknowledged packets contain sequence numbers so they may be ordered  Bi-directional byte stream both sender and receiver write and read bytes acknowledgements identify received bytes buffers hold data until there is a sent multiple bytes are packaged into a segment when sent

62. Network Programming (TDC561)Page 62 Winter 2003 TCP End-to-End Issues Based on sliding window protocol used at data link level, but the situation is very different.  Potentially connects many different hosts –need explicit connection establishment and termination  Potentially different RTT (Round Trip Time) –need adaptive timeout mechanism  Potentially long delay in network –need to be prepared for arrival of very old packets  Potentially different capacity at destination –need to accommodate different amounts of buffering  Potentially different network capacity –need to be prepared for network congestion

63. Network Programming (TDC561)Page 63 Winter 2003 TCP Segment Format  Every TCP segment includes a Sequence Number that refers to the first byte of data included in the segment.  Every TCP segment includes an Acknowledgement Number that indicates the byte number of the next data that is expected to be received. –All bytes up through this number have already been received.  Control flags: –URG: urgent data included. –ACK: this segment is (among other things) an acknowledgement. –RST: error - abort the session. –SYN: synchronize Sequence Numbers (setup) –FIN: polite connection termination.  Window: –Every ACK includes a Window field that tells the sender how many bytes it can send before the receiver buffer will be in overflow

64. Network Programming (TDC561)Page 64 Winter 2003 Source Port NumberDestination Port Number Sequence Number Acknowledgement Hdr Len 0FlagsWindow ChecksumUrgent Pointer Options/Padding Data 01631 TCP Segment Format

65. Network Programming (TDC561)Page 65 Winter 2003 TCP Connection Establishment and Termination  When a client requests a connection it sends a “SYN” segment (a special TCP segment) to the server port.  SYN stands for synchronize. The SYN message includes the client’s SN.  SN is Sequence Number.

66. Network Programming (TDC561)Page 66 Winter 2003 SYN SN=X SYN SN=X Client Active Participant Server Passive Participant SYN SN=Y ACK=X+1 SYN SN=Y ACK=X+1 ACK=Y+1 1 2 3 TCP Connection Creation

67. Network Programming (TDC561)Page 67 Winter 2003 TCP 3-Way Handshake  A client starts by sending a SYN segment with the following information: –Client’s SN (generated pseudo-randomly) = X –Maximum Receive Window for client. –Only TCP headers  When a waiting server sees a new connection request, the server sends back a SYN segment with: –Server’s SN (generated pseudo-randomly) = Y –Acknowledgement Number is Client SN+1 = X+1 –Maximum Receive Window for server. –Only TCP headers  When the Server’s SYN is received, the client sends back an ACK with: –Acknowledgement Number is Server’s SN+1 = Y+1  Why 3-way? 1 2 3

68. Network Programming (TDC561)Page 68 Winter 2003 TCP Data and ACK  Once the connection is established, data can be sent.  Each data segment includes a sequence number identifying the first byte in the segment.  Each segment (data or empty) includes an acknowledgement number indicating what data has been received.

69. Network Programming (TDC561)Page 69 Winter 2003 TCP  Reliable Byte-Stream  Connection-oriented  Byte-stream –sending process writes some number of bytes –TCP breaks into segments and sends via IP –receiving process reads some number of bytes  Full duplex  Flow control: keep sender from overrunning receiver  Congestion control: keep sender from overrunning network Application process Write bytes TCP Send buffer Segment Transmit segments Application process Read bytes TCP Receive buffer … ……

70. Network Programming (TDC561)Page 70 Winter 2003 TCP Buffering  The TCP layer doesn’t know when the application will ask for any received data.  TCP buffers incoming data so it’s ready when we ask for it.  Client and server allocate buffers to hold incoming and outgoing data –The TCP layer does this.  Client and server announce with every ACK how much buffer space remains (the Window field in a TCP segment).  Most TCP implementations will accept out-of-order segments (if there is room in the buffer).  Once the missing segments arrive, a single ACK can be sent for the whole thing.

71. Network Programming (TDC561)Page 71 Winter 2003 TCP Buffering  Send Buffers –The application gives the TCP layer some data to send. –The data is put in a send buffer, where it stays until the data is ACK’d. –The TCP layer won’t accept data from the application unless (or until) there is buffer space.  ACK –A receiver doesn’t have to ACK every segment (it can ACK many segments with a single ACK segment). –Each ACK can also contain outgoing data (piggybacking). –If a sender doesn’t get an ACK after some time limit it resends the data.

72. Network Programming (TDC561)Page 72 Winter 2003 Termination  The TCP layer can send a RST segment that terminates a connection if something is wrong.  Usually the application tells TCP to terminate the connection gracefully with a FIN segment.  FIN –Either end of the connection can initiate termination. –A FIN is sent, which means the application is done sending data. –The FIN is ACK’d. –The other end must now send a FIN. –That FIN must be ACK’d.

73. Network Programming (TDC561)Page 73 Winter 2003 FIN SN=X FIN SN=X App1 App2 ACK=X+1 ACK=Y+1 1 2 4 FIN SN=Y FIN SN=Y 3... TCP Connection Termination

74. Network Programming (TDC561)Page 74 Winter 2003 Stream Sockets  Connection-Based, i.e., socket addresses established before sending messages between C/S  Address Domain: AF_UNIX (UNIX pathname) or AF_INET (host+port)  Virtual Circuit i.e., Data Transmitted sequentially in a reliable and non-duplicated manner  Default Protocol Interface is TCP  Checks order, sequence, duplicates  No boundaries are imposed on data (its a stream of bytes)  Slower than UDP  Requires more program overhead

75. Network Programming (TDC561)Page 75 Winter 2003 Datagram Sockets  Connectionless sockets, i.e., C/S addresses are passed along with each message sent from one process to another  Peer-to-Peer Communication  Provides an interface to the UDP datagram services  Handles network transmission as independent packets  Provides no guarantees, although it does include a checksum  Does not detect duplicates  Does not determine sequence –ie information can be lost, wrong order or duplicated