|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
||||||
|
IETF RFC 161
Solution to the race condition in the ICP Last modified on Saturday, March 17th, 2001 Permanent link to RFC 161 Search GitHub Wiki for RFC 161 Show other RFCs mentioning RFC 161 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 |