1. Client-Server Applications Approx. text coverage: Chap. 21, Vol III

2. Copyright Rudra Dutta, NCSU, Spring, 20032 Introduction TCP/IP specifies the details of how data passes between a pair of communicating applications provides peer-to-peer communication TCP/IP standard does not… specify how to write distributed applications provide a way to start a process when a message arrives the “rendezvous” problem Solution to rendezvous problem a program must be waiting to establish communication before any requests arrive savings in cost scalability

3. Copyright Rudra Dutta, NCSU, Spring, 20033 Client-Server Relationship

4. Copyright Rudra Dutta, NCSU, Spring, 20034 Clients vs. Servers Who takes the first step? clients initiate peer-to-peer communications  active open servers wait for incoming communication requests  passive open Lifetimes servers start execution before interaction begins, and continue to accept and process requests “forever” clients are short-lived Ports servers wait for requests at a well-known port reserved for the service offered clients use arbitrary, non-reserved ports for communication

5. Copyright Rudra Dutta, NCSU, Spring, 20035 Clients vs. Servers (cont’d) Complexity of clients no special privileges required (usually) overall, relatively easy to build Complexity of servers require special system privileges (usually) may need to handle multiple requests concurrently must protect themselves against all possible errors generally more difficult to build Both are usually implemented as application programs

6. Copyright Rudra Dutta, NCSU, Spring, 20036 Privileges and Complexity Because of their privileged status, servers must contain code that handles... 1. authentication 2. authorization 3. data security 4. privacy 5. protection (of resources)

7. Copyright Rudra Dutta, NCSU, Spring, 20037 Connectionless vs. Connection- Oriented Servers Generally “connectionless” = UDP “connection-oriented” = TCP critical difference = level of reliability provided Use of UDP recommended only when... application is non-critical (occasional failure is OK), or application handles reliability, or application uses hardware broadcast/multicast, or application cannot tolerate the overhead of TCP as measured in time, and in bytes

8. Copyright Rudra Dutta, NCSU, Spring, 20038 Iterative (“one-at-a-time”) Servers… Request handling 1. wait for a client request to arrive 2. process the client request 3. send the response back to the client 4. go back to step 1 OK for services such as Echo/Time/Daytime short, single response easy to program! But if Step 2 takes a while, other clients have to wait and/or incoming requests may be lost

9. Copyright Rudra Dutta, NCSU, Spring, 20039 …vs. Concurrent Servers “Master” process responsible for accepting requests, “Slave” processes responsible for handling requests 1. Master waits for a client request to arrive 2. Master starts a new slave process to handle this request 3. Master returns to Step 1 Slave executes concurrently, terminates independently when finished Efficient, no waiting, but harder to program

10. Copyright Rudra Dutta, NCSU, Spring, 200310 Server Deadlock Problem Server can be subject to deadlock if... client never sends a request, server may block in a call to read() for ever or, client sends a sequence of requests but never reads responses What happens with UDP? TCP? For concurrent servers, only the slave handling the request from misbehaving client will block For single-process implementation the central server process will block will stop handling other connections Could be an issue for “apparent concurrency”

11. Copyright Rudra Dutta, NCSU, Spring, 200311 Types of Servers ConnectionlessConnection- Oriented Iterative (one-at- a-time) Iterative Connectionless (normal UDP) Iterative Connection- Oriented (uncommon) Con- current Concurrent Connectionless (uncommon) Concurrent Connection- Oriented (normal TCP)

12. Copyright Rudra Dutta, NCSU, Spring, 200312 Connection-Oriented Concurrent Server

13. Copyright Rudra Dutta, NCSU, Spring, 200313 Options for Concurrency Dynamically create one child process per client fork() creates a child process all memory, stack, code, registers, etc. are duplicated for the child open file and socket descriptors are shared Dynamically create one thread per client easier to share data between clients must be careful to lock shared data structures before modifying! Statically create fixed number of child processes all children call accept() the next incoming connection will be handed to one child

14. Copyright Rudra Dutta, NCSU, Spring, 200314 The fork() System Call int pid; … pid = fork(); if (pid != 0) /* original process */ printf("The original process prints this\n"); else /* newly created process */ printf("The new process prints this\n"); fork() returns 0 to the child process, process ID of the child to the parent process

15. Copyright Rudra Dutta, NCSU, Spring, 200315 Stateless vs. Stateful Servers Servers may or may not keep state information about ongoing interactions Keeping state information may improve efficiency smaller messages simpler processing Keeping state also causes problems state information may become incorrect, due to unreliable network (duplicate messages, undelivered messages) client crashes keeping state “bogs down” the server

16. Copyright Rudra Dutta, NCSU, Spring, 200316 Improving Server Performance Caching in client/server interaction improves performance whenever recent history of queries is a good indicator of future use (e.g., ARP cache) lowers retrieval cost for all except the first request for the information Pre-fetching of information prior to first request The “push” paradigm concurrent background processes collect and propagate information before any program requests it wasteful if push data that no one actually needs may not be scalable

17. Copyright Rudra Dutta, NCSU, Spring, 200317 System Calls and Errors In general, systems calls return a negative number to indicate an error servers generally add this information to a log clients generally provide some information to the user 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: perror(), strerror() windows error codes are defined at http://www.sockets.com/err_lst1.htm

18. Copyright Rudra Dutta, NCSU, Spring, 200318 Errors (cont’d) 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 extern int errno;

19. Copyright Rudra Dutta, NCSU, Spring, 200319 UDP Datagram Transmission Example Client Server int value_out; value = htonl(value); n = write(s, (char *)&value, sizeof(value)); If (n < 0) /* error message here */ int value_in; n = read(s, (char *)&value_in, sizeof(value_in));

20. Copyright Rudra Dutta, NCSU, Spring, 200320 TCP Example #1: Client (fixed-length data to send) int s, n, buflen; char *request = "some request"; char buf[BLEN]; char *bptr; write(s, request, strlen(request)); /* send request */ bptr = buf; buflen = BLEN; /* read response (may come in many pieces) */ while ((n = read(s, bptr, buflen) > 0) { bptr += n; buflen -= n; }

21. Copyright Rudra Dutta, NCSU, Spring, 200321 TCP Example #2: Sending Variable-Length Messages Client sends size of message first then sends actual data Server receive size, then receive whole message u_short msg_len; Char msgout[MAXLEN]; fill_in_data(&msgout); /* make sure null-terminated */ msg_len = htons(strlen(&msgout)); write(s, (char *) &msg_len, sizeof(msg_len));/* write length */ write(s, msgout, msg_len); /* write message */

22. Copyright Rudra Dutta, NCSU, Spring, 200322 TCP Example #2 (cont’d) u_short msg_len; char *ptr, msgin[MAXLEN]; n = 0; ptr = (char *)&msg_len; /* read length of message */ for(i=0; i<sizeof(msg_len); i+=n, ptr+=n){ n = read(s, ptr, sizeof(msg_len)-i); if(n < 0) /* error message here*/ } msg_len = ntohs(msg_len); ptr = (char *) msgin; /* now read message */ for(i=0; i<msg_len; i+=n, ptr+=n){ n = read(s, ptr, msg_len-i); if(n < 0) /* error message here*/ }

23. Copyright Rudra Dutta, NCSU, Spring, 200323 Concurrent Server Algorithm (TCP) Master create socket and bind to well-known address for service; leave socket unconnected place the socket in passive mode (ready for use) repeat: call accept() to receive next request from a client, and create a slave process to handle the response Slave receive a connection request (i.e., socket for the connection) upon creation repeat: read request(s) from the client, and send back the responses when finished with the client, close the connection and exit

24. Copyright Rudra Dutta, NCSU, Spring, 200324 Server Implementation for ( ; ; ) { new_s = accept(s,... ); /* blocks until connect */ /* request recv’d */ if (fork() == 0) { /* this is the child process */ close(s); /* child stops using parent’s socket */ process_request(new_s);/* get request, respond */ exit(0); /* child process is done ! */ } close(new_s); /* this is the parent process */ /* parent stops using child’s socket */ }

25. Copyright Rudra Dutta, NCSU, Spring, 200325 Cleaning Up Child Processes Signals = type of asynchronous interprocess communication When a child process terminates, signal SIGCHLD is sent to the parent if the parent does not call wait() to obtain the child's exit status, the terminating process is marked as a zombie process the parent must call wait3() to clean up zombie processes (see text for details)

26. Copyright Rudra Dutta, NCSU, Spring, 200326 Multiplexing with select(), again Allows a single process to wait for connections on multiple sockets (applies to I/O in general, not just sockets) int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) struct timeval { long tv_usec;/* seconds */ long tv_usec;/* microseconds */ } … struct timeval max = {1,0};

27. Copyright Rudra Dutta, NCSU, Spring, 200327 select() Details Parameters nfds : highest number assigned to any descriptor you wish to check readfds : set of descriptors we want to read from writefds : set of descriptors we want to write to exceptfds : set of descriptors to watch for exceptions timeout : maximum time select should wait F unctions for manipulating and checking flags FD_ZERO(fd_set *fdset) /* clear all bits in fdset */ FD_SET(int fd, fd_set *fdset) /* turn bit for fd on in fdset */ FD_CLR(int fd, fd_set *fdset) /* turn bit for fd off in fdset */ FD_ISSET(int fd, fd_set *fdset)/* test the bit for fd in fdset */

28. Copyright Rudra Dutta, NCSU, Spring, 200328 select() (cont'd) The value of the timeout argument determines the behavior of select() NULL pointer select() returns only when one of the specified descriptors is ready for I/O, but may wait indefinitely Non-zero value select() returns when one of the specified descriptors is ready for I/O but only waits up to the time specified Zero value select() returns immediately after checking the descriptors i.e., used for polling

29. Copyright Rudra Dutta, NCSU, Spring, 200329 Using select() 1. Create fds 2. Clear fds with FD_ZERO 3. Add each descriptor you want to watch using FD_SET 4. Call select() 5. When select() returns, use FD_ISSET to see if I/O is possible check each descriptor one-by-one

30. Copyright Rudra Dutta, NCSU, Spring, 200330 Single Process Concurrent Server Algorithm Example (TCP) int master_s, new_s; fd_set rfds, afds; /* read, active descriptors */ master_s = socket(...); /* create master socket */ bind(master_s,...); /* bind to a port */ listen(master_s, 5); /* listen for requests */ FD_ZERO(&afds); FD_SET(master_s, &afds); /* only respond to requests */ /* on master socket */ for(; ; ) { bcopy(&rfds, &afds, sizeof(rfds)); if (select(64, &rfds, (fd_set *)0, (fd_set *)0, (struct timeval *)0 ) < 0) /* error */

31. Copyright Rudra Dutta, NCSU, Spring, 200331 Example (cont'd) if (FD_ISSET(master_s, &rfds)) { /* request arrived */ new_s = accept(master_s,... ); FD_SET(new_s, &afds); /* now start listening */ } /* to the slave socket */ for(fd=0; fd < 64; fd++){ /* process slave requests */ if(fd != master_s && FD_ISSET(fd, &rfds)) { process_request(fd); if (finished(fd)) FD_CLR(fd, &afds); }

32. Copyright Rudra Dutta, NCSU, Spring, 200332 Multiprotocol Servers (TCP, UDP) Separate servers (e.g., DAYTIME) for UDP and TCP? replication of effort difficult to maintain consumption of resources Multiprotocol servers bind and listen to two sockets; one for TCP, one for UDP use asynchronous I/O ( select() ) to determine when one of the sockets needs a response

33. Copyright Rudra Dutta, NCSU, Spring, 200333 Multiservice Servers (TCP, UDP) Typically, individual server for each service dozens of server processes (daemons) routed, snmpd, in.rlogind, ftpd, mountd, telnetd,... Drawbacks most of the servers rarely receive requests, but consume system resources much of the development effort is the same for each type of server; actual request processing may be trivial Solution: consolidate many services into a single server

34. Copyright Rudra Dutta, NCSU, Spring, 200334 Multiservice Servers (cont’d) Server manages multiple services one port per service UDP dedicate one port for each service handle requests in order received, iteratively port received on identifies service needed TCP dedicate one port per service to listen for connection requests create a socket for each request to concurrently handle connections

35. Copyright Rudra Dutta, NCSU, Spring, 200335 Server Configuration Static configuration configuration file specifies services a server should handle to change services, change configuration file, restart server Dynamic configuration (change services without restarting server) change configuration file, inform server server reads file, starts new services and/or terminates services may use UNIX signals to inform server Signal = a form of asynchronous interprocess communication (i.e., interrupts) may use TCP/IP to inform the server Requires an extra socket don’t terminate existing connections when reconfiguring!

36. Copyright Rudra Dutta, NCSU, Spring, 200336 inetd: the Unix Super Server Internet services daemon – a common solution reads file /etc/inetd.conf Opens sockets, forks processes when requests arrive uses select() to determine what needs attention without blocking process creation overhead (has to call fork() and execve() ) inetd handles several services itself echo daytime time discard

37. Copyright Rudra Dutta, NCSU, Spring, 200337 /etc/inetd.conf File # @(#)inetd.conf 1.24 92/04/14 SMI # # Configuration file for inetd(8). See inetd.conf(5). # # To re-configure the running inetd process, edit this # file, then send the inetd process a SIGHUP. # # Internet services syntax: # # “wait” = iterative execution, “nowait” = concurrent

38. Copyright Rudra Dutta, NCSU, Spring, 200338 /etc/inetd.conf File (cont'd) # Ftp and telnet are standard Internet services. # ftpstreamtcpnowaitroot/usr/etc/in.ftpdin.ftpd telnetstreamtcpnowaitroot/usr/etc/in.telnetdin.telnetd # # Shell, login, exec, comsat and talk are BSD protocols. # shellstreamtcpnowaitroot/usr/etc/in.rshdin.rshd loginstreamtcpnowaitroot/usr/etc/in.rlogindin.rlogind execstreamtcpnowaitroot/usr/etc/in.rexecdin.rexecd comsatdgramudpwaitroot/usr/etc/in.comsatin.comsat talkdgramudpwaitroot/usr/etc/in.talkdin.talkd

39. Copyright Rudra Dutta, NCSU, Spring, 200339 /etc/inetd.conf File (cont'd) # Finger, systat and netstat give out user information which # may be valuable to potential "system crackers." Many sites # choose to disable some or all of these services # to improve security. # fingerstreamtcp nowaitnobody/usr/etc/in.fingerdin.fingerd #systat stream tcp nowaitroot/usr/bin/psps -auwwx #netstat stream tcpnowaitroot/usr/ucb/netstatnetstat -f inet # # Time service is used for clock synchronization. timestreamtcpnowaitrootinternal timedgramudpwaitrootinternal

40. Copyright Rudra Dutta, NCSU, Spring, 200340 Process Preallocation Master opens socket for well-known port creates N slaves each inherits the socket for the well-known port master can then exit Each slave calls accept() when a connection request arrives, one of the slaves is unblocked and handles the connection when finished, it closes connection and calls accept() again Assessment can respond quickly to short requests maximum concurrency level limited to N

41. Copyright Rudra Dutta, NCSU, Spring, 200341 Delayed Process Allocation Tradeoff short processing time favors iterative server long processing time favors concurrent server compromise: start iteratively, switch to concurrent if time becomes “too long” Setting alarms system call specifies when to generate a signal to the process Switching from iterative to concurrent fork() creates exact duplicate of all variables, including open sockets child process can continue from exactly the same point

42. Copyright Rudra Dutta, NCSU, Spring, 200342 Variations and Extensions Client Concurrency One client may communicate with multiple servers simultaneously E.g.: make same request simultaneously to multiple servers, so not delayed if one server is slow or unavailable Client may receive aynsynchronous input from both a user and remote machine simultaneously user may wish to inquire about client status, control processing, … E.g.: telnet client Multilevel client-server Client for one service is server for another Powerful and broad concept