rfc161.txt

RFC技术文档 从0000－05

NWG/RFC #161                                                 A. Shoshani
NIC #6772                                                    SDC
                                                             19 May 1971


              A SOLUTION TO THE RACE CONDITION IN THE ICP

In NWG/RFC #143 a race condition in the ICP was described and a solution
was suggested. The problem arises because the Host-Host protocol does
not specify what the NCP should do when it gets more than one request of
STR (or RTS) to the same socket. As a result this decision depends on
the particular implementation: some may queue these requests (SDC for
example), some will refuse a request if the socket is already connected
(UCLA for example), etc.

The solution is not to change the Host-Host protocol, but find a third
level ICP which does not depend on this issue. Such a solution is the
following: the INITs from server to user and user to server ((S5), (S6),
(U5), (U6) on page 3 in RFC #143) should use another socket -- say U+2
and U+3. The sequences in RFC #143 would be:

      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+3,Bu)                (U5) INIT(U+3,S,Bu)
      (S6) INIT(S+1,U+2,Bs)              (U6) INIT(U+2,S+1,Bs)


This solution will solve the problems pointed out in RFC #143 without
any assumptions made about the NCP implementation. The solution in RFC
#143 assumes that the NCP can notify a process when a command (e.g.,
close) comes in, which is implementation dependent.






       [ This RFC was put into machine readable form for entry ]
           [ into the online RFC archives by Alan Ford 8/99]








Shoshani                                                        [Page 1]