RFC 197

Initial Connection Protocol - Reviewed

📅 published July 1971, from ietf

RFC 197: INITIAL CONNECTION PROTOCOL--REVIEWED 🎀

Okay bestie, so this is RFC #197 from the Network Working Group 🦋 It was written by A. Shoshani of SDC and E. Harslem of Rand, got NIC number #7142, and is dated 14 July 1971. It's filed under categories C.3 and D.1. It updates nothing and obsoletes nothing, so it's totally its own main character 💅

INTRODUCTION 🌸

Okay so at the Network meeting right before SJCC '71, they set up an "ICP Committee" 🧚 Its whole purpose was to get "something" working fast, with as few changes to the current ICP as possible so people wouldn't complain. (Honestly, that's a pretty good definition for almost everything, lol 💀) They talked to everyone who had problems with the current ICP, and they landed on a compromise, written up in RFC #165. The committee never got to think about an alternative because of those constraints. So in this note they tried a simple version of an ICP, assuming they could add commands to the Host-Host protocol. They're hoping it helps design the next version of the Host-Host protocol 🫶

ICP COMMANDS 💜

To set up a regular connection, one party can send an INIT (NCP sends RTS or STR commands). Then the other party can accept the request by replying with an INIT, or refuse it with a CLOSE. They think a similar, simple mechanism is desirable for the ICP ✨ They also want the ICP to allow simplex as well as duplex connections from user to server.

The following commands are necessary for simplex connections:

  • ISC - Initiate Simplex Connection
  • ASC - Accept Simplex Connection
  • RSC - Refuse Simplex Connection

The notation for parameters is similar to what RFC #165 uses:

  • L - Server socket name. In one special case the server is "logger".
  • U - User socket.
  • S - Socket assigned by server for the connection with user.
  • X - Is the byte size if U is odd, and is the link number if U is even.
  • X with a dash over it - Is the complement of X. (X is the link number if U is odd, and byte size if U is even.)

To start a simplex connection, the user's NCP issues:

ISC, L, U, X

To refuse this connection, the server's NCP issues:

RSC, L, U

To accept this connection, the server's NCP issues:

                         -
           ASC, L, U, S, X

Similarly, for duplex connections, we have:

           IDC, L, U1, X1, U2, X2

           RDC, L, U1, U2
                           -           -
           ADC, L, U1, S1, X1, U2, S2, X2

where (U1,U2), (S1,S2), (U1,S1) and (U2,S2) are pairs of opposite gender.

After the server accepts the connection(s), it (they) goes immediately to a "connected state", and the appropriate ALL command(s) must be sent. 🔥

ADVANTAGES 👑

The main advantage here is that it minimizes the dialog between user and server. ✨ The server socket L is only used as an address, not as a socket to connect to. That means no need to connect to L, pick a byte size, send an ALL command, send and receive data on it, and then CLOSE it. Race conditions like the ones mentioned in RFC #143 don't come up. Socket L is the server, and it should be in a "Listening for ICP" state when an ISC or IDC is received. If socket L isn't in that state, the serving NCP should refuse the ICP request. The serving NCP should not queue ICP requests. 🙈

In the current ICP, when the user chooses socket U, they have to reserve sockets U+2 and U+3. With the approach described here there are no restrictions on U1 and U2 (other than that they're of opposite gender), and it's the same story for S1 and S2 💅

Duplex commands are necessary because both connections go to the same server process. If you used two ISCs to separate them, you'd have to correlate the two ISCs with that same process, which adds complications. Also, if two ISCs are used, the first might be accepted and the second refused. That leads to uncertainty on the user's part. This can't happen with the duplex commands 😭

MINIMUM MODIFICATION TO CURRENT ICP 🌈

The smallest change they could think of to make the current ICP look more like the above is to add one NCP-level command, accept:

ACC, L, U, S

The exchange between NCPs, in the notation of RFC #165, is now the following. Quick notation check: where the original uses a script lowercase "L," we write "l." Where it uses subscripts, we use braces, so A-subscript-B is printed as A{B}. ✨

     Server NCP                   User NCP
     ----------                   --------

     Listen for connection on L   RST,U,L,l{A}

     ACC,L,U,S                    S is passed by NCP to the
                                  user and connection from
                                  U to L is closed.

     STR,S+1,U+2,B{s}             STR,U+3,S,B{u}

     RTS,S,U+3,l{B}               RTS,U+2,S+1,l{c}

     Wait for connection          Wait for connection

     ALL,l{B},m{B},b{B}           ALL,l{c},m{c},b{c}

There's also an alternative to the ACC command: a CLS command with an extra 32-bit parameter. If the parameter is zero, the user's request for connection is refused. If it's non-zero, the request is accepted, and socket S is the value of the parameter. 🦋

All the suggested changes improve the ICP dialog, both aesthetically and in terms of efficiency. Still, they lean strongly toward the first, more major ICP modification 💖

A COMMENT ABOUT CLS COMMAND 🍓

Okay, it's worth mentioning here, for the next version of the Host-Host protocol, that the CLS command has more than one job. 🙃 They think CLS should be reserved for closing connections in the "connected state" only (aka "open" connections). Two additional commands can be used for "refusing" and "rejecting" connection requests:

  • REJ<mysocket><yoursocket> is used when a request for connection is rejected unconditionally.
  • REF<mysocket><yoursocket><reason> is used when a request for connection is refused temporarily, because the NCP couldn't handle it. For example, no process LISTENed to it and it timed out, or the NCP tables are full, in which case the user process may try again. The reason for refusing is given in the parameter "reason." 🫶

[ This RFC was put into machine readable form for entry into the online RFC archives by BBN Corp. under the direction of Alex McKenzie. 12/96 ] 💜

📦 where this page comes from