Dimension of Server Designs

1
Dimension of Server Designs

• Iterative vs Concurrent
• Connection-oriented vs. connectionless
• Stateful and stateless
• Constrained by application protocols
• Four classes of servers
• Iterative, connectionless server (37 TIME )
• Iterative, connection-oriented server (13 DAYTIME
  )
• Concurrent, connectionless server (7 ECHO )
• Concurrent, connection-oriented server

2
Server Design Combinations

• Concurrent
• multi-user (time slice, multi-core)
• multi-processor, multi-process, multi-thread,
  async IO
• performance

• Iterative
• simple

diagnosticprograms
some app
most app

• Connection (TCP)
• reliable pipe
• prone to attack
• 3 way handshaking (SYN attack)
• Nothing going on when idle
• resource exhaustion
• client crash unintentional or intentional
• memory leak

• Connectionless (UDP)
• simple
• fast

3
Iterative Server

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

4
Iterative UDP Server
master thread

• Other clients block while one request is
  processed, not for a full connection time
• Each subsequent recvfrom can be from a different
  client
• Server identifies client by from_addr
• Not reliable, but no connection overhead

recvfrom
msock
server port/addr
sendto
bind
port
5
Iterative TCP Server
master thread
accept
client port/addr
listen
work on new sock until closethen, go back to
accept
msock
server port/addr
ssock
Queue
read, write
bind
port
three way handshaking
disconnect sequence
data
6
Iterative, Connection-Oriented Server (1-3)

• Create a socket
• sock socket (PF_INET, SOCK_STREAM, 0)
• Bind to a local address
• bind (sock, localaddr, addrlen)
• For well-known service, use getservbyname (name,
  protocol) to get port number from service name
• Often use wildcard address (INADDR_ANY) for host
  IP
• Place socket in passive mode
• listen (sock, queuelen)
• Need to establish queue length

7
Iterative, Connection-Oriented Server (4)

• 4. Accepting a connection from a client
• new_sock accept (sock, addr, addrlen)
• accept() blocks until there is an incoming
  request
• 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()
• New socket descriptor (new_sock) is used to send
  and receive messages with the connected client.

8
Iterative, Connection-Oriented Server (5-6)

• 5. Interact with client using new_sock
• Depending on application-level protocol
• 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
• close (new_sock)

9
Iterative, Connection-Oriented Server Example

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

10
Possible Server Deadlocks

• A deadlock occurs when
• The client waits for the server
• The server waits for the client
• A simple deadlock

Server Client accept ()
lt-----gt connect ()
recv () recv ()
11
More Server Deadlocks

• Deadlocks can happen in a more subtle way
• Why deadline in the following scenario?

Server Client accept ()
lt-----gt connect ()
recv () send
(BIGBUFFER) send ()
---gt ----
12
Iterative, Connectionless Server Example

• TIME server listens at port 37
• recvfrom() to receive the datagram sent by the
  client
• Read only one byte
• What about the remaining data?
• time() returns the number of seconds in EPOCH
• Converting the number of seconds to network byte
  order before sending to the client!