TCP programming question

"Cini, Richard" <RCini(a)congressfinancial.com> wrote: This is one of those things that is poorly understood and apt to be implemented incorrectly and/or differently by different people. Telnet tries to provide a "network virtual terminal" abstraction, and one of the bits of that abstraction is encoding a "newline" across the Telnet connection. This was important way back when a terminal or host might send CR, LF, CR LF, or some other character sequence to indicate newline; and there was some thought being given to how to make it so you could use any terminal+host as a network virtual terminal to another host. The Telnet RFC provides two encodings: CR NUL and CR LF. When I worked on WIN/TCP for MPE/V I tried to make the Telnet server use CR NUL to mean "return the carriage to the left margin" and CR LF to mean "return the carriage to the left margin and advance to the next line" (there were MPE FWRITE carriage-controls that needed to be mapped to these). What I can't remember right now is whether that worked or whether I later changed the server to send CR NUL LF in some cases to appease clients that turned CR LF back into "return the carriage to the left margin". If a Telnet negotiates binary mode (sends IAC WILL BINARY and receives IAC DO BINARY) then it is saying that it will send raw 8-bit data and not do this NVT stuff. And of course some Telnet clients just do whatever, so just send CR when the user presses RETURN or ENTER. This is Wrong, but "be liberal in what you accept", so what you need to do for the NVT (non-binary) case is to run received data through a state machine: when you receive CR you enter a state for the next character where a NUL or LF is discarded but other characters are treated as received data. -Frank McConnell