diff options
Diffstat (limited to 'doc/rfc/rfc161.txt')
| -rw-r--r-- | doc/rfc/rfc161.txt | 59 |
1 files changed, 59 insertions, 0 deletions
diff --git a/doc/rfc/rfc161.txt b/doc/rfc/rfc161.txt new file mode 100644 index 0000000..cfc2fa6 --- /dev/null +++ b/doc/rfc/rfc161.txt @@ -0,0 +1,59 @@ + + + + + + +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] + |