Network Working Group Richard Schantz
RFC # 671 BBN-TENEX
NIC # 31439 December 6, 1974
A Note on Reconnection Protocol
INTRODUCTION
This note documents the experience we have had in implementing a
modified, experimental version of the Telnet reconnection protocol
option within the context of the Resource Sharing Executive (RSEXEC).
The reconnection protocol specifies a procedure for transforming a
configuration from one in which the initiating process has
connections to two correspondent processes, to one in which there is
a direct connection between the correspondents. When the procedure is
successfully completed, the initiating process is no longer in the
communication path between the correspondents.
Resource sharing computer networks and distributed computing will
increasingly give rise to specialization by task among the computer
installations. In such an environment, a "job" is the dynamically
varying interconnection of a subset of these specialized modules.
Connections are the "glue" in "bonding" the job together.
Reconnection provides for a dynamically changing "bonding" structure.
(For a more complete discussion of the utility of reconnection, see
RFC 426).
This document deals with reconnection in terms of its current ARPANET
definition as a Telnet protocol option. The first section defines a
modified reconnection protocol. The second section discusses general
network implementation details, while the final section describes
aspects of the TENEX/RSEXEC implementation.
Familiarity with the new ARPANET Telnet protocol (RFC 495) is
assumed.
I. PROTOCOL for RECONNECTING TELNET COMMUNICATION PATHS
A process initiates the reconnection of two of its Telnet connections
by sending (or requesting its "system" to send) the
Telnet command sequence over each of the two
send connections. The process initiating the reconnection is
attempting to cause the direct connection of the objects of the two
Telnet connections. In this manner, the initiating process can remove
itself from the communication path between Telnet objects.
Schantz [Page 1]
RFC 671 A Note on Reconnection Protocol December 1974
The initiating process awaits positive responses to both reconnection
requests before proceeding further with the reconnection. A
reconnection request may be accepted by replying with the Telnet
sequence . It may be rejected by sending the
Telnet sequence . Rejection of both requests
means normal communication may resume at once. Rejection of one
request (but not the other) requires that the process agreeing to the
reconnection be notified by sending it the Telnet sequence
in response to its acceptance reply.
After receiving positive responses to both requests, the initiating
agent next selects the object of one of the Telnet connections for a
passive role in the subsequent connection attempt. The other is
designated as the active participant. The passive participant is to
listen on a set of sockets, and the active participant is to send
Request for Connections (RFCs) for those sockets. By designating
roles, we are trying to reduce the probability of synchronization
problems.
The initiating process next enters into subnegotiation with the
process designated as being passive. This subnegotiation involves
sending the Telnet sequence . The parameter indicates that the recipient is to
listen for RFCs from the socket pair denoted by . The "NEWHOST" is one 8-bit byte designating the
address of the host on which the active process (i.e., the one to
reconnect to) resides. NEWSOCKET1-4 are four 8-bit bytes indicating
the 32-bit send socket number of the Telnet pair from the active
process. The fields terminate the subnegotiation
parameters. The initiating agent awaits a response from the passive
process before proceeding. The legal responses are:
1) Telnet sequence (RECONNECT>
Meaning: The passive process has decided not to complete the
reconnection, after having initially indicated willingness. This
may be due to unexpected parameters during the subnegotiation
(e.g., it refuses to connect to NEWHOST), or perhaps some error
condition at the passive host.
2) Telnet sequence Meaning: Positive acknowledgement of the subnegotiation
sequence. The passive process has accepted the reconnection
parameters and will proceed with reconnection.
Schantz [Page 2]
RFC 671 A Note on Reconnection Protocol December 1974
If the reply was , the initiator is obliged to send
the Telnet to the active participant, to
cancel the outstanding reconnection request. A confirming
should follow.
The reply means that the passive participant has begun its
connection shutdown, and will listen on the appropriate sockets. The
initiator may now close its connections to the passive participant
and supply the parameters to the active participant. This can be
done with the assurance that it (the initiator) has done all it can
to ensure that the passive process listens before the active process
sends its RFCs. Failure to coordinate these actions may result in the
failure of the reconnection, if, for example, the passive host does
not queue unmatched RFCs. Persistence on the part of the active
participant should be an integral part of the protocol, due to
uncertainties of synchronization.
The parameter list sent to the active participant is the Telnet
sequence . The parameter indicates to the recipient that it is to send RFCs to the
socket pair denoted by . The initiator again
waits for a reply. The legal replies are:
1) Telnet sequence Meaning: Process will not complete the reconnection (e.g., it
couldn't parse the parameter string).
Possible action of initiator: Attempt to re-establish
communication with the passive participant by sending RFCs for
the sockets on which the passive participant is listening. This
will succeed if the listener is willing to accept connections
from either the host/socket specified by the reconnect
parameters or the host/socket of the former connection. If it is
successful in reestablishing the connection, the initiator could
send the Telnet sequence to confirm that
reconnection has been aborted.
2) Telnet sequence Meaning: Positive confirmation of the reconnection
subnegotiation. The active participant indicates with this reply
that it will close the connections to the initiator and send the
necessary RFCs to connect to the passive participant. The
initiator may close the connections to the active participant,
thereby removing itself from the communication path between the
objects of the reconnection.
Schantz [Page 3]
RFC 671 A Note on Reconnection Protocol December 1974
DEFAULT CONDITIONS and RACES
The default for this option is as for most other Telnet options: DONT
and WONT. An initiator uses the Telnet sequence to
return to the default state, while a participant uses
to maintain or return to the default state. The
reconnection state is only a transient one. When accepted by all
parties, the reconnection state lasts only until the reconnection is
completed. Upon completion, and without further interaction among the
parties, the state of the new connection is the default state, with
the negotiated reconnection forgotten.
Since reconnection is an option concerning the entire Telnet
connection, the asynchronous nature of the option processing
mechanism exemplified by many other Telnet options (e.g., echo), is
not applicable. That is, a race condition occurs when two
requests cross each other in the network. A
solution to this problem was presented in RFC 426; the following is a
modified version of that protocol extension. The modification is
concerned mainly with preserving the right of a process to deny a
reconnection attempt by another process, while having its own
reconnection request pending.