Movatterモバイル変換

Network Working Group                                         W. NaylorRequest for Comments #143                                     J. WongNIC #6728                                                     C. KlineCategories:  D.1, D.3                                         J. PostelObsoletes:  None                                              UCLA - NMCUpdates:123,145                                            3 May 1971Regarding Proferred Official ICPWe should like to comment on a race condition discovered in the ICP asproposed in NWG/RFC #123.  The problem arises when the server attemptsto initiate a second connection to the user's receive socket and thefirst connection is not yet closed.  Using a similar notation to that ofNWG/RFC #123 the following table illustrates the sequence of events inthe proferred and proposed ICP.  The last two columns indicate whichactions must be completed before the current action may be initiated.User and Server are third level programs, and UNCP and SNCP are theusers NCP and Servers NCP respectively.  Allocates have not beenincluded 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 ICPRFC 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                           3Note that in the Proferred Order column, 16 can occur before 12 in whichcase 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 theconversation.The above problem is resolved by eliminating the Close from one side andcausing that side to wait for the CLS from the other side before doingan Init.  We propose that eliminating the user's Close (U) is the bestsolution.  (The user NCP must of course return a CLS in response to theCLS sent by the server NCP).The Server's Close (L) leads more quickly to the reuse of socket L thusthe serving of another user.                                                                [Page 2]

NWG                 Regarding Proferred Official ICPRFC 143To clarify the above discussion which may seem confusing at firstglance, 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                                   sNotice that since server and user are independent (probably in differenthosts), server could execute (S6) before user executes (U4) and couldreceive an error back from user's NCP that socket U is busy.  Similarly,user could execute (U6) before server executes (S4) and could receive anerror back from his own NCP that socket U is not yet closed (assuming animplementation where sockets are kept busy until a CLS match).Various modifications could be made to ICP to solve this problem.  Wepropose the following ICP:                                                                [Page 3]

NWG                 Regarding Proferred Official ICPRFC 143          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 )                      sThis 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 reconnectionfeatures of RFC #36 been included in the NCP protocol and had dynamicreconnection 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 ]                                                                [Page 4]