[Contrib] [RFC Index] [RFC 100 - 199]    RFC 161: Solution to the race condition in the ICP. A. Shoshani. May-19-1971.

RFC 161: Solution to the race condition in the ICP. A. Shoshani. May-19-1971.   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]

[Contrib] [RFC Index] [RFC 100 - 199]    RFC 161: Solution to the race condition in the ICP. A. Shoshani. May-19-1971.