Protocol Notes (RFC0036)
Original Publication Date: 1970-Mar-16
Included in the Prior Art Database: 2001-Jul-11
Internet Society Requests For Comment (RFCs)
AbstractI Overview --------
Network Working Group S. Crocker Request for Comments: 36 16 March 1970
The network protocol provides three facilities:
1. Connection establishment
2. Flow control
Reconnection is considered separately from connection establishment partly because of the complexity of reconnection and partly because I don't have enough experience with the protocol to present these concepts in an integrated fashion.
Connection establishment works essentially the same as in NWG/RFC #33. The major change is that a more general form of switching is provided independently of establishment, so establishment is simplified by not including switching procedures.
A rough scenario for connection establishment follows:
1. Process PA in host A grabs socket SA and requests connection with
socket SB. Process PA accomplishes this through a system call.
2. Concurrently with the above, process PB in host B grabs socket SB
and requests connection with socket SA.
3. In response to process PA's request, the network control program in host A (referred to as NCPA) sends a Request-for-Connection (RFC) command to host B. NCPB in host B sends a similar command to host A. No ordering is implied: NCPB may send the command to NCPA before or after receiving the command from NCPA.
4. NCPA and NCPB are both aware the connection is established when each has received a RFC command and each has received the RFNM for the one it has sent. They then notify processes PA and PB, respectively, that the connection is established.
Crocker [Page 1]
RFC 36 Protocol Notes March 1970
One of the rules adhered to is that either SA is a send socket and SB is a receive socket or vice versa. This condition is sometimes stated as "SA and SB must be a send/receive pair."
5. The sending process may now send.
In order to prevent a sending process from flooding a receiving processes it is necessary for the receiving process to be able to stop the flow(*). Flow control is integrated into the network RFNM handling. When a receiving host wishes to inhibit flow on a particular link, the host sends a special message to its IMP which causes the next RFNM on that link to be modified. The sending host interprets this message as a RFNM and as a request to stop sending. A confirming control command is returned.
When the receiving host is ready to receive again, it sends a command (RSM) telling the sending host to resume sending.
For a great many reasons it is desirable to be able to switch one (or both) ends of a connection from one socket to another. Depending upon the restrictions placed upon the switching process, it may be easy or hard to implement. To achieve maximum generality, I present here a scheme for dynamic reconnection, which means that reconnection can take place even after flow has started. It may turn out that for the majority of cases, this scheme is much more expensive than it needs to be; however, the following virtues are claimed:
1. All variou...