Lecture Notes for Client-Server Interfaces

30 January 2001 - Iterative Servers

1. basics

   1. the server itself responds to each request - single threaded, non concurrent (one at a time)

   2. undemanding services - short, not resource intensive

   3. general structure

   4. listener <- socket()
      loop
        request, requestor <- read(listener)
        reply <- f(request)
        write(requestor, reply)
      

   5. not only the request, but the requestor

2. iterative datagram servers

   1. single socket, the listener

   2. generally, the listener is incomplete - no receive side

   3. requestor address - from recvfrom(), to sendto()

   4. listener <- socket()
      bind(listener, local)
      loop
        request, requestor <- recvfrom(listener)
        reply <- f(request)
        sendto(listener, reply, requestor)
      

3. iterative stream servers

   1. multiple sockets - the listener, and one per requestor

   2. the listener is incomplete, but it is not used to communicate with requestors

   3. each requestor socket is complete

   4. listener <- socket()
      bind(listener)
      listen(listener)
      loop 
        connection <- accept(listener)
        request <- read(connection)
        reply <- f(request)
        write(connection, reply)
        close(connection)
      

   5. multiplexing

      1. keep connections open over many iterations - amortize set-up and tear-down costs

      2. reads are blocking - need a way to pick the sockets that have data available

      3. non-blocking reads, select(), poll()

      4. when to close a connection

4. discussion

   1. good - simple implementation; reasonably fast; not cpu, process resource heavy

   2. bad - easy stream server dos attacks; multiplexed stream servers can get complex

   3. when to use

      1. look at expected inter-arrival rate and service time

      2. look at the cost of late or ignored requests

This page last modified on 1 February 2001.