💾 Archived View for gmi.noulin.net › rfc › rfc161.gmi captured on 2022-04-28 at 22:15:46. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-05)
-=-=-=-=-=-=-
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]