RFC 143

Regarding Proferred Official ICP 💖

Okay bestie, RFC 143 is here 🎀 It was written by W. Naylor, J. Wong, C. Kline, and J. Postel from UCLA - NMC (NIC #6728) and dated 3 May 1971 🧚 It's filed under categories D.1 and D.3, it obsoletes none, and it updates 123 and 145 ✨

So the tea is that we need to flag a race condition we spotted in the ICP proposed in NWG/RFC #123 👀 It happens when the server tries to start a second connection to the user's receive socket while the first one still isn't closed 🙈 That's a whole mess, ngl.

Using a similar notation to NWG/RFC #123, the table below shows the order of events in the proferred and proposed ICP 💅 The last two columns say which actions must be completed before the current one may be initiated. User and Server are third level programs (the big stuff 🧠), and UNCP and SNCP are the user's NCP and the server's NCP respectively. We left out the Allocates since they don't add anything to the argument 🙅‍♀️

                                               Required Predecessors
                                               ---------------------
Reference #   Action              Initiator   "Proferred"   Proposed
-----------   ------              ---------   -----------   --------
    1         Listen(L,32)        Server           --          --

    2         Init(U,L,32)        User             --          --

    3         RTS(U,L,'l')        UNCP             2           2

    4         STR(L,U,32)         SNCP          1 and 3     1 and 3

    5         Send(L,S)           Server           4           4

    6         SEND('l',S)         SNCP             5           5

    7         RECEIVE('l',S)      UNCP             6           6

    8         Receive(U,S)        User             7           7

    9         Close(L)            Server           5           5

   10         CLS(L,U)            SNCP          9 and 7     9 and 7

   11         Close(U)            User             8        not used

   12         CLS(U,L)            UNCP            11          10

                                               Required Predecessors
                                               ---------------------
Reference #   Action              Initiator   "Proferred"   Proposed
-----------   ------              ---------   -----------   --------

   13         Init(S,U+1,B )      Server           9           9
                          u

   14         RTS(S,U+1,'l' )     SNCP            13          13
                           2

   15         Init(S+1,U,B )      Server          13        14 and 18
                          s

   16         STR(S+1,U,B )       SNCP            15          15
                         s

   17         Init(U+1,S,B )      User            11          12
                          u

   18         STR(U+1,S,B )       UNCP            17          17
                         u

   19         Init(U,S+1,B )      User            17          17
                          s

   20         RTS(U,S+1,'l' )     UNCP            19          19
                           3

Now look at the Proferred Order column. 16 can happen before 12, and then UNCP finds socket U still in use and will probably return a CLS (U,S+1) 😬 The Server would probably then assume the User was done with the conversation 💀

The fix is to drop the Close from one side and make that side wait for the CLS from the other side before doing an Init ✨ We propose that dropping the user's Close (U) is the best solution 👑 (The user NCP must of course return a CLS in response to the CLS sent by the server NCP.)

The Server's Close (L) reuses socket L faster, which means it can serve another user sooner 🚀

To make this less confusing, let's show the problem using the language of RFC #123 🫶

          Server                              User
          ------                              ----
     (S1) Listen(L,32)                   (U1) Init(U,L,32)

     (S2) [Wait for match]               (U2)

     (S3) Send(L,S)                      (U3) Receive(U,S)

     (S4) Close(L)                       (U4) Close(U)

     (S5) Init(S,U+1,B )                 (U5) Init(U+1,S,B )
                      u                                   u

     (S6) Init(S+1,U,B )                 (U6) Init(U,S+1,B )
                      s                                   s

Notice that the server and the user are independent (probably on different hosts) 🌸 So the server could run (S6) before the user runs (U4), and then get an error back from the user's NCP saying socket U is busy 😭 It can also go the other way: the user could run (U6) before the server runs (S4), and then get an error back from its own NCP saying socket U isn't closed yet (assuming an implementation where sockets stay busy until a CLS match) 🙈

There are a bunch of ways to tweak the ICP to fix this. We propose the following ICP 💖

          Server                              User
          ------                              ----
          Listen(L,32)                        Init(U,L,32)

          [Wait for match]

          Send(L,S)                           Receive(U,S)

          Close(L)                            [Wait for CLS]

          Init(S,U+1,B )                      Init(U+1,S,B )
                      u                                   u

          [Wait for match]                    Init(U,S+1,B )
                                                          s

          Init(S+1,U,B )
                      s

This ICP assumes the following:

1. The user can inquire or is notified of the fact that one of his connections has been closed.
2. The server can inquire or is notified that a connection for which he has done an Init (or Listen) is now open.

Both of the above seem basic to any NCP-user interface 🧚

This race condition problem would not exist had the dynamic reconnection features of RFC #36 been included in the NCP protocol and had dynamic reconnection been used in this ICP. 🦋

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Walter Pienciak 1/98 ]