TDC 561 Network Programming Week 1 Course Introduction

TDC 561 Network Programming Week 1: Course Introduction; Socket Application Programming Interface; Examples: C/C++ UNIX/Linux APIs Camelia Zlatea, Ph. D Email: czlatea@cs. depaul. edu Distributed Systems Frameworks (DS 520 -95 -103) DISC’ 99

TDC 561 – 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 Network Programming (TDC 561) Winter 2003 Page 2

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 Network Programming (TDC 561) Winter 2003 Page 3

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 Network Programming (TDC 561) Winter 2003 Page 4

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

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, 2 nd edition, 1999 (ISBN 0 -13081081 -9) § Robertazzi, Thomas G. , Computer Networks and Systems Queuing Theory and Performance Evaluation, second edition, Springer Verlag, 1994 Network Programming (TDC 561) Winter 2003 Page 6

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

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. Network Programming (TDC 561) Winter 2003 Page 8

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

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 OR – Use dlweb. cti. depaul. edu and post questions to class forum • Anybody may reply (including your classmates) • Everyone benefits from common issues Network Programming (TDC 561) Winter 2003 Page 10

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

References § Douglas Comer, David Stevens, Internetworking with TCP/IP : Client-Server Programming, Volume III (BSD Unix and ANSI C), 2 nd edition, 1996 (ISBN 0 -13 -260969 -X) – Chap. 3, 4, 5 § W. Richard Stevens, Network Programming : Networking API: Sockets and XTI, Volume 1, 2 nd edition, 1998 (ISBN 013 -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 Network Programming (TDC 561) Winter 2003 Page 12

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 Network Programming (TDC 561) Winter 2003 Page 13

Client Server Communication Port 65536 65535 65534 65533 82 81 Network Host 123. 45. 67. 89 IP Network 80 79 82 81 80 79 Network Host 122. 34. 45. 67 78 78 SOCKETS 122. 34. 45. 67: 65534 3 2 1 Network Programming (TDC 561) 123. 45. 67. 89: 80 3 2 1 Winter 2003 Page 14

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

Ports § Port - A 16 -bit number that identifies the application process that receives an incoming message. § Port numbers divided into three categories • • • Well Known Ports 0 -1023 Registered Ports 1024 -49151 by the IANA (Internet Assigned Numbers Authority), and represent second tier common ports (socks (1080), WINS (1512), kermit (1649), https (443)) Dynamic/Private Ports 49152 -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. • • 1 20 21 23 25 43 69 80 Network Programming (TDC 561) TCP Port Service Multiplexer File Transfer Protocol (FTP) Data FTP Control Telnet Simple Mail Transfer (SMT) Who Is Trivial File Transfer Protocol (TFTP) HTTP Winter 2003 Page 16

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 endpoints 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} Network Programming (TDC 561) Winter 2003 Page 17

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”) Network Programming (TDC 561) Winter 2003 Page 18

Creating a Socket #include <sys/types. h> #include <sys/socket. h> 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 Network Programming (TDC 561) Winter 2003 Page 19

The Socket Structure § INET Address struct in_addr { in_addr_t s_addr; } /* 32 -bit IPv 4 address */ § INET Socket Struct sockaddr_in { uint 8_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 IPv 4 address */ char sin_zero[8]; /* unused */ } Network Programming (TDC 561) Winter 2003 Page 20

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 Network Programming (TDC 561) Winter 2003 Page 21

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

• Connection-oriented socket connections • Client-Server view Network Programming (TDC 561) Winter 2003 Page 23

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

Client Side Socket Details CLIENT Create socket connect to Server socket 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 */ write to the connection int write(int sockfd, void * buffer, size_t buffer_size) write(sockfd, buffer, sizeof(buffer)); read from the connection int read(int sockfd, void * buffer, size_t buffer_size) read(sockfd, buffer, sizeof(buffer)); Network Programming (TDC 561) Winter 2003 Page 25

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) Network Programming (TDC 561) Winter 2003 Page 26

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 the socket, use close() for that) “rw” Network Programming (TDC 561) Winter 2003 close Page 27

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: Little-Endian (Intel) Low Byte High Byte Network Programming (TDC 561) Big-Endian (RISC-Sparc) Address A+1 High Byte Low Byte Winter 2003 Page 28

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

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. Network Programming (TDC 561) Winter 2003 Page 30

Network Byte Order Functions § Several functions are provided to allow conversion between host and network byte ordering, § Conversion macros (<netinet/in. h>) – 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); Network Programming (TDC 561) Winter 2003 Page 31

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

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 */ } Network Programming (TDC 561) Winter 2003 Page 33

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)); Network Programming (TDC 561) Winter 2003 Page 34

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); Network Programming (TDC 561) Winter 2003 Page 35

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. Network Programming (TDC 561) Winter 2003 Page 36

Converting Between IP Address formats § From ASCII to numeric – “ 130. 245. 1. 44” 32 -bit network byte ordered value – inet_aton(…) with IPv 4 – inet_pton(…) with IPv 4 and IPv 6 § From numeric to ASCII – 32 -bit value “ 130. 245. 1. 44” – inet_ntoa(…) with IPv 4 – inet_ntop(…) with IPv 4 and IPv 6 – Note – inet_addr(…) obsolete » cannot handle broadcast address “ 255” (0 x. FFFF) Network Programming (TDC 561) Winter 2003 Page 37

IPv 4 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). Network Programming (TDC 561) Winter 2003 Page 38

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. Network Programming (TDC 561) Winter 2003 Page 39

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). Network Programming (TDC 561) Winter 2003 Page 40

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. Network Programming (TDC 561) Winter 2003 Page 41

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. Network Programming (TDC 561) Winter 2003 Page 42

Terminating a TCP connection § Either end of the connection 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. Network Programming (TDC 561) Winter 2003 Page 43

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 Network Programming (TDC 561) Winter 2003 Page 44

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 Network Programming (TDC 561) Winter 2003 Page 45

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). Network Programming (TDC 561) Winter 2003 Page 46

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. Network Programming (TDC 561) Winter 2003 Page 47

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

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

Daytime client #include "unp. h" int main(int argc, char **argv) { int sockfd, n; char recvline[MAXLINE + 1]; struct sockaddr_in servaddr; § Connects to a daytime server § Retrieves the current date and time % gettime 130. 245. 1. 44 Thu Sept 05 15: 50: 00 2002 if( argc != 2 )err_quit(“usage : gettime <IP address>”); /* 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]); Network Programming (TDC 561) Winter 2003 Page 50

Daytime client /* 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); } Network Programming (TDC 561) Winter 2003 Page 51

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; } Network Programming (TDC 561) Winter 2003 Page 52

Daytime Server #include "unp. h" <time. h> int main(int argc, char **argv) { int listenfd, connfd; struct sockaddr_in servaddr; char buff[MAXLINE]; time_t ticks; § § Waits for requests from Client Accepts client connections Send the current time Terminates connection and goes back waiting for more connections. /* 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)); Network Programming (TDC 561) Winter 2003 Page 53

Daytime Server /* 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), "%. 24 srn", ctime(&ticks)); /* Write to socket */ Write(connfd, buff, strlen(buff)); /* Close the connection */ Close(connfd); } } Network Programming (TDC 561) Winter 2003 Page 54

Background Slides TCP/IP Protocol Suite - Terms and Concepts Distributed Systems Frameworks (DS 520 -95 -103) DISC’ 99

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 Network Programming (TDC 561) Winter 2003 Page 56

End-to-End (Transport) Protocols § 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 Network Programming (TDC 561) Winter 2003 Page 57

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

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 Header § 0 16 31 Src Port Address Dst Port Address Checksum Length of DATA Network Programming (TDC 561) Winter 2003 Page 59

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 Application process W rite bytes … … Application process TCP Receive buffer TCP Send buffer Segment § § § Read bytes Segment … Segment T ransmit segments Full duplex Flow control: keep sender from overrunning receiver Congestion control: keep sender from overrunning network Network Programming (TDC 561) Winter 2003 Page 60

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 Network Programming (TDC 561) Winter 2003 Page 61

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 Network Programming (TDC 561) Winter 2003 Page 62

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 Network Programming (TDC 561) Winter 2003 Page 63

TCP Segment Format 0 16 Source Port Number 31 Destination Port Number Sequence Number Acknowledgement Hdr Len 0 Flags Window Checksum Urgent Pointer Options/Padding Data Network Programming (TDC 561) Winter 2003 Page 64

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. Network Programming (TDC 561) Winter 2003 Page 65

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

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 1 2 3 § Why 3 -way? Network Programming (TDC 561) Winter 2003 Page 67

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. Network Programming (TDC 561) Winter 2003 Page 68

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 Application process W rite bytes … … Application process Read bytes TCP Receive buffer TCP Send buffer Segment … Segment T ransmit segments § Full duplex § Flow control: keep sender from overrunning receiver § Congestion control: keep sender from overrunning network Network Programming (TDC 561) Winter 2003 Page 69

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. Network Programming (TDC 561) Winter 2003 Page 70

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. Network Programming (TDC 561) Winter 2003 Page 71

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. Network Programming (TDC 561) Winter 2003 Page 72

TCP Connection Termination App 2 App 1 FIN SN=X 2 . . . ACK=X+1 1 FIN SN=Y ACK=Y+1 Network Programming (TDC 561) 3 4 Winter 2003 Page 73

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 Network Programming (TDC 561) Winter 2003 Page 74

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 Network Programming (TDC 561) Winter 2003 Page 75