1. Lecture 6 TCP Socket Programming CPE 401 / 601 Computer Network Systems slides are modified from Dave Hollinger

2. TCP Sockets Programming  Creating a passive mode (server) socket.  Establishing an application-level connection.  send/receive data.  Terminating a connection. TCP Socket Programming 2

3. 3 TCP state diagram

4. Creating a TCP socket int socket(int family,int type,int protocol);  family: AF_INET, AF_INET6, AF_LOCAL, …  type: SOCK_STREAM, SOCK_DGRAM, SOCK_SEQPACKET, SOCK_RAW  protocol: IPPROTO_TCP, IPPROTO_UDP, IPPROTO_SCTP int sock; sock = socket(PF_INET, SOCK_STREAM, 0); if (sock<0) { /* ERROR */ } TCP Socket Programming 4

5. Binding to well known address int bind(int sockfd, const struct sockaddr *myaddr, socklen_t addrlen); int mysock; struct sockaddr_in myaddr; mysock = socket(PF_INET,SOCK_STREAM,0); myaddr.sin_family = AF_INET; myaddr.sin_port = htons( 80 ); myaddr.sin_addr = htonl( INADDR_ANY ); bind(mysock, (sockaddr *) &myaddr, sizeof(myaddr)); TCP Socket Programming 5

6. 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. TCP Socket Programming 6

7. listen() int listen(int sockfd, int backlog);  sockfd 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).  Sum of incomplete and completed queues  listen() returns -1 on error (otherwise 0). TCP Socket Programming 7

8. 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. TCP Socket Programming 8

9. accept() int accept( int sockfd, struct sockaddr* cliaddr, socklen_t *addrlen);  sockfd is the passive mode TCP socket.  initiated by socket(), bind(), and listen()  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. TCP Socket Programming 9

10. accept() return value  accept() returns a new socket descriptor (small 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.  read() and write() operate a little differently on sockets (vs. file operation)! TCP Socket Programming 10

11. Terminating a TCP connection int close(int sockfd);  Either end of the connection can call the close() system call.  What if there is data being sent?  If the other end has closed the connection, and there is no buffered data, reading from a TCP socket returns 0 to indicate EOF. TCP Socket Programming 11

12. 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 TCP Socket Programming 12

13. 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  No response to SYN segment (3 trials: 6 sec, 24 sec, 45 sec)  RST signal  ICMP destination unreachable (3 trials) TCP Socket Programming 13

14. 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).  You must be prepared to read data 1 byte at a time! TCP Socket Programming 14

15. 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).  The book includes readn(), writen() and readline() function definitions (section 3.9). TCP Socket Programming 15

16. Metaphor for Good Relationships To succeed in relationships*:  you need to establish your own identity.  you need to be open & accepting.  you need to establish contacts.  you need to take things as they come, not as you expect them.  you need to handle problems as they arise. bind() accept() connect() check for errors read might return 1 byte TCP Socket Programming 16 *Copyright Dr. Laura’s Network Programming Corp.

17. Error Handling Issues and Ideas

18. System Calls and Errors  In general, systems calls return a negative number to indicate an error.  We often want to find out what error.  Servers generally add this information to a log.  Clients generally provide some information to the user. TCP Socket Programming 18

19. extern int errno;  Whenever an error occurs, system calls set the value of the global variable errno.  You can check errno for specific errors.  You can use support functions to print out or log an ASCII text error message.  errno is valid only after a system call has returned an error.  System calls don't clear errno on success.  If you make another system call you may lose the previous value of errno. printf makes a call to write ! TCP Socket Programming 19

20. Error codes Error codes are defined in errno.h EAGAINEBADFEACCESS EBUSYEINTREINVAL EIOENODEVEPIPE … Support routines  void perror(const char *string);  stdio.h  char *strerror(int errnum);  string.h TCP Socket Programming 20

21. General Strategies  Include code to check for errors after every system call.  Develop "wrapper functions" that do the checking for you.  Develop layers of functions, each hides some of the error-handling details. TCP Socket Programming 21

22. Example wrapper int Socket( int f, int t, int p) { int n; if ( (n=socket(f,t,p)) < 0 ) ) { perror("Fatal Error"); exit(1); } return(n); } TCP Socket Programming 22

23. What is fatal?  How do you know what should be a fatal error (program exits)?  Common sense.  If the program can continue – it should.  if a server can't create a socket, or can't bind to it's port there is no sense continuing… TCP Socket Programming 23

24. Wrappers are great!  Wrappers like those used in the text can make code much more readable.  There are always situations in which you cannot use the wrappers  Sometimes system calls are "interrupted" (EINTR) this is not always a fatal error ! TCP Socket Programming 24

25. Word of Caution  If you use the code from the book for your projects, you must understand it!  The library of code used in the text is extensive  Wrappers call custom error handing code.  Custom error handling code make assumptions about having other custom library functions.  … TCP Socket Programming 25

26. Another approach  Instead of simple wrapper functions, you might develop a layered system.  The idea is to "hide" the sockaddr and error handling details behind a few custom functions: int tcp_client(char *server, int port); int tcp_server(int port); TCP Socket Programming 26

27. Layers and Code Re-use  Developing general functions that might be re-used in other programs is obviously "a good thing".  Layering is beneficial even if the code is not intended to be re-used:  hide error-handling from "high-level" code.  hide other details.  often makes debugging easier. TCP Socket Programming 27

28. The Best Approach to handling errors  There is no best approach.  Do what works for you.  Make sure you check all system calls for errors!  Not checking can lead to security problems!  Not checking can lead to bad grades on lab projects! TCP Socket Programming 28