Client-Server Interfaces Class Notes

Lecture Notes for Client-Server Interfaces

5 February 2002 - Iterative Servers

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, requester <- read(listener)
  reply <- f(request)
  write(request or, reply)
```
5. not only the request, but the request or
iterative datagram servers
1. single socket, the listener
2. generally, the listener is incomplete - no receive side
3. requester address - from recvfrom(), to sendto()
4. ```
listener <- socket()
bind(listener, local)
loop
  request, requester <- recvfrom(listener)
  reply <- f(request)
  sendto(listener, reply, requester)
```
iterative byte-stream servers
1. multiple sockets - the listener, and one per requester
2. the listener is incomplete, but it is not used to communicate with requesters
3. each requester 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)
```
iterative server refinements - 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
5. http 1.0 didn't do this, http 1.1 does it (optionally)
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 arrival rate and service time
  2. look at the cost of late or ignored requests

This page last modified on 5 February 2002.