1. Lecture 16 Overview

2. Creating a TCP socket 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)); 2 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

3. 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 3 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

4. 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 4 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

5. 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 5 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

6. 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 6 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

7. 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. 7 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

8. Client Code TCP clients can call connect() which: – takes care of establishing an endpoint address for the client socket – Attempts to establish a connection to the specified server 3-way handshake no need to call bind first, the O.S. will take care of assigning the local endpoint address – TCP port number, IP address 8 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

9. 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 connect() returns 0 if OK, -1 on error – No response to SYN segment (3 trials) – RST signal – ICMP destination unreachable (3 trials) 9 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

10. 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! 10 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

11. 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 readn(), writen() and readline() functions 11 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

12. Creating a UDP socket int mysock; struct sockaddr_in myaddr; Mysock=socket(PF_INET,SOCK_DGRAM,0); myaddr.sin_family = AF_INET; myaddr.sin_port = htons(1234); myaddr.sin_addr = htonl(INADDR_ANY); bind(mysock, &myaddr, sizeof(myaddr)); 12 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

13. Sending UDP Datagrams ssize_t sendto( int sockfd, void *buff, size_t nbytes, int flags, const struct sockaddr* to, socklen_t addrlen); sockfd is a UDP socket buff is the address of the data (nbytes long) to is the destination address Return value is the number of bytes sent, – or -1 on error. 13 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

14. sendto() The return value of sendto() indicates how much data was accepted by the O.S. for sending as a datagram – not how much data made it to the destination. There is no error condition that indicates that the destination did not get the data!!! You can send 0 bytes of data! 14 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

15. Receiving UDP Datagrams ssize_t recvfrom( int sockfd, void *buff, size_t nbytes, int flags, struct sockaddr* from, socklen_t *fromaddrlen); sockfd is a UDP socket buff is the address of a buffer (nbytes long) from is the address of a sockaddr Return value is the number of bytes received and put into buff, or -1 on error 15 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

16. recvfrom() If buff is not large enough, any extra data is lost forever... You can receive 0 bytes of data! recvfrom doesn’t return until there is a datagram available, You should set fromaddrlen before calling If from and fromaddrlen are NULL we don’t find out who sent the data 16 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

17. Typical UDP Communication 17 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

18. Timeout when calling recvfrom() It might be nice to have each call to recvfrom() return after a specified period of time even if there is no incoming datagram We can do this by using SIGALRM and wrapping each call to recvfrom() with a call to alarm() 18 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

19. recvfrom()and alarm() signal(SIGALRM, sig_alrm); alarm(max_time_to_wait); if (recvfrom(…)<0) if (errno==EINTR) /* timed out */ else /* some other error */ else /* no error or time out - turn off alarm */ alarm(0); 19 There are some other (better) ways to do this CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

20. Connected mode A UDP socket can be used in a call to connect() This simply tells the O.S. the address of the peer No handshake is made to establish that the peer exists No data of any kind is sent on the network as a result of calling connect() on a UDP socket 20 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

21. Connected UDP Once a UDP socket is connected: – can use sendto() with a null dest address – can use write() and send() – can use read() and recv() only datagrams from the peer will be returned – Asynchronous errors will be returned to the process 21 OS Specific, some won’t do this! CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

22. Asynchronous Errors What happens if a client sends data to a server that is not running? – ICMP “port unreachable” error is generated by receiving host and sent to sending host – The ICMP error may reach the sending host after sendto() has already returned! – The next call dealing with the socket could return the error 22 CPE 401/601 Lecture 16 : TCP & UDP Socket Programming

23. Lecture 17 Socket Programming Issues CPE 401 / 601 Computer Network Systems slides are modified from Dave Hollinger

24. I/O Multiplexing We often need to be able to monitor multiple descriptors: – a generic TCP client (like telnet) – a server that handles both TCP and UDP – Client that can make multiple concurrent requests browser 24 CPE 401/601 Lecture 17 : I/O Multiplexing

25. Example - generic TCP client Input from standard input should be sent to a TCP socket Input from a TCP socket should be sent to standard output How do we know when to check for input from each source? 25 STDIN STDOUT TCP SOCKET CPE 401/601 Lecture 17 : I/O Multiplexing

26. Options Use multiple processes/threads Use nonblocking I/O – use fcntl() to set O_NONBLOCK Use alarm and signal handler to interrupt slow system calls Use functions that support checking of multiple input sources at the same time 26 CPE 401/601 Lecture 17 : I/O Multiplexing

27. Non blocking I/O Tell kernel not to block a process if I/O requests can not be completed use fcntl() to set O_NONBLOCK: int flags; flags = fcntl(sock,F_GETFL,0); fcntl(sock,F_SETFL,flags | O_NONBLOCK); Now calls to read() (and other system calls) will return an error and set errno to EWOULDBLOCK 27 CPE 401/601 Lecture 17 : I/O Multiplexing

28. Non blocking I/O while (! done) { if ( (n=read(STDIN_FILENO,…)<0)) if (errno != EWOULDBLOCK) /* ERROR */ else write(tcpsock,…) if ( (n=read(tcpsock,…)<0)) if (errno != EWOULDBLOCK) /* ERROR */ else write(STDOUT_FILENO,…) } 28 CPE 401/601 Lecture 17 : I/O Multiplexing

29. The problem with nonblocking I/O Using blocking I/O allows the OS to put your process to sleep when nothing is happening – Once input arrives, the OS will wake up your process and read() (or whatever) will return With nonblocking I/O, the process will chew up all available processor time!!! 29 CPE 401/601 Lecture 17 : I/O Multiplexing

30. Using alarms signal(SIGALRM, sig_alrm); alarm(MAX_TIME); read(STDIN_FILENO,…);... signal(SIGALRM, sig_alrm); alarm(MAX_TIME); read(tcpsock,…);... 30 A function you write CPE 401/601 Lecture 17 : I/O Multiplexing

31. “Alarming” Issues What will happen to the response time ? What is the ‘right’ value for MAX_TIME? 31 CPE 401/601 Lecture 17 : I/O Multiplexing

32. Select() The select() system call allows us to use blocking I/O on a set of descriptors – file, socket, … We can ask select to notify us when data is available for reading on either STDIN or a socket 32 CPE 401/601 Lecture 17 : I/O Multiplexing

33. select() int select( int maxfd, fd_set *readset, fd_set *writeset, fd_set *excepset, const struct timeval *timeout); maxfd: highest number assigned to a descriptor readset: set of descriptors we want to read from writeset: set of descriptors we want to write to excepset: set of descriptors to watch for exceptions timeout: maximum time select should wait 33 CPE 401/601 Lecture 17 : I/O Multiplexing

34. struct timeval struct timeval { long tv_sec;/* seconds */ long tv_usec;/* microseconds */ } struct timeval max = {1,0}; To return immediately after checking descriptors – set timeout as {0, 0} To wait until I/O is ready – set timeout as a NULL pointer 34 CPE 401/601 Lecture 17 : I/O Multiplexing

35. fd_set Operations you can use with an fd_set: – Clear all bits in fd_set void FD_ZERO(fd_set *fdset); – Turn on the bit for fd in fd_set void FD_SET(int fd, fd_set *fdset); – Turn off the bit for fd in fd_set void FD_CLR(int fd, fd_set *fdset); – Check whether the bit for fd in fd_set is on int FD_ISSET(int fd, fd_set *fdset); 35 CPE 401/601 Lecture 17 : I/O Multiplexing

36. Using select() Create fd_set Clear the whole thing with FD_ZERO Add each descriptor you want to watch using FD_SET Call select when select returns, use FD_ISSET to see if I/O is possible on each descriptor 36 CPE 401/601 Lecture 17 : I/O Multiplexing

37. Error Handling Issues and Ideas

38. 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. 38 CPE 401/601 Lecture 17 : Error Handling

39. extern int errno; Whenever an error occurs, system calls set the value of the global variable errno – You can check errno for specific errors 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! 39 CPE 401/601 Lecture 17 : Error Handling

40. 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 40 CPE 401/601 Lecture 17 : Error Handling

41. 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. 41 CPE 401/601 Lecture 17 : Error Handling

42. 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); } 42 CPE 401/601 Lecture 17 : Error Handling

43. 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… 43 CPE 401/601 Lecture 17 : Error Handling

44. 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 ! 44 CPE 401/601 Lecture 17 : Error Handling

45. 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); 45 CPE 401/601 Lecture 17 : Error Handling

46. 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. 46 CPE 401/601 Lecture 17 : Error Handling

47. 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! 47 CPE 401/601 Lecture 17 : Error Handling

48. Client/Server Programming

49. Issues in Client/Server Programming Identifying the Server Looking up an IP address Looking up a well known port name Specifying a local IP address UDP/TCP client design Client/Server Issues 49

50. Identifying the Server Options: – hard-coded into the client program. – require that the user identify the server. – read from a configuration file. – use a separate protocol/network service to lookup the identity of the server. Client/Server Issues 50

51. Identifying a TCP/IP server Need an IP address, protocol and port. – We often use host names instead of IP addresses – usually the protocol is not specified by the user UDP vs. TCP – often the port is not specified by the user. Client/Server Issues 51

52. Services and Ports Many services are available via “well known” addresses (names). There is a mapping of service names to port numbers: struct *servent getservbyname( char *service, char *protocol ); servent->s_port is the port number in network byte order Client/Server Issues 52

53. Specifying a Local Address When a client creates and binds a socket, it must specify a local port and IP address Typically a client doesn’t care what port it is on: haddr->port = htons(0); Client/Server Issues 53 give me any available port !

54. Local IP address A client can also ask the operating system to take care of specifying the local IP address: haddr->sin_addr.s_addr= htonl(INADDR_ANY); Client/Server Issues 54 Give me the appropriate address

55. UDP Client Design Establish server address (IP and port). Allocate a socket. Specify that any valid local port and IP address can be used. Communicate with server (send, recv) Close the socket. Client/Server Issues 55

56. Connected mode UDP A UDP client can call connect() to establish the address of the server The UDP client can then use read() and write() or send() and recv() A UDP client using a connected mode socket can only talk to one server – using the connected-mode socket Client/Server Issues 56

57. TCP Client Design Establish server address (IP and port). Allocate a socket. Specify that any valid local port and IP address can be used. Call connect() Communicate with server (read, write). Close the connection. Client/Server Issues 57

58. Closing a TCP socket Many TCP based application protocols support – multiple requests and/or – variable length requests over a single TCP connection. How does the server known when the client is done ? – and it is OK to close the socket ? Client/Server Issues 58

59. Partial Close One solution is for the client to shut down only it’s writing end of the socket. The shutdown() system call provides this function. shutdown(int s, int direction); – direction can be 0 to close the reading end or 1 to close the writing end. – shutdown sends info to the other process! Client/Server Issues 59

60. TCP sockets programming Common problem areas: – null termination of strings. – reads don’t correspond to writes. – synchronization (including close()). – ambiguous protocol. Client/Server Issues 60

61. TCP Reads Each call to read() on a TCP socket returns any available data – up to a maximum TCP buffers data at both ends of the connection. You must be prepared to accept data 1 byte at a time from a TCP socket! Client/Server Issues 61

62. Server Design Client/Server Issues 62 Iterative Connectionless Iterative Connectionless Iterative Connection-Oriented Iterative Connection-Oriented Concurrent Connection-Oriented Concurrent Connection-Oriented Concurrent Connectionless Concurrent Connectionless

63. Concurrent vs. Iterative Client/Server Issues 63 Iterative Small, fixed size requests Easy to program Iterative Small, fixed size requests Easy to program Concurrent Large or variable size requests Harder to program Typically uses more system resources Concurrent Large or variable size requests Harder to program Typically uses more system resources

64. Connectionless vs. Connection-Oriented Client/Server Issues 64 Connection-Oriented EASY TO PROGRAM transport protocol handles the tough stuff. requires separate socket for each connection. Connection-Oriented EASY TO PROGRAM transport protocol handles the tough stuff. requires separate socket for each connection. Connectionless less overhead no limitation on number of clients Connectionless less overhead no limitation on number of clients

65. Statelessness State: Information that a server maintains about the status of ongoing client interactions. Connectionless servers that keep state information must be designed carefully! Client/Server Issues 65 Messages can be duplicated!

66. The Dangers of Statefullness Clients can go down at any time. Client hosts can reboot many times. The network can lose messages. The network can duplicate messages. Client/Server Issues 66

67. Concurrent Server Design Alternatives One child per client Spawn one thread per client Preforking multiple processes Prethreaded Server Client/Server Issues 67

68. One child per client Traditional Unix server: – TCP: after call to accept(), call fork(). – UDP: after recvfrom(), call fork(). – Each process needs only a few sockets. – Small requests can be serviced in a small amount of time. Parent process needs to clean up after children!!!! – call wait() Client/Server Issues 68

69. One thread per client Almost like using fork – call pthread_create instead Using threads makes it easier to have sibling processes share information – less overhead Sharing information must be done carefully – use pthread_mutex Client/Server Issues 69

70. Prefork()’d Server Creating a new process for each client is expensive. We can create a bunch of processes, each of which can take care of a client. Each child process is an iterative server. Client/Server Issues 70

71. Prefork()’d TCP Server Initial process creates socket and binds to well known address. Process now calls fork() a bunch of times. All children call accept(). The next incoming connection will be handed to one child. Client/Server Issues 71

72. Preforking Having too many preforked children can be bad. Using dynamic process allocation instead of a hard-coded number of children can avoid problems. Parent process just manages the children – doesn’t worry about clients Client/Server Issues 72

73. Sockets library vs. system call A preforked TCP server won’t usually work the way we want if sockets is not part of the kernel: – calling accept() is a library call, not an atomic operation. We can get around this by making sure only one child calls accept() at a time using some locking scheme. Client/Server Issues 73

74. Prethreaded Server Same benefits as preforking. Can also have the main thread do all the calls to accept() – and hand off each client to an existing thread Client/Server Issues 74

75. What’s the best server design? Many factors: – expected number of simultaneous clients – Transaction size time to compute or lookup the answer – Variability in transaction size – Available system resources perhaps what resources can be required in order to run the service Client/Server Issues 75

76. Server Design It is important to understand the issues and options. Knowledge of queuing theory can be a big help. You might need to test a few alternatives to determine the best design. Client/Server Issues 76