Solution to the race condition in the ICP
A socket arrangement intended to avoid conflicting ICP connection requests.
Shoshani, A., "Solution to the race condition in the ICP", RFC 161, DOI 10.17487/RFC0161, May 1971, <https://www.rfc-editor.org/info/rfc161>.
@misc{rfc161,
series = {Request for Comments},
number = 161,
howpublished = {RFC 161},
publisher = {RFC Editor},
doi = {10.17487/RFC0161},
url = {https://www.rfc-editor.org/info/rfc161},
author = {A. Shoshani},
title = {{Solution to the race condition in the ICP}},
pagetotal = 1,
year = 1971,
month = may,
} RFC text
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]
ISO Plain Language
On this page
§1The Socket Request Conflict
RFC 143 described a race condition in the Initial Connection Protocol. The Host-Host protocol did not specify what an NCP should do when it received more than one STR or RTS request for the same socket.
As a result, implementations could behave differently. SDC might queue requests, while UCLA might refuse a request if the socket was already connected.
The protocol left an important case undefined. Different host software could queue a second request or refuse it, so the same connection attempt could behave differently.
§2Use Separate Sockets for INIT
The proposal leaves the Host-Host protocol unchanged and moves the solution into the third-level ICP. It assigns separate sockets, suggested as U+2 and U+3, for the INIT messages between server and user.
Because the two setup exchanges use different sockets, they do not compete for the same socket. The RFC includes the corresponding server and user command sequence from RFC 143.
The user and server send their setup messages on separate sockets. This avoids the conflict without changing the lower-level protocol.
§3No NCP Notification Assumption
The RFC says the proposed arrangement solves the problem without assumptions about how the NCP handles simultaneous requests. It contrasts this with another solution that assumes an NCP can notify a process when a command, such as a close, arrives.
The proposed fix does not depend on the NCP sending a special notice to a process. It avoids the contested behavior by assigning separate sockets.