RFC 718

Comments on RCTE from the TENEX Implementation Experience ✨

Network Working Group 🌸

• Author: Jon Postel (SRI-ARC) 💖
• Request for Comments: 718 🎀
• Date: Jun 1976 📅
• NIC #: 35874 🦋
• Obsoletes / Updates: the original doesn't list either one 🤷‍♀️

okay so this memo started life as a single page from a document about changes in version 1.34 of the Tenex system. The author is probably Ray Tomlinson or someone else in the BBN-RCC Tenex group 🧚. Ray agreed these comments should go out to the whole network community, not just Tenex people, so everyone gets to read them 💅✨

The code for the RCTE option of the new TELNET protocol on TENEX is finished! 🎉 RCTE cuts down on network traffic by holding back characters that won't wake up the receiving user program, and only sending them once a character that will wake it up shows up. It gets even better: it also cuts the echo characters flowing back to the user TELNET 🙈 The server tells the user TELNET to echo the whole group of characters up through the next wakeup character. The server sends this command right as the user program is about to read the first character of that group, so the echo is guaranteed to come after any response to the group before it 💜

Significant problems with the RCTE protocol came up during implementation 😭 Spontaneous output was specified in a way that made it super hard to implement correctly (if a correct implementation is even possible, tbh 💀). The fix was to fully separate the control of input transmission and echoing from the characters in the output stream. Input and output now sync up just by embedding control information in the output stream 🫶 This makes the coding of both the user TELNET and the server TELNET simpler, which is iconic ✨

Problem number two was interrupt characters 🔥 RCTE has no explicit mechanism for them, so they got handled as program wakeup characters. But interrupt characters aren't actually handled as wakeup characters, and they bypass the terminal input buffer. So a special fix was needed to get the command back to the user TELNET saying the character stream should be echoed past the point where the interrupt character was typed. The transmission has to stay in sync with processing of the terminal input buffer so it gets sent at the right time. The solution was a marker placed in the input buffer at the spot where the interrupt character was. This marker is never given to the user's program and must not be counted as an input character 🙅‍♀️ A new counter tracks how many markers are in the input buffer, and the SIBE JSYS was changed to indicate "empty" only if the total characters in the buffer minus the number of markers is greater than 0. Main character energy 👑

Heads up: the marker must not be counted as an input character. Don't skip this part, bestie 🫶

Problem number three is when the input buffer gets cleared 🧹 The buffer might hold a mix of wakeup characters and special markers, so the user TELNET and the server could fall out of sync. Scanning the buffer and sending an RCTE command for each wakeup character or marker is infeasible 💀 So instead, a single command is sent to the user TELNET meaning "clear your input buffer and reset your counters." This command is sent as WILL RCTE. It's the reverse of a normal RCTE (which is DO RCTE), so it can't be confused with the regular use of the option. Best part: no new option needed 🦋✨

-1-

-2-