4 ms·
And unless there's another software engineer named Daniel J. Bernstein out there, he also authored RFC 1143 documenting the Q Method of TELNET Option Negotiatio
by Twisol 7y ago
And unless there's another software engineer named Daniel J. Bernstein out there, he also authored RFC 1143 documenting the Q Method of TELNET Option Negotiation [1], which prevents negotiation loops and nails down (in the shape of a state machine) exactly what behavior is good and proper for a Telnet peer.
I referenced this document a lot when writing my own Telnet stack.
[1] https://datatracker.ietf.org/doc/rfc1143/ https://datatracker.ietf.org/doc/rfc1143/
- tambourine_man 7y ago>…when writing my own Telnet stack. There’s probably an interesting story hidden in there.
- Twisol 7y agoThat probably depends more on the listener than on the story! I played MUDs for several years, at the same time that I was learning the ins and outs of programming. I developed some plugins for a popular third-party client called MUSHclient. The game I played also had a somewhat proprietary first-party client, and they used a spare Telnet option (one left unassigned by IANA [1]) to pass data from the server to the client to drive some extra graphical widgets on their client. I got involved in developing plugins that made use of that data, which led me to learning how to negotiate that option with the server and get the data I wanted. I eventually started developing my own MUD client, which is where the Telnet stack came in. Now, writing a Telnet stack is just something I do when I learn a new language. It's just large enough of a project to exercise some architectural and API-level concerns. [1] If you're curious, all of the formally allocated Telnet options are documented here: https://www.iana.org/assignments/telnet-options/telnet-options.xhtml https://www.iana.org/assignments/telnet-options/telnet-optio...