1. why stop at transport protocols - combine application protocols too

2. in theory, the same advantages accrue

   1. in addition, amortize the cost of offering many services over one server

   2. possibly simplify service implementations

   3. but

      1. a point of failure

      2. increased complexity - servers implement application protocols

      3. greater sensitivity to changes in services

3. architectural issues

   1. mapping and running

   2. mapping - which services are offered through which listeners

      1. establishing, discovering, and responding to changes

   3. running - providing the discovered service

   4. affect on service architecture - how to hand-off

4. multi-service server designs

   1. a multiplicity of listener sockets

   2. a multiplicity of services

   3. complexity - doing several simple things at the same time in the same place

   4. how to control complexity - box and isolate; box what, isolate how

      1. box listener control and each service (and possibly each protocol)

      2. isolation depends on server architecture

   5. don't forget to re-integrate the isolated boxes

   6. concurrency - within a service, between services

   7. connectionless, iterating server

      1. simplest, assuming classic, stateless client-server communication

   8. connection-oriented, iterating server

      1. about the same as connectionless, but service time becomes an issue

      2. multiplexing between listener and active sockets

   9. connectionless, concurrent server

      1. is this a good idea

      2. thread concurrency - have a thread per listener; listener thread dispatches

      3. fork concurrency - is this a good idea

   10. connection-oriented, concurrent server

       1. pretty much like connectionless

   11. breaking the monolith

       1. multi-service servers contain way too much code - move services into separate programs

       2. each server request is handled by a separate program

       3. fork concurrency a must - followed by some form of exec()

       4. why bother - central control, decentral work; reduce change sensitivity

   12. don't forget multi-protocol, multi-service servers either

   13. configuring multi-service servers

       1. configuration includes service, address, and protocol

       2. static configuration - kill the old, start the new

       3. dynamic configuration - when is this possible

          1. turn services on and off, set new parameter or argument values

          2. with dynamic libraries, add new services

          3. need a configuration file or special configuration port (danger!)

          4. informing the server - polling or interrupts

5. example - inetd

   1. a unix-standard (sorta) multi-service, multi-protocl server

   2. dynamic - /etc/inetd.conf

   3. configuration indicates service name, tli and protocol, concurrency, execution owner, program and arguments

   4. sockets are remapped to std-in, std-out, and std-err

This page last modified on 27 April 2001.