RFC 161

A SOLUTION TO THE RACE CONDITION IN THE ICP 💖

okay bestie, title block tea first ☕🎀

• Network Working Group 🌸
• RFC: 161 ✨
• Author: A. Shoshani, from SDC (NIC #6772) 🧚
• Date: 19 May 1971 📅
• Category/status: not listed in the header 🙈
• Obsoletes / updates: neither is listed in the header 🫶

So in NWG/RFC #143, someone found a race condition in the ICP 😭 and suggested a fix. The problem is that the Host-Host protocol doesn't say what the NCP should do when it gets more than one STR (or RTS) request for the same socket. So each implementation picks its own vibe. SDC might queue those requests, and UCLA might refuse a request if the socket is already connected. Totally different energy, and it's giving chaos 💀

The fix? Don't change the Host-Host protocol 🙅‍♀️. Instead, find a third-level ICP that doesn't care about this issue at all. The idea is that the INITs going from server to user and from user to server (the ones labelled (S5), (S6), (U5) and (U6) on page 3 of RFC #143) should use a different socket, say U+2 and U+3. Here's how the sequences from RFC #143 would look:

      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 fixes the problems pointed out in RFC #143 without making any assumptions about the NCP implementation 👑. That's the main slay here. The RFC #143 solution, meanwhile, assumes the NCP can notify a process when a command (e.g., close) comes in, and that part is implementation dependent 🥺

bestie, that implementation-dependent bit is the whole reason this fix is needed ✨

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alan Ford 08/99] 🦋