RFC 467 (rfc467) - Page 3 of 7
Proposed change to Host-Host Protocol: Resynchronization of connection status
Alternative Format: Original Text Document
RFC 467 February 1973 2.) Wait until the message pipeline is empty, i.e. until a RFNM has been received for each regular message sent over this connection. This synchronizes the control and data activity, and also assures that the data stream will not be corrupted during the control re-synchronization exchange. 3.) Send the RCS command. 4.) Continue to process allocates normally, updating the variables which indicate outstanding bit and message allocation. When the receiving NCP receives the RCS, it should: 1.) Zero the variables indicating outstanding bit and message allocation. 2.) Reset the connection to the state which indicates readiness to accept a message. 3.) Confirm the re-synchronization by sending the RCR reply. 4.) Reconsider bit and message allocation, and send an ALL command for any allocation it cares to do. When the sending host receives the RCR reply, it should: 1.) Zero the variables indicating outstanding bit and message allocate. 2.) Put the connection into the "ready-to-send-message" state in preparation for any forthcoming ALL commands. At this point, the "pipeline" contains no messages and no allocates, and the outstanding allocation variables at both ends are in agreement. (With value zero) IV. Resynchronization By Receiver The re-synchronization sequence may be triggered by the receiving NCP. Such resynchronization could be initiated manually by TIP and TELNET users who are expecting output but receiving none. Again assuming that allocation has been lost, the appropriate action is to reset the connection by sending an RCR command. This action is also appropriate if an inconsistent event occurs with respect to the connection. (e.g. arrival of a message which exceeds allocation). Burchfiel
