Initial Connection Protocols
We wish to make two points concerning specific Initial Connection Protocols (IPCs). Firstly, the IPC described in NEW/RFC #66--its generality and a restatement of that ICP. Secondly, a proposal for a variant ICP using basically the same logic as NWG/RFC #66.
I. NWG/RFC #66
The only technical error in this IPC is that as diagrammed both the Server and User send ALL messages before the connections are established which is inconsistent with Network Document No. 1. This can easily be remedied as will be shown in the restatement below.
In terms of generality, any ICP that is adopted as a standard should apply to more situations than a process calling a logger. That is, some Network service processes that hook directly to a user process, independent of logger action, could perhaps use a standard ICP. Thus, as is shown below, the process name field of the server socket should be a parameter with a value of zero being a special case for loggers.
Restatement of NWG/RFC #66 (using the same wording where appropriate)
- To initiate contact, the using process attaches a receive socket (US) and requests connection to process SERV socket #1 in the serving HOST. (SERV = 0 for ICP to the logger.) As a result the using NCP sends:
1 4 3 1 1
+-----+---------------------+---------------+-----+-----+
| RTS | US | SERV | 1 | P |
+-----+---------------------+---------------+-----+-----+
over link 1, where P is the receive link.
- The serving process (SERV) may decide to refuse to the call, in which case it closes the connection. If it accepts the call, the serving process completes the connection (via an INIT system call, hence an STR).
1 3 1 4
+-----+----------------+-----+--------------------+
| STR | SERV | 1 | US |
+-----+----------------+-----+--------------------+
- When the connection is completed, the user process allocates a nominal amount of space to the connection, resulting in the NCP sending:
1 1 4
+-----+-----+--------------------+
| ALL | P | SPACE |
+-----+-----+--------------------+
where SPACE is the amount.
-
The serving process then selects the socket pair it wishes to assign this user. It sends exactly an even 32 bit number over the connection. This even 32 bit number (SS) is the receive socket in the serving HOST. This socket and the next higher numbered socket are reserved for the using process.
-
It then closes the connection. The serving NCP sends (step 4):
4
+---------------------+
| SS |
+---------------------+
on link P, and (step 5):
1 3 1 4
+-----+----------------+-----+--------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+--------------------+
on the control link (which is echoed by the using NCP).
- Now that both server and user are aware of the remote socket pair for the duplex connection, <STR, RTS>s can be exchanged.
Sever sends User
1 4 4
+-----+--------------------+--------------------+
| STR | SS + 1 | US |
+-----+--------------------+--------------------+---+
| RTS | SS | SS + 1 | Q |
+-----+--------------------+--------------------+---+
where Q is the Server's receive link.
User sends Server
1 4 4
+-----+--------------------+--------------------+
| STR | US + 1 | SS |
+-----+--------------------+--------------------+---+
| RTS | US | SS + 1 | R |
+-----+--------------------+--------------------+---+
where R is the User's receive link.
ALLocates may then be sent and transmission begun.
II. A Variation of NWG/RFC #66
This variation reduces Network messages and eliminates duplication of information transfer.
Steps 3 and 4 above are deleted. The user process is not notified directly which of the Server's sockets it will be assigned. The user process, however, will listen on sockets US and US + 1 for calls from SERV after step 5 above. It can reject any spurious calls. In accepting the calls from SERV, the connection is established.
The following sample sequence illustrates this ICP. (The notation is as above).
- User --> Server
1 4 3 1 1
+-----+--------------------+----------------+-----+-----+
| RTS | US | SERV | 1 | P |
+-----+--------------------+----------------+-----+-----+
- Server --> User
If accepted:
1 3 1 4
+-----+----------------+-----+---------------------+
| STR | SERV | 1 | US |
+-----+----------------+-----+---------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+---------------------+
If rejected:
1 3 1 4
+-----+----------------+-----+---------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+---------------------+
-
If accepted, user listens on US and US + 1.
-
Server --> User
1 4 4
+-----+--------------------+---------------------+
| STR | SS + 1 | US |
+-----+--------------------+---------------------+---+
| RTS | SS | US + 1 | Q |
+-----+--------------------+---------------------+---+
- User accepts the calls, hence:
User --> Sender
1 4 4
+-----+---------------------+--------------------+
| STR | US + 1 | SS + 1 |
+-----+---------------------+--------------------+---+
| RTS | US + 1 | SS | R |
+-----+---------------------+--------------------+---+
and the connection is established.
This reduces the number of network messages by two and only passes the information regarding the Server's sockets once via RTS and STR.