Regarding proffered official ICP
A proposed change to avoid a race during the Initial Connection Protocol.
Naylor, W., Wong, J., Kline, C., and J. Postel, "Regarding proffered official ICP", RFC 143, DOI 10.17487/RFC0143, May 1971, <https://www.rfc-editor.org/info/rfc143>.
@misc{rfc143,
series = {Request for Comments},
number = 143,
howpublished = {RFC 143},
publisher = {RFC Editor},
doi = {10.17487/RFC0143},
url = {https://www.rfc-editor.org/info/rfc143},
author = {W. Naylor and J. Wong and C. Kline and J. Postel},
title = {{Regarding proffered official ICP}},
pagetotal = 4,
year = 1971,
month = may,
} RFC text
Contents
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 RFC was put into machine readable form for entry ]
[ into the online RFC archives by Walter Pienciak 1/98 ]
ISO Plain Language
On this page
§1A Connection-Closing Race
RFC 143 analyzes the Initial Connection Protocol proposed in RFC 123. The conflict occurs when the server tries to initiate a second connection to the user's receive socket before the first connection has fully closed. The user and server act independently, so the timing can vary.
In the sequence table, action 16 can occur before action 12. The user's NCP can then find the socket still in use and return a close response, which may lead the server to assume the user has finished.
The server can try to reuse a socket before the user's network software has released it. The resulting error can make the two sides disagree about whether the user is still connected.
§1The Proposed Ordering Change
The memo proposes eliminating the user's explicit close operation. The user waits for a close signal from the server before issuing another Init, and the user's NCP still returns a close response to the server's close.
The authors prefer removing the user's close because the server's close lets the server reuse its socket sooner to serve another user. The memo also notes that the race would not occur if the dynamic reconnection features of RFC 36 had been included in the NCP protocol and used in this procedure.
Have one side close first and make the other wait for that signal before opening the next connection. This gives both sides a clear order for releasing and reusing sockets.
§1Updates and Status
RFC 143 updates RFC 123 and RFC 145. The work unit metadata says that RFC 165 later obsoleted this memo.
This memo proposed an ordering change for connection setup. RFC 165 later replaced it.