Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc143.txt.pdf Дата изменения: Wed Mar 27 23:10:27 2002 Дата индексирования: Tue Oct 2 16:18:45 2012 Кодировка:

Network Working Group Request for Comments #143 NIC #6728 Categories: D.1, D.3 Obsoletes: None Updates: 123, 145 Regarding Proferred Official ICP

W. Naylor J. Wong C. Kline J. Postel UCLA - NMC 3 May 1971

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 --------------------"Proferred" Proposed --------------------2 1 and 3 4 5 6 7 5 9 and 7 8 11 -2 1 and 3 4 5 6 7 5 9 and 7 not used 10

Reference # ----------1 2 3 4 5 6 7 8 9 10 11 12

Action -----Listen(L,32) Init(U,L,32) RTS(U,L,'l') STR(L,U,32) Send(L,S) SEND('l',S) RECEIVE('l',S) Receive(U,S) Close(L) CLS(L,U) Close(U) CLS(U,L)

Initiator --------Server User UNCP SNCP Server SNCP UNCP User Server SNCP User UNCP

[Page 1]


NWG

Regarding Proferred Official ICP

RFC 143

Reference # ----------13

Action -----Init(S,U+1,B ) u RTS(S,U+1,'l' ) 2 Init(S+1,U,B ) s STR(S+1,U,B ) s Init(U+1,S,B ) u STR(U+1,S,B ) u Init(U,S+1,B ) s RTS(U,S+1,'l' ) 3

Initiator --------Server

Required Predecessors --------------------"Proferred" Proposed -----------------9 9

14

SNCP

13

13

15

Server

13

14 and 18

16

SNCP

15

15

17

User

11

12

18

UNCP

17

17

19

User

17

17

20

UNCP

19

19

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.

[Page 2]


NWG

Regarding Proferred Official ICP

RFC 143

To clarify the above discussion which may seem confusing at first glance, let us demonstrate the problem in the language of RFC #123. Server -----(S1) Listen(L,32) (S2) [Wait for match] (S3) Send(L,S) (S4) Close(L) (S5) Init(S,U+1,B ) u (S6) Init(S+1,U,B ) s User ---(U1) Init(U,L,32) (U2) (U3) Receive(U,S) (U4) Close(U) (U5) Init(U+1,S,B ) u (U6) Init(U,S+1,B ) 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. propose the following ICP: We

[Page 3]


NWG

Regarding Proferred Official ICP

RFC 143

Server -----Listen(L,32) [Wait for match] Send(L,S) Close(L) Init(S,U+1,B ) u [Wait for match]

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

Receive(U,S) [Wait for CLS] Init(U+1,S,B ) u 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. The server can inquire or is notified that a connection for which he has done an Init (or Listen) is now open.

2.

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 RFC was put into machine readable form for entry ] [ into the online RFC archives by Walter Pienciak 1/98 ]

[Page 4]