RFC143 - Regarding proffered official ICP

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

Network Working Group W. Naylor

Request for Comments #143 J. Wong

NIC #6728 C. Kline

Categories: D.1, D.3 J. Postel

Obsoletes: None UCLA - NMC

Updates: 123, 145 3 May 1971

Regarding Proferred Official ICP

We should like to comment on a race condition discovered in the ICP as

proposed in NWG/RFC#123. The problem arises when the server attempts

to initiate a second connection to the user's receive socket and the

first connection is not yet closed. Using a similar notation to that of

NWG/RFC#123 the following table illustrates the sequence of events in

the proferred and proposed ICP. The last two columns indicate which

actions must be completed before the current action may be initiated.

User and Server are third level programs, and UNCP and SNCP are the

users NCP and Servers NCP respectively. Allocates have not been

included since they add nothing to the argument.

Required Predecessors

---------------------

Reference # Action Initiator "Proferred" Proposed

----------- ------ --------- ----------- --------

1 Listen(L,32) Server -- --

2 Init(U,L,32) User -- --

3 RTS(U,L,'l') UNCP 2 2

4 STR(L,U,32) SNCP 1 and 3 1 and 3

5 Send(L,S) Server 4 4

6 SEND('l',S) SNCP 5 5

7 RECEIVE('l',S) UNCP 6 6

8 Receive(U,S) User 7 7

9 Close(L) Server 5 5

10 CLS(L,U) SNCP 9 and 7 9 and 7

11 Close(U) User 8 not used

12 CLS(U,L) UNCP 11 10

Required Predecessors

---------------------

Reference # Action Initiator "Proferred" Proposed

----------- ------ --------- ----------- --------

13 Init(S,U+1,B ) Server 9 9

u

14 RTS(S,U+1,'l' ) SNCP 13 13

2

15 Init(S+1,U,B ) Server 13 14 and 18

s

16 STR(S+1,U,B ) SNCP 15 15

s

17 Init(U+1,S,B ) User 11 12

u

18 STR(U+1,S,B ) UNCP 17 17

u

19 Init(U,S+1,B ) User 17 17

s

20 RTS(U,S+1,'l' ) UNCP 19 19

3

Note that in the Proferred Order column, 16 can occur before 12 in which

case UNCP would find socket U in use and probably return a CLS (U,S+1).

The Server would probably then assume the User was finished with the

conversation.

The above problem is resolved by eliminating the Close from one side and

causing that side to wait for the CLS from the other side before doing

an Init. We propose that eliminating the user's Close (U) is the best

solution. (The user NCP must of course return a CLS in response to the

CLS sent by the server NCP).

The Server's Close (L) leads more quickly to the reuse of socket L thus

the serving of another user.

To clarify the above discussion which may seem confusing at first

glance, let us demonstrate the problem in the language of RFC#123.

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+1,B ) (U5) Init(U+1,S,B )

u u

(S6) Init(S+1,U,B ) (U6) Init(U,S+1,B )

s s

Notice that since server and user are independent (probably in different

hosts), server could execute (S6) before user executes (U4) and could

receive an error back from user's NCP that socket U is busy. Similarly,

user could execute (U6) before server executes (S4) and could receive an

error back from his own NCP that socket U is not yet closed (assuming an

implementation where sockets are kept busy until a CLS match).

Various modifications could be made to ICP to solve this problem. We

propose the following ICP:

Server User

------ ----

Listen(L,32) Init(U,L,32)

[Wait for match]

Send(L,S) Receive(U,S)

Close(L) [Wait for CLS]

Init(S,U+1,B ) Init(U+1,S,B )

u u

[Wait for match] Init(U,S+1,B )

s

Init(S+1,U,B )

s

This ICP assumes the following:

1. The user can inquire or is notified of the fact that one of his

connections has been closed.

2. The server can inquire or is notified that a connection for which

he has done an Init (or Listen) is now open.

Both of the above seem basic to any NCP - user interface.

This race condition problem would not exist had the dynamic reconnection

features of RFC#36 been included in the NCP protocol and had dynamic

reconnection been used in this ICP.

[ This RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by Walter Pienciak 1/98 ]

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