Previous: Channel Server Protocols
Up: Channel Server
Next: Protocol MIC-0 - The interface to the CCS
Previous Page: Channel Server Protocols
Next Page: Protocol MIC-0 - The interface to the CCS

Implementation and Failure Modes

For ease of testing, for fault diagnosis, and for portability, all these protocols are to be implemented using plain text over a TCP connection. This allows a particular connection to be tested manually using "telnet". If an invalid command is received, it should simply be ignored. All servers should be resistant to mistyped or other invalid commands. The channel server will never initiate a connection - it is always the responsibility of the other system to do this. Similarly it is the responsibility of the other system to terminate a connection.

In general, writes to the channel server should be blocking with a timeout, as if the channel server fails to deal with the request, there has clearly been an irrecoverable problem. If a write fails, the other system should attempt to reinitiate it's connection periodically.

Channel server writes should be non-blocking, in order to prevent the channel server locking up on a write to a dead end-system. This means that the channel server must keep state about which end systems it thinks are alive and in a known state. If a connection to a "presumed-dead" end system is re-established, the end system should be reinitialised as if the connection was a new connection.



Previous: Channel Server Protocols
Up: Channel Server
Next: Protocol MIC-0 - The interface to the CCS
Previous Page: Channel Server Protocols
Next Page: Protocol MIC-0 - The interface to the CCS

[email protected]
Mon Jan 10 18:40:57 GMT 1994