Server Algorithms
References for Lecture
Comer Text Chapter 8
Server tasks
Provide a service Conformance to specified protocols Completion
of requests Deal with concurrency problems
- Gather statistics
- Create log entries
Concurrent vs. Iterative Servers
Iterative:
When to use:
- When requests are guaranteed to be completed within a small
amount of time.
Advantage:
- Trivial to implement.
- Easy to serialize accesses to a central database.
Problems:
- Server is locked while dealing with a request. If the request
does take longer than allowed, no other clients can get
service.
Concurrent:
- Many requests at the same time
When to use:
- Most cases where the time taken to complete a request cannot
be limited.
Advantages:
- Individual client requests can be of any complexity and duration
Problems:
- Complexity inherent in concurrent processing.
Connectionless vs. Connection-Oriented Servers
The protocol specifies underlying transport layer needs to be
used.
Connectionless Servers
Advantages:
- Low overhead
- Fewer system-imposed limits on the number of simultaneous
clients
Disadvantages:
- Non-reliable transmission
- Complexity in retransmission (either in the client or server)
Connection-Oriented Servers
Advantages:
- Reliable transmission of data
Disadvantages:
- Overhead in handshaking when setting up the connection
- Separate socket for each connection (limited resource)
- Overhead for protocols which do not require reliable transmission
Stateful vs. Stateless Servers
Statefulness is determined by the Protocol
State requires resources
Stateful protocols make both clients and servers more complicated
Why use state? Interactive protocols:
- Client asks server "can I do this?" and the server
may say "yes" or "no". This response will
then govern when the client will do next. Security:
- Once a connection has been authenticated, the server knows
what rights the client has (POP, FTP, SMTP)
Why not state? If either server the server of client needs
to be restarted without ill effects (NFS, Gopher, HTTP)
Caching Stateless Servers
Example: Reading a file (trivial)
The server gets a request to read a part of this file.
The server:
- opens the file
- seeks to the correct offset in the file
- reads the block
- closes the file.
The file could be kept open by the server and only closes it after
a certain amount of idle time.
Each request to read a block in the file will then only involve:
- seek to the correct offset in the file
- read the block
Other things that can be cached:
- Login information
- Connections to other servers
Basic Server Types
- Iterative, connectionless
- Iterative, connection-oriented
- Concurrent, connectionless
- Concurrent, connection-oriented
Iterative, Connectionless Server
Good enough for non-critical servers
Trivial to implement:
- Create a socket and bind it.
- Repeatedly read requests from the socket
Iterative, Connection-Oriented Server
Never use
Concurrent, Connectionless Server
Use for heavily used services that need quick turnaround (DNS,
NFS)
Concurrent, Connection-Oriented Server
Everything else...
Most standard servers fall into this category
Server Startup
When to use:
- Infrequent services
- Trivial services (implemented using limited languages such
as sh or tcl)
- When system resources are too low to run as a daemon
When NOT to use:
- Heavily used services.
- Services that require state
- Services that cache
command line (manual starting)
When to use:
- During development
- A use-once service
- When user interaction is required
When NOT to use:
- Critical services (remember power failures?)
When to use:
- Permanent services
- Frequently used services
- Services that require fast request processing
When NOT to use:
- When user interaction is required
- When system resources are too low to support it