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]
License.
All information of this service is derived from the free sources and is provided solely in the form of quotations.
This service provides information and interfaces solely for the familiarization (not ownership) and under the "as is" condition.
Copyright 2016 © ELTASK.COM. All rights reserved.
Site is optimized for mobile devices.
Downloads: 128 / 158763792. Delta: 0.00282 с