07 May, 2011, talvo wrote in the 21st comment:
Votes: 0
Just to clarify (I'm the author of Potato) - Potato handles \r\n (which is the default lineending for Telnet, on all platforms) just fine. The problem is that this particular MUD/codebase is, on occasion, sending \n\r instead of \r\n, which (because the final line then doesn't have a correct/complete lineending) causes the final line to not display (the client displays whole lines, not char-by-char). I suggested the person trying to connect change an option when connecting to the world to make the client just treat '\n' as the lineending, to avoid that problem, which means that the \r is treated as a normal character and displayed. Other clients might handle that error more gracefully, but it's still a server-side error - the server is sending \n\r incorrectly. I notice that someone right back at the start of this thread recommended switching \r\n -> \n\r temporarily as a debugging measure, and suspect that was done with the MUD/codebase in question, which never reverted back to \r\n.
07 May, 2011, Twisol wrote in the 22nd comment:
I agree that "\n\r" should be exterminated wherever it is found, but most clients I've used are able to cope with loose \r's. There's a number of MUDs that send odd line-end sequences (like \n\r or just \n), and it's not just the one being discussed here.
MUDs are notorious for not consistently supporting Telnet anyways, so clients really do need to be a little bit liberal in what they accept.
MUDs are notorious for not consistently supporting Telnet anyways, so clients really do need to be a little bit liberal in what they accept.
07 May, 2011, Tyche wrote in the 23rd comment:
Twisol said:
And just FYI, "\r\n" is the standard end-of-line sequence for Telnet. It is this way because the \r control character is supposed to move the cursor back to the left edge, and the \n control character is meant to drop the cursor down one character. Hence "\r\n" means end-of-line. Of course, it's a bit of an anachronism these days, but you still need to follow the standard or funky things happen.
The HTTP protocol also uses "\r\n" for the end-of-line sequence in headers. However most browsers and clients will handle the incorrect "\n" as well.
Scandum said:
I think it's Windows telnet that requires \r\n or \n\r, old Macintosh systems might send \r or \r\0, and pretty much everything else handles \n correctly.
Actually Windows telnet handles \n correctly as in the example KaVir used. The "\r\0" sequence will be sent by Telnet clients when in character mode.
Robust clients and servers can implement both the Telnet end-of-line sequences correctly AND handle the "broken" \n\r as an end-of-line sequence without any conflict whatsoever. That is it is best to write a client or server to only send the correct sequences, but to receive both the correct and incorrect sequences. The motto "Be conservative in what you send, and liberal in what you accept" is good practice.
07 May, 2011, quixadhal wrote in the 24th comment:
Nice. I may have to borrow that for WileyMUD. That makes the output more like an LpMUD, which normally only shows a prompt after user input. Makes the screen more dense, which is a good thing for me.
Darn… missed the chance to spew about the CRLF TELNET thing. Oh well. :)
Darn… missed the chance to spew about the CRLF TELNET thing. Oh well. :)
Random Picks
