Regarding proffered official ICP
RFC 143

Document Type RFC - Unknown (May 1971; No errata)
Obsoleted by RFC 165
Updates RFC 123, RFC 145
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 143 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         W. Naylor
Request for Comments #143                                     J. Wong
NIC #6728                                                     C. Kline
Categories:  D.1, D.3                                         J. Postel
Obsoletes:  None                                              UCLA - NMC
Updates:  123, 145                                            3 May 1971

                    Regarding Proferred Official ICP

We should like to comment on a race condition discovered in the ICP as
proposed in NWG/RFC #123.  The problem arises when the server attempts
to initiate a second connection to the user's receive socket and the
first connection is not yet closed.  Using a similar notation to that of
NWG/RFC #123 the following table illustrates the sequence of events in
the proferred and proposed ICP.  The last two columns indicate which
actions must be completed before the current action may be initiated.
User and Server are third level programs, and UNCP and SNCP are the
users NCP and Servers NCP respectively.  Allocates have not been
included since they add nothing 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

                                                                [Page 1]
NWG                 Regarding Proferred Official ICP             RFC 143

                                               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

Note that in the Proferred Order column, 16 can occur before 12 in which
case UNCP would find socket U in use and probably return a CLS (U,S+1).
The Server would probably then assume the User was finished with the
conversation.

The above problem is resolved by eliminating the Close from one side and
causing that side to wait for the CLS from the other side before doing
an Init.  We propose that eliminating 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) leads more quickly to the reuse of socket L thus
the serving of another user.

                                                                [Page 2]
NWG                 Regarding Proferred Official ICP             RFC 143

To clarify the above discussion which may seem confusing at first
glance, let us demonstrate the problem in 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 since server and user are independent (probably in different
Show full document text