1. 1 Dimension of Server Designs r Iterative vs Concurrent r Connection-oriented vs. connectionless r Stateful and stateless m Constrained by application protocols r Four classes of servers  Iterative, connectionless server ( 37 TIME )  Iterative, connection-oriented server ( 13 DAYTIME )  Concurrent, connectionless server ( 7 ECHO ) m Concurrent, connection-oriented server

2. 2 Server Design Combinations Iterative r simple Concurrent r multi-user ( time slice, multi-core ) r multi-processor, multi-process, multi- thread, async IO r performance Connection (TCP) r reliable pipe r prone to attack r 3 way handshaking (SYN attack) r Nothing going on when idle m resource exhaustion m client crash – unintentional or intentional m memory leak Connectionless (UDP) r simple r fast most app diagnostic programs some app

3. 3 Iterative Server r A simple iterative server m Creates a socket, binds address, and makes it passive m Server accepts a connection, services the request, and closes the connection. This step repeats for each incoming connection r What is the problem with this simple server?

4. 4 master thread Iterative UDP Server addr family port msock port bind server port/addr sendto recvfro m r Other clients block while one request is processed, not for a full connection time r Each subsequent recvfrom can be from a different client r Server identifies client by from_addr r Not reliable, but no connection overhead

5. 5 master thread Iterative TCP Server addr family port addr family port msock port ssock Queue bind liste n accep t client port/addr server port/addr read, write work on new sock until close then, go back to accept three way handshaking disconnect sequence data

6. 6 Iterative, Connection-Oriented Server (1-3) 1. Create a socket r sock = socket (PF_INET, SOCK_STREAM, 0); 2. Bind to a local address r bind (sock, localaddr, addrlen) r For well-known service, use getservbyname (name, protocol) to get port number from service name r Often use wildcard address (INADDR_ANY) for host IP 3. Place socket in passive mode r listen (sock, queuelen) r Need to establish queue length

7. 7 Iterative, Connection-Oriented Server (4) 4. Accepting a connection from a client m new_sock = accept (sock, addr, addrlen); m accept() blocks until there is an incoming request m Based on the queue length specified in listen() call, incoming connection requests may be accepted by the operating system and queued to be accepted later by the application server using accept() m New socket descriptor (new_sock) is used to send and receive messages with the connected client.

8. 8 Iterative, Connection-Oriented Server (5-6) 5. Interact with client using new_sock m Depending on application-level protocol m Send and receive messages using the connected socket send (new_sock,…) or write (new_sock…) recv (new_sock…) or read (new_sock, …) 6. Close the connection and return to step 4 to accept a new connection m close (new_sock)

9. 9 Iterative, Connection-Oriented Server Example r DAYTIME server m Server blocks until a client connects m Client sends no data m time() returns a 32-bit integer that gives the current time in seconds since the Mac epoch m ctime() converts the epoch seconds into human- readable character string m close the connection Is it safe here?

10. 10 Possible Server Deadlocks r A deadlock occurs when m The client waits for the server m The server waits for the client r A simple deadlock Server Client accept () connect () | | recv () recv ()

11. 11 More Server Deadlocks r Deadlocks can happen in a more subtle way r Why deadline in the following scenario? Server Client accept () connect () | | recv () send (BIGBUFFER) | send () ---> | ----

12. 12 Iterative, Connectionless Server Example r TIME server listens at port 37 r recvfrom() to receive the datagram sent by the client m Read only one byte m What about the remaining data? r time() returns the number of seconds in EPOCH r Converting the number of seconds to network byte order before sending to the client!