Browse Prior Art Database

Solution to the race condition in the ICP (RFC0161)

IP.com Disclosure Number: IPCOM000002445D
Original Publication Date: 1971-May-19
Included in the Prior Art Database: 2001-Oct-17
Document File: 2 page(s) / 2K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Shoshani: AUTHOR

Abstract

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 98% of the total text.

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