II. Host Up and Host Down
Significant problems can arise when a host goes down and then attempts to restart. Two cases can easily be distinguished. The first is a "soft" crash, where the system has prior notice that the machine is going down; sufficient time is available to execute pre-recovery procedures. The other case can be termed a "hard" crash, often the result of a system failure. Insignificant warning is usually given; but more important, the state of the machine after recovery is rarely predictable.
When a host returns from a hard crash, the network will be in an undefined state. Very probably the NCP's data structures are destroyed or are meaningless. The network has declared the host dead -- but only to processes which attempted data transmission and were refused. The only alternative for the crashed host is re-initialization of its tables. What are the alternatives for the foreign hosts?
We would like to propose the addition of two control commands: RESET (RST) and RESET REPLY (RSR). Each would consist solely of an op code with no parameters. Upon receipt of an RST, a host would immediately terminate all connections with the sending host, but would not issue any CLS's. The receiver of the RST would also note that the originator of the RST was alive, and would then echo an RSR to the sender. When a host receives an RSR, he sould then note that the echoing host is alive. (The function of RST can be partially simulated if a host will immediately close all relevant table entries upon discovering that another host is down.)
Thus, after a hard crash, all connections and request for connections are terminated. The RST also informs all foreign hosts that we are again alive, and an RSR is received from every functioning NCP. A host live table (see NWG/RFC #55) can easily be assembled, and establishment of connections can resume.
Related problems also crop up when we consider attempting to synchronize the network, which may still be carrying messages generated prior to the crash, with an NCP which has an initialized environment. We lack the facilities for unblocking links, discarding messages, etc. -- facilities which this proposal will necessitate. Further interaction with BBN should resolve these difficulties.
The problems associated with "soft" crashes are not nearly as pressing, and they demand more sophisticated (i.e., complex) solutions. Our preliminary experimentation with the network demonstrates that a good initialization and recovery protocol are far more necessary.
Many of the ideas presented herin wre germinated and/or jelled through conversations with Steve Crocker and Jon Postel. We would also like to acknowledge the assistance of Jim Balter and Charles Kline of UCLA, who devoted a great deal of effort toward helping develop the pseudo-Algol program which was the predecessor of much of our recent documentation.
Note: This RFC was put into machine readable form for entry into the online RFC archives by Katsunori Tanaka 2/98.