Subject: [DGD] Re: Telnet Protocol
From: Dread Quixadhal
Date: Sun, 05 Sep 2004 18:02:54 -0400

Not too long ago, Thomas Rice claimed:

>I'm trying to build on the Kernel Lib and am trying to modify how the
>MUD treats my input when I telnet in and press enter.
>
>At the moment, after I press enter the cursor goes to the beginning of
>the line (but not down one) and then any response to what I typed is
>written over the same text.
>
>This happens with the Kernel lib I downloaded, as well as the
>Phantasmal lib I downloaded, but doesn't happen with the Gurba lib,
>but I haven't been able to figure out how to change it.
>
>  
>
and not long after that, Felix A. Croes replied:

> <>
>
>DGD always sends \r\n as a newline on telnet connections.  But it does
>not respond to some of the more advanced settings that putty may be
>attempting.  Your options are to modify dgd/src/comm.c to more fully
>implement telnet option negotiation, to change putty settings instead
>of DGD/LPC code, or to connect to the binary port.
>  
>

As usual, Dworkin answered my question before I could ask it :)

Not too long ago, I was working on a telnet class in C++ and sent mail 
to a couple of people claiming to have found the oldest and most trivial 
bug in all of DikuMUD Land... namely, if you look at the source to just 
about any of the diku variants, you'll see they send text out the socket 
with "\n\r" as the line termination characters.  According to the telnet 
specification, all transmissions in line mode must use "\r\n" as the 
line termination sequence, if you want to send the opposite, it would 
actually be sent as "\n\r\0".  The telnet server (which DGD acts as) 
will always send things in this form and expect them in this form.  It's 
up to the client (putty, your local /bin/telnet, or tinyfugue, etc...) 
to correctly translate them back and forth between the telnet spec and 
your local machine's interpretation.  Most unix-like platforms use "\n", 
most DOS-like platforms use "\r\n", and I think most pre-OSX macs use "\r".

Needless to say, reporting this bug didn't raise many red flags with 
anyone who noticed... but what Thomas describes is what I would expect 
to happen if either side (client or server) wasn't correctly honouring 
the protocol.  Besides changing settings, you might want to try another 
client as well.