RFC 202

Request for Comments #202 💖

Network Working Group 🎀

• Authors: Steve Wolfe (UCLA-CCN) and Jon Postel (UCLA-NMC) 👑
• Request for Comments: #202, NIC #7155
• Categories: D
• References: Document #2
• Date: 26 July 1971
• Obsoletes: None

okay so bestie, we spotted a possible deadlock 💀 lurking in the Initial Connection Protocol (ICP) from Document #2 (NIC #7101 in the Current Network Protocols Notebook, NIC #7104). it's giving "everyone is waiting and nobody moves" energy 😭

here's the tea: if both sides send one RFC and then wait for a match before sending the second RFC, the first RFCs might not match up with each other. the deadlock hits hardest when both sides open their send sockets first, or both open their receive sockets first 🙈

quick refresher on the ICP first 🧚 (where the original uses a script lowercase letter with a single digit subscript, we write the letter followed by {digit}, so script-m-subscript-2 shows up as m{2}):

Server                                User
------                                ----

S1:  Listen on socket L.              U1:  RTS(U, L, l{1})

S2:  Wait for a match.                U2:  Wait for match.

S3:  STR(L, U, s{1})

S4:  Wait for allocation.             U3:  All(l{1}, m{1}, b{1})

S5:  Send data S in s{1} bit          U4:  Receive data S in s{1}
     bytes as allowed by                   bit bytes.
     allocation m{1}, b{1}.

S6:  CLS(L, U)                        U5:  CLS(U, L)

S7:  RTS(S, U+3, l{2})                U6:  STR(U+3, S, s{2})

S8:  STR(S+1, U+2, s{3})              U7:  RTS(U+2, S+1, l{3})

the step labels don't mean a strict order, except for the order the Host-Host Protocol already requires 🫶 steps S7 and S8 can swap places, and so can U6 and U7. also, the server can kick off S7 and S8 at any point after S2, running them alongside S3 through S6. and the user can kick off U6 and U7 at any point after U4, running them alongside U5 💅

so here's what we recommend, no cap ✨

• the server should do steps 7 and 8 before it waits for the user to do step 6 or 7.
• the user should send the RFCs in steps 6 and 7 without waiting on the server.
• if the user is only Listening, then both Listens should go out without waiting on the server.
• if a host has to pause between sending RFCs for some reason, it should send the RFCs involving sockets S and U+3 first 🦋

the big takeaway: never let both sides sit there waiting for each other. the order of your RFCs is the whole plot 🎭

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Robert Barnes 6/97 ]