RFC161 - Solution to the race condition in the ICP

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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 RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by Alan Ford 08/99]

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航