GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc161

Network Working Group A. Shoshani Request for Comments: 161 SDC NIC #6772 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 08/99]

Shoshani [Page 1]

/data/webs/external/dokuwiki/data/pages/rfc/rfc161.txt · Last modified: 2001/03/17 00:22 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki