home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0143.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  6.8 KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         W. Naylor
  8. Request for Comments #143                                     J. Wong
  9. NIC #6728                                                     C. Kline
  10. Categories:  D.1, D.3                                         J. Postel
  11. Obsoletes:  None                                              UCLA - NMC
  12. Updates:  123, 145                                            3 May 1971
  13.  
  14.                     Regarding Proferred Official ICP
  15.  
  16. We should like to comment on a race condition discovered in the ICP as
  17. proposed in NWG/RFC #123.  The problem arises when the server attempts
  18. to initiate a second connection to the user's receive socket and the
  19. first connection is not yet closed.  Using a similar notation to that of
  20. NWG/RFC #123 the following table illustrates the sequence of events in
  21. the proferred and proposed ICP.  The last two columns indicate which
  22. actions must be completed before the current action may be initiated.
  23. User and Server are third level programs, and UNCP and SNCP are the
  24. users NCP and Servers NCP respectively.  Allocates have not been
  25. included since they add nothing to the argument.
  26.  
  27.                                                Required Predecessors
  28.                                                ---------------------
  29. Reference #   Action              Initiator   "Proferred"   Proposed
  30. -----------   ------              ---------   -----------   --------
  31.     1         Listen(L,32)        Server           --          --
  32.  
  33.     2         Init(U,L,32)        User             --          --
  34.  
  35.     3         RTS(U,L,'l')        UNCP             2           2
  36.  
  37.     4         STR(L,U,32)         SNCP          1 and 3     1 and 3
  38.  
  39.     5         Send(L,S)           Server           4           4
  40.  
  41.     6         SEND('l',S)         SNCP             5           5
  42.  
  43.     7         RECEIVE('l',S)      UNCP             6           6
  44.  
  45.     8         Receive(U,S)        User             7           7
  46.  
  47.     9         Close(L)            Server           5           5
  48.  
  49.    10         CLS(L,U)            SNCP          9 and 7     9 and 7
  50.  
  51.    11         Close(U)            User             8        not used
  52.  
  53.    12         CLS(U,L)            UNCP            11          10
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. NWG                 Regarding Proferred Official ICP             RFC 143
  61.  
  62.  
  63.                                                Required Predecessors
  64.                                                ---------------------
  65. Reference #   Action              Initiator   "Proferred"   Proposed
  66. -----------   ------              ---------   -----------   --------
  67.  
  68.    13         Init(S,U+1,B )      Server           9           9
  69.                           u
  70.  
  71.    14         RTS(S,U+1,'l' )     SNCP            13          13
  72.                            2
  73.  
  74.    15         Init(S+1,U,B )      Server          13        14 and 18
  75.                           s
  76.  
  77.    16         STR(S+1,U,B )       SNCP            15          15
  78.                          s
  79.  
  80.    17         Init(U+1,S,B )      User            11          12
  81.                           u
  82.  
  83.    18         STR(U+1,S,B )       UNCP            17          17
  84.                          u
  85.  
  86.    19         Init(U,S+1,B )      User            17          17
  87.                           s
  88.  
  89.    20         RTS(U,S+1,'l' )     UNCP            19          19
  90.                            3
  91.  
  92. Note that in the Proferred Order column, 16 can occur before 12 in which
  93. case UNCP would find socket U in use and probably return a CLS (U,S+1).
  94. The Server would probably then assume the User was finished with the
  95. conversation.
  96.  
  97. The above problem is resolved by eliminating the Close from one side and
  98. causing that side to wait for the CLS from the other side before doing
  99. an Init.  We propose that eliminating the user's Close (U) is the best
  100. solution.  (The user NCP must of course return a CLS in response to the
  101. CLS sent by the server NCP).
  102.  
  103. The Server's Close (L) leads more quickly to the reuse of socket L thus
  104. the serving of another user.
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.                                                                 [Page 2]
  115.  
  116. NWG                 Regarding Proferred Official ICP             RFC 143
  117.  
  118.  
  119. To clarify the above discussion which may seem confusing at first
  120. glance, let us demonstrate the problem in the language of RFC #123.
  121.  
  122.           Server                              User
  123.           ------                              ----
  124.      (S1) Listen(L,32)                   (U1) Init(U,L,32)
  125.  
  126.      (S2) [Wait for match]               (U2)
  127.  
  128.      (S3) Send(L,S)                      (U3) Receive(U,S)
  129.  
  130.      (S4) Close(L)                       (U4) Close(U)
  131.  
  132.      (S5) Init(S,U+1,B )                 (U5) Init(U+1,S,B )
  133.                       u                                   u
  134.  
  135.      (S6) Init(S+1,U,B )                 (U6) Init(U,S+1,B )
  136.                       s                                   s
  137.  
  138. Notice that since server and user are independent (probably in different
  139. hosts), server could execute (S6) before user executes (U4) and could
  140. receive an error back from user's NCP that socket U is busy.  Similarly,
  141. user could execute (U6) before server executes (S4) and could receive an
  142. error back from his own NCP that socket U is not yet closed (assuming an
  143. implementation where sockets are kept busy until a CLS match).
  144.  
  145. Various modifications could be made to ICP to solve this problem.  We
  146. propose the following ICP:
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.                                                                 [Page 3]
  171.  
  172. NWG                 Regarding Proferred Official ICP             RFC 143
  173.  
  174.  
  175.           Server                              User
  176.           ------                              ----
  177.           Listen(L,32)                        Init(U,L,32)
  178.  
  179.           [Wait for match]
  180.  
  181.           Send(L,S)                           Receive(U,S)
  182.  
  183.           Close(L)                            [Wait for CLS]
  184.  
  185.           Init(S,U+1,B )                      Init(U+1,S,B )
  186.                       u                                   u
  187.  
  188.           [Wait for match]                    Init(U,S+1,B )
  189.                                                           s
  190.  
  191.           Init(S+1,U,B )
  192.                       s
  193.  
  194. This ICP assumes the following:
  195.  
  196. 1.  The user can inquire or is notified of the fact that one of his
  197.     connections has been closed.
  198.  
  199. 2.  The server can inquire or is notified that a connection for which
  200.     he has done an Init (or Listen) is now open.
  201.  
  202. Both of the above seem basic to any NCP - user interface.
  203.  
  204. This race condition problem would not exist had the dynamic reconnection
  205. features of RFC #36 been included in the NCP protocol and had dynamic
  206. reconnection been used in this ICP.
  207.  
  208.  
  209.        [ This RFC was put into machine readable form for entry ]
  210.         [ into the online RFC archives by Walter Pienciak 1/98 ]
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.                                                                 [Page 4]
  227.  
  228.