1. TDC561 Network Programming Camelia Zlatea, PhD Email: czlatea@cs.depaul.educzlatea@cs.depaul.edu Week 5: Client/Server Programming Aspects  Client side: Identifying the Server; Specifying a local IP address; TCP client design, UDP client design.  Server Side: Daemon, inetd. Socket Options ( discussion will continue in a next lecture )

2. Network Programming (TDC561)Page 2 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. 6, 14 (partial)  W. Richard Stevens, Network Programming : Networking API: Sockets and XTI, Volume 1, 2nd edition, 1998 (ISBN 0- 13-490012-X) –Chap. 7,11,12, 21,22

3. Network Programming (TDC561)Page 3 Winter 2003 Aspects of Client/Server Programming  Client-side aspects: –Identifying the Server. »Looking up an IP address. »Looking up a well known port name. –Specifying a local IP address. –TCP client design. –UDP client design.  Server-side aspects: –daemons –inetd

4. Network Programming (TDC561)Page 4 Winter 2003 Identifying the Server  Need an IP address, protocol and port. –often use host names instead of IP addresses. –usually the protocol (UDP vs. TCP) is not specified by the user. –often the port is not specified by the user.  Options: –hard-coded into the client program. –require that the user identify the server. –read from a configuration file. –use a separate network service to lookup the identity of the server.

5. Network Programming (TDC561)Page 5 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)

6. Network Programming (TDC561)Page 6 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

7. Network Programming (TDC561)Page 7 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.

8. Network Programming (TDC561)Page 8 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);

9. Network Programming (TDC561)Page 9 Winter 2003 Services and Ports  Identifying of the server –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.  Specifying a Local Address –When a client creates and binds a socket it must specify a local port and an IP address. »A client ask the kernel to assign the local IP address: haddr->sin_addr.s_addr= htonl(INADDR_ANY); »Typically a randomly port available is assigned with: haddr->port = htons(0);

10. Network Programming (TDC561)Page 10 Winter 2003 Example: Identifying the Server /* Initialize the server structure */ server.sin_addr.s_addr = INADDR_ANY; server.sin_family = AF_INET; /* Get the service port associated with this process usually in some /etc/ config file such as /etc/services */ servent_p = getservbyname ( PMSERVICE, “tcp” ); server.sin_port = servent_p->s_port;  Option: read from a configuration file.

11. Network Programming (TDC561)Page 11 Winter 2003 DNS library functions : gethostbyname #include struct hostent *gethostbyname( const char *hostname); struct hostent { char *h_name; char **h_aliases; int h_addrtype; int h_length; char **h_addr_list; };

12. Network Programming (TDC561)Page 12 Winter 2003 hostent h_name h_aliases h_addrtype h_length h_addr_list Official Name alias 1 alias 2 null (IP address 1) (IP address 2) null #define h_addr h_addr_list[0] h_addr_list[0] h_addr_list[1] All the IP addresses returned via the hostent are in network byte order

13. Network Programming (TDC561)Page 13 Winter 2003 DNS library functions : gethostbyname  On error gethostbyname return null.  gethostbyname sets the global variable h_errno to indicate the exact error: –HOST_NOT_FOUND –TRY_AGAIN –NO_RECOVERY –NO_DATA –NO_ADDRESS

14. Network Programming (TDC561)Page 14 Winter 2003 Getting host IP address: char **h_addr_list; h = gethostbyname(“hawk.depaul.edu"); memcpy(&sockaddr.sin_addr, h->h_addr_list[0], sizeof(struct in_addr));

15. Network Programming (TDC561)Page 15 Winter 2003 DNS library functions : gethostbyaddr struct hostent *gethostbyaddr( const char *addr size_t len, int family);

16. Network Programming (TDC561)Page 16 Winter 2003 Other DNS library functions  Shell Command uname –n –get hostname of local host –uname –a prints all info local host  getservbyname –get port number for a named service  getservbyaddr –get name for service associated with a port number

17. Network Programming (TDC561)Page 17 Winter 2003 Name/Address Conversion  Protocol dependent DNS library functions –gethostbyname –gethostbyaddr  Posix protocol independent functions –getaddrinfo() –getnameinfo() –getaddrinfo()and getnameinfo() functions provide name/address conversions as part of the sockets library. –designed to support writing code that can run on many protocols (IPv4, IPv6)

18. Network Programming (TDC561)Page 18 Winter 2003 POSIX: getaddrinfo() int getaddrinfo( const char *hostname, const char *service, const struct addrinfo* hints, struct addrinfo **result);  hostname is a hostname or an address string (dotted decimal string for IP).  service is a service name or a decimal port number string.  getaddrinfo() –provides the combined functionality of gethostbyname() and getservbyname()

19. Network Programming (TDC561)Page 19 Winter 2003 POSIX: getaddrinfo() struct addrinfo { intai_flags; intai_family; intai_socktype; intai_protocol; size_tai_addrlen; char *canonname; structsockaddr *ai_addr; structaddrinfo *ai_next; }; used by socket() used by: bind()connect()sendto()  result is returned with the address of a pointer to an addrinfo structure that is the head of a linked list.

20. Network Programming (TDC561)Page 20 Winter 2003 POSIX: getnameinfo() int getnameinfo( const struct sockaddr *sockaddr, socklen_t addrlen char *host, size_t hostlen, char *serv, size_t servlen, int flags); getnameinfo() looks up a hostname and a service name given a sockaddr

21. Network Programming (TDC561)Page 21 Winter 2003 TCP Client Design  Identify and establish server address (IP and port).  Allocate a socket.  Request OS to use any valid local port and IP address  Call connect()  Communicate with server (read,write).  Close the connection.

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 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 ? –When it is safe to close the socket?

24. Network Programming (TDC561)Page 24 Winter 2003 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

25. Network Programming (TDC561)Page 25 Winter 2003 TCP Sockets Programming  Typical issues : –reads don’t correspond to writes. –synchronization (including close())  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.

26. Network Programming (TDC561)Page 26 Winter 2003 UDP Client Design  Identify and establish the server address (IP and port).  Allocate a socket.  Request OS to use any valid local port and IP address  Communicate with server (send, recv)  Close the socket.

27. Network Programming (TDC561)Page 27 Winter 2003 Datagram Socket Transaction (UDP Connection) socket() bind() socket() sendto() recvfrom() close() recvfrom() sendto() data Client Server

28. Network Programming (TDC561)Page 28 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

29. Network Programming (TDC561)Page 29 Winter 2003 Daemons  Most servers run as a daemon process  Typical UNIX daemons: –Web server (httpd) –Mail server (sendmail) –SuperServer (inetd) –System logging (syslogd) –Print server (lpd) –router process (routed, gated)

30. Network Programming (TDC561)Page 30 Winter 2003 Daemon Process  A daemon is a process that: –runs in the background –not associated with any terminal »output doesn't end up in another session. »ignore SIGINT (such as terminal generated signals - ^C –since is not associated with any terminal uses »file system »central logging facility –daemons should close all unnecessary descriptors »often including stdin, stdout, stderr. –daemons often change working directory.  A background process –Parent process fork() and then the parent exit().  A way to disassociate a process from a terminal. –Call setsid() and then fork() again.

31. Network Programming (TDC561)Page 31 Winter 2003 Daemon Process Init – Example #include int daemon_init(void) { pid_tpid; if ( (pid = fork()) < 0) return(-1); else if (pid != 0) exit(0);/* parent is gone */ /* child continues */ setsid();/* become session leader */ system(“cd /");/* change working directory */ umask(0);/* clear our file mode creation mask */ close(0); close(1); close(2); /* stdin, stdout, stderr */ return(0); }

32. Network Programming (TDC561)Page 32 Winter 2003  CPU utilization –There can be many servers running as daemons -and idle most of the time.  Memory utilization –Most daemons/servers are suspended most of the time, but still occupy space in the process table.  A solution: Superserver or inetd ( Internet services daemon ) Performance issues with daemons processes

33. Network Programming (TDC561)Page 33 Winter 2003 inetd  the SuperServer is named inetd.  inetd daemon creates multiple sockets and waits for (multiple) incoming requests.  inetd typically uses select to watch multiple sockets for input.  when a request arrives, inetd will fork and the child process handles the client.  inetd child process closes all unnecessary sockets.  inetd child dup ’s the client socket to descriptors 0,1 and 2 ( stdin, stdout, stderr ).  inetd child exec ’s the real server program, which handles the request and exits.

34. Network Programming (TDC561)Page 34 Winter 2003 inetd based servers  Servers that are started by inetd assume that the socket holding the request is already established (descriptors 0,1 or 2).  TCP servers started by inetd don’t call accept, so they must call getpeername if they need to know the address of the client.  inetd reads a configuration file that lists all the services it should handle. –/etc/inetd.conf  inetd creates a socket for each listed service, and adds the socket to a fd_set given to select().

35. Network Programming (TDC561)Page 35 Winter 2003 getpeername #include int getpeername(int s, struct sockaddr *name, socklen_t *namelen);  getpeername() returns the name of the peer connected to socket s.

36. Network Programming (TDC561)Page 36 Winter 2003 inetd service specification  For each service, inetd needs to know: –the socket type and transport protocol –wait/nowait flag. –login name the process should run as. –pathname of real server program. –command line arguments to server program.  Servers that are expected to deal with frequent requests are typically not run from inetd –mail, web, NFS.

37. Network Programming (TDC561)Page 37 Winter 2003 # Syntax for socket-based Internet services: # # comments start with # echo stream tcp nowait root internal echo dgram udp wait root internal chargen stream tcp nowait root internal chargen dgram udp wait root internal ftp stream tcp nowait root /usr/sbin/ftpd ftpd -l telnet stream tcp nowait root /usr/sbin/telnetd telnetd finger stream tcp nowait root /usr/sbin/fingerd fingerd # Authentication auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e - o # TFTP tftp dgram udpwait root /usr/sbin/tftpd tftpd -s /tftpboot Example /etc/inetd.conf

38. Network Programming (TDC561)Page 38 Winter 2003 wait/nowait  WAIT specifies that inetd should not look for new clients for the service until the child (the real server) has terminated.  TCP servers usually specify nowait - this means inetd can start multiple copies of the TCP server program - providing concurrency  Most UDP services run with inetd told to wait until the child server has died.

39. Topic Socket Options (discussion will continue in a next lecture)

40. Network Programming (TDC561)Page 40 Winter 2003 Socket Options  Various attributes that are used to determine the behavior of sockets.  Setting options tells the OS/Protocol Stack the behavior we want.  Support for generic options (apply to all sockets) and protocol specific options.

41. Network Programming (TDC561)Page 41 Winter 2003 Option types  Many socket options are Boolean flags indicating whether some feature is enabled (1) or disabled (0).  Other options are associated with more complex types including int, timeval, in_addr, sockaddr, etc.

42. Network Programming (TDC561)Page 42 Winter 2003 Read-Only Socket Options  Some options are readable only (we can’t set the value).

43. Network Programming (TDC561)Page 43 Winter 2003 Setting and Getting option values #include getsockopt() gets the current value of a socket option. setsockopt() is used to set the value of a socket option.

44. Network Programming (TDC561)Page 44 Winter 2003 int getsockopt( int sockfd, int level, int optname, void *opval, socklen_t *optlen); level specifies whether the option is a general option or a protocol specific option (what level of code should interpret the option). getsockopt()

45. Network Programming (TDC561)Page 45 Winter 2003 int setsockopt( int sockfd, int level, int optname, const void *opval, socklen_t optlen); setsockopt()

46. Network Programming (TDC561)Page 46 Winter 2003 General Options  Protocol independent options.  Handled by the generic socket system code.  Some general options are supported only by specific types of sockets (SOCK_DGRAM, SOCK_STREAM).

47. Network Programming (TDC561)Page 47 Winter 2003 Some Generic Options SO_BROADCAST SO_DONTROUTE SO_ERROR SO_KEEPALIVE SO_LINGER SO_RCVBUF,SO_SNDBUF SO_REUSEADDR

48. Network Programming (TDC561)Page 48 Winter 2003 SO_BROADCAST  Boolean option: enables/disables sending of broadcast messages.  Underlying data layer must support broadcasting  Applies only to SOCK_DGRAM sockets.  Prevents applications from inadvertently sending broadcasts (OS looks for this flag when broadcast address is specified).

49. Network Programming (TDC561)Page 49 Winter 2003 SO_DONTROUTE  Boolean option: enables bypassing of normal routing.  Used by routing daemons.

50. Network Programming (TDC561)Page 50 Winter 2003 SO_ERROR  Integer value option.  The value is an error indicator value (similar to errno).  Readable only  Reading (by calling getsockopt() ) clears any pending error.

51. Network Programming (TDC561)Page 51 Winter 2003 SO_KEEPALIVE  Boolean option: enabled means that STREAM sockets should send a probe to peer if no data flow for a “long time”.  Used by TCP - allows a process to determine whether peer process/host has crashed.  Consider what would happen to an open telnet connection without keepalive.

52. Network Programming (TDC561)Page 52 Winter 2003 SO_LINGER Value is of type: struct linger { int l_onoff; /* 0 = off */ int l_linger; /* time in seconds */ };  Used to control whether and how long a call to close will wait for pending ACKS.  connection-oriented sockets only.

53. Network Programming (TDC561)Page 53 Winter 2003 SO_LINGER usage  By default, calling close() on a TCP socket will return immediately.  The closing process has no way of knowing whether or not the peer received all data.  Setting SO_LINGER means the closing process can determine that the peer machine has received the data (but not that the data has been read() !).

54. Network Programming (TDC561)Page 54 Winter 2003 shutdown() vs SO_LINGER  How you can use shutdown() to find out when the peer process has read all the sent data [see R.Stevens, 7.5]

55. Network Programming (TDC561)Page 55 Winter 2003 FIN SN=X FIN SN=X Client Server ACK=X+1 ACK=Y+1 1 2 4 FIN SN=Y FIN SN=Y 3... TCP Connection Termination write close close returns Data queued By TCP Application Reads queued data and FIN close

56. Network Programming (TDC561)Page 56 Winter 2003 FIN SN=X FIN SN=X Client Server ACK=X+1 ACK=Y+1 1 2 4 FIN SN=Y FIN SN=Y 3... TCP Connection Termination close w/ SO_LINGER write close close returns Data queued By TCP App. Reads queued data and FIN close

57. Network Programming (TDC561)Page 57 Winter 2003 FIN SN=X FIN SN=X Client Server ACK=X+1 ACK=Y+1 1 2 4 FIN SN=Y FIN SN=Y 3... TCP Connection Termination w/ shutdown write shutdown WRITE read blocks read returns 0 Data queued By TCP App. Reads queued data and FIN close

58. Network Programming (TDC561)Page 58 Winter 2003 SO_RCVBUF and SO_SNDBUF  Integer values options - change the receive and send buffer sizes.  Can be used with STREAM and DGRAM sockets.  With TCP, this option effects the window size used for flow control - must be established before connection is made.

59. Network Programming (TDC561)Page 59 Winter 2003 SO_REUSEADDR  Boolean option: enables binding to an address (port) that is already in use.  Used by servers that are transient - allows binding a passive socket to a port currently in use (with active sockets) by other processes. (see example from lecture 4 – Performance Management server)  Can be used to establish separate servers for the same service on different interfaces (or different IP addresses on the same interface).  Virtual Web Servers can work this way.

60. Network Programming (TDC561)Page 60 Winter 2003 IP Options (IPv4)  IP_HDRINCL: used on raw IP sockets when we want to build the IP header ourselves.  IP_TOS: allows us to set the “Type-of-service” field in an IP header.  IP_TTL: allows us to set the “Time-to-live” field in an IP header.

61. Network Programming (TDC561)Page 61 Winter 2003 TCP socket options  TCP_KEEPALIVE: set the idle time used when SO_KEEPALIVE is enabled.  TCP_MAXSEG: set the maximum segment size sent by a TCP socket.

62. Network Programming (TDC561)Page 62 Winter 2003 TCP socket options  TCP_NODELAY: can disable TCP’s Nagle algorithm that delays sending small packets if there is unACK’d data pending.  TCP_NODELAY also disables delayed ACKS (TCP ACKs are cumulative).