OpenRFC.org Requests For Comments ... for the community
Welcome to OpenRFC
Home Full RFC index RFC humour Our technology
 
RFC 161
Solution to the race condition in the ICP.
A. Shoshani. May 1971.

 
[Direct link][Download PDF version][Download text version]
 

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]

   

[Home] [Full RFC index] [RFC humour] [Our technology]

Copyright © Inter-Corporate Computer & Network Services, Inc.  All rights reserved.
All trademarks and RFC contents are the property of their respective owners.