RFC 71

RFC 71: Reallocation in Case of Input Error 💖

Who wrote it: Tjaart Schipper 🎀 Where: UCLA-CCN 🌸 When: 25 September 1970 📅 Series: Network Working Group, Request for Comments #71 ✨ Category/status, obsoletes, updates: none listed in this document 🙈

Okay so, picture this bestie: a message is coming in from the IMP, and an input error happens mid-read. 😭 Now the receiving NCP might literally have no idea how long that message was supposed to be. Yikes! That's the whole problem. So this RFC gives us a resync protocol that the CCN-Host at UCLA uses to get its flow control back on track. It's giving reliability, no cap 💅

The Protocol 🧚

If an input error is detected and the NCP can find the intended link number, it sends a GVB with frac = O to the sending Host. Then it ignores any further incoming messages on that link. 🙈 Once the RET comes back, the NCP sends a new ALL. Main character energy 👑

Now, the sending Host's behaviour depends on what it's doing when the GVB lands:

• If the sending Host is not waiting for an RFNM when the GVB arrives, it sends the RET right away. ⚡
• If it is waiting for an RFNM for the message with the error, or for an RFNM for a message that came after it, it waits until that RFNM shows up and then sends the RET. 🦋

Why It Works 💜

Basically, all this waiting means the receiving Host can be sure the link is clear before it issues a new ALL. No leftover traffic crashing the party. Periodt 🫶

TS/rb. ✨

[ This RFC was put into machine readable form for entry into the online RFC archives by Alexandra Weikert 7/97 ] 🌈