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