Protocol Notes (RFC0036)
Original Publication Date: 1970-Mar-16
Included in the Prior Art Database: 2001-Jul-11
Internet Society Requests For Comment (RFCs)
I 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 re...