RFC202 - Possible Deadlock in ICP

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

Network Working Group Steve Wolfe

Request for Comments: #202 UCLA-CCN

NIC #7155 Jon Postel

Categories: D UCLA-NMC

References: Document #2 26 July 1971

Obsoletes: None

We have noticed a possible deadlock situation which may arise using the

Initial Connection Protocol (ICP) specified in Document #2 (NIC #7101 in

the Current Network Protocols Notebook NIC #7104).

If on both sides one RFCis issued and a "wait for match" is required

before the second RFCis issued, it is possible that the first RFC's

will not match. In particular a deadlock will occur if both sides open

their send or both sides open their receive sockets first.

Briefly the ICP is:

<where the original uses a script lowercase letter with a single digit

subscript we use the lower case letter followed by {digit} so that

script-m-subscript-2 is printed m{2}>

Server User

------ ----

S1: Listen on socket L. U1: RTS(U, L, l{1})

S2: Wait for a match. U2: Wait for match.

S3: STR(L, U, s{1})

S4: Wait for allocation. U3: All(l{1}, m{1}, b{1})

S5: Send data S in s{1} bit U4: Receive data S in s{1}

bytes as allowed by bit bytes.

allocation m{1}, b{1}.

S6: CLS(L, U) U5: CLS(U, L)

S7: RTS(S, U+3, l{2}) U6: STR(U+3, S, s{2})

S8: STR(S+1, U+2, s{3}) U7: RTS(U+2, S+1, l{3})

"The labels here imply no ordering except that ordering required by the

Host-Host Protocol. Note that steps S7 and S8 can be reversed as can U6

and U7. Also, notice that at any time after S2 the server could

initiate steps S7 and S8 in parallel with steps S3 through S6, and that

at any time after U4 the user could initiate steps U6 and U7 in parallel

with step U5."

[Page 1]

We recommend that the server perform steps 7 and 8 before waiting for

the user to perform step 6 or 7. It is also suggested that the user

issue the RFC's in steps 6 and 7 without waiting for the server. (If

the user is only Listening then both Listens should be issued without

waiting for the server.) If for some reason a host must delay between

issuing RFC's it must issue the RFC's involving sockets S and U+3 first.

[ This RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by Robert Barnes 6/97 ]

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