Browse Prior Art Database

Regarding proffered official ICP (RFC0143) Disclosure Number: IPCOM000002257D
Original Publication Date: 1971-May-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 4 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

W. Naylor: AUTHOR [+3]

Related Documents

10.17487/RFC0143: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 73% of the total text.

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

[Page 1]

NWG Regarding Proferred Official ICP RFC 143

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.

[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 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 c...