summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc161.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc161.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc161.txt')
-rw-r--r--doc/rfc/rfc161.txt59
1 files changed, 59 insertions, 0 deletions
diff --git a/doc/rfc/rfc161.txt b/doc/rfc/rfc161.txt
new file mode 100644
index 0000000..cfc2fa6
--- /dev/null
+++ b/doc/rfc/rfc161.txt
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+Network Working Group A. Shoshani
+Request for Comments: 161 SDC
+NIC #6772 19 May 1971
+
+
+ A SOLUTION TO THE RACE CONDITION IN THE ICP
+
+ In NWG/RFC #143 a race condition in the ICP was described and a
+ solution was suggested. The problem arises because the Host-Host
+ protocol does not specify what the NCP should do when it gets more
+ than one request of STR (or RTS) to the same socket. As a result
+ this decision depends on the particular implementation: some may
+ queue these requests (SDC for example), some will refuse a request if
+ the socket is already connected (UCLA for example), etc.
+
+ The solution is not to change the Host-Host protocol, but find a
+ third level ICP which does not depend on this issue. Such a solution
+ is the following: the INITs from server to user and user to server
+ ((S5), (S6), (U5), (U6) on page 3 in RFC #143) should use another
+ socket -- say U+2 and U+3. The sequences in RFC #143 would be:
+
+ 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+3,Bu) (U5) INIT(U+3,S,Bu)
+ (S6) INIT(S+1,U+2,Bs) (U6) INIT(U+2,S+1,Bs)
+
+
+This solution will solve the problems pointed out in RFC #143 without
+any assumptions made about the NCP implementation. The solution in RFC
+#143 assumes that the NCP can notify a process when a command (e.g.,
+close) comes in, which is implementation dependent.
+
+
+
+
+ [ This RFC was put into machine readable form for entry ]
+ [ into the online RFC archives by Alan Ford 08/99]
+
+
+
+
+
+
+
+
+
+
+Shoshani [Page 1]
+