Phantasmal Site > DGD > Writing a Library > Telnet Protocol

Implementing Extended Telnet Protocol in DGD

DGD has 'telnet ports', which implement the basic telnet protocol. However, they do so in a very limited and rigid way, and Dworkin has no intention of extending them, or even modifying their behavior. The network patch for DGD makes no change in this, and the ANSI color patch, while it allows certain outgoing high-ASCII characters, still requires patching DGD. What should you do to fix this?

The best answer is to implement your own telnet server in LPC and connect it to a DGD binary port. This allows you to configure the result in LPC rather than patching DGD, and lets you send things like international high-ASCII characters and ANSI color codes when and how you like. It also lets you handle parts of the telnet protocol that DGD does not, such as changes in the screen size, and default terminal settings.

If you want to implement the telnet protocol, you may find this page highly useful. You'll also want to use some RFCs. Here are some potentially useful ones:

  RFC 854 - Telnet protocol specification.
  RFC 855 - Telnet option specifications.
  RFC 1091 - Telnet terminal-type option.
  

There are bugs in how older MUD servers treat newlines, and the same is true of older clients. However, the bugs seem to be all different and highly platform-dependent, so you'll need to work this one out for yourself. Whether a telnet linefeed is newline-then-CR or CR-then-newline or just one or just the other seems to be highly platform dependent. When in doubt, be tolerant.

Be sure to test with a variety of telnet clients. Even recent clients seem to have a variety of odd bugs in the protocol. When testing, remember that some clients will even do odd things like detect the string "password" and turn off character echo afterward rather than relying on the server to turn off echo at the appropriate times.

From: DGD Mailing List (Felix A. Croes)
Date: Fri Nov  1 15:43:01 2002
Subject: [DGD] Mexican Characters

Lord Lerkista wrote:

> When in a Mud i type the n-tilde character in a Unix-like terminal i 
> get a "q" as output,
> It's something of the telnet protocol that uses DGD??

It's because you are using a Mac.  DGD uses line mode for telnet clients,
and binary mode is not well-defined for line mode in the telnet protocol.
DGD uses a hack to enable it on many clients, but apparently it fails on
the Mac.

I am not planning any changes in DGD's telnet support, since even minor
changes are bound to break clients on some other platform.  Instead I am
thinking about a standard protocol for a new mud client, a version of
which I will probably release in Java.  Oh, and it will connect to the
binary port, with the protocol level on the server side handled by LPC.

Regards,
Dworkin
  

From: "Felix A. Croes"
Subject: Re: [DGD] Telnet Echo / Carriage Returns
Date: Sat, 4 Sep 2004 13:43:01 +0200

Thomas Rice <thomas.rice@gmail.com> wrote:

> Hmm, I noticed I setting on my telnet client (putty) for "local line
> editing". I had it on "auto", which makes it not drop to the next line
> when I press enter. If I switch it to "force on" it will then go to
> the next line like I want.
>
> So it seems this is the option I'm looking for. :) Does anyone know
> what I need to change in the Kernel lib and/or the driver source so
> that a client with 'auto' will turn this value to on?

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.

Regards,
Dworkin

From: Dread Quixadhal
Subject: [DGD] Re: Telnet Protocol
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.

Date: Tue Mar 30 12:30:03 2004
Subject: [DGD] ansi colours

Assuming you're just talking about ANSI escape sequences in general and 
not a DGD-specific thing, I have a list of the ansi escape sequences on 
my web-site.  It's not wildly accurate (in terms of which sequences came 
from which specific standards), but it's what I used for the muds I've 
worked on and my mud client.

http://bluesock.org/~willg/dev/ansi.html

/will

From: dgd at list.imaginary.com (Erwin Harte)
Date: Tue Mar 30 13:45:01 2004
Subject: [DGD] Re: ansi colours

Have you considered the possibility that the \e is not an escape
supported by LPC and it really _is_ an 'e' that you send to the
client?

    > @code "\e"[0]
    $28 = 101

This is what you want, however:

    > @code "\033"[0]
    $29 = 27

Hope that helps,

\033[36mErwin\033[0m.
-- 
Erwin Harte

From: dgd at list.imaginary.com (Michael McKiel)
Date: Tue Mar 30 17:39:07 2004
Subject: [DGD] ansi colours

These might be of some use to you, when using the escape \033 sequence in
files the editors or mor'ing interprets the colours and not the codes so
You can't see the codes used like that in a file, these are visible as
colours in the mud as well as being editable:

"\x1B[0m"
"\x1B[1m"
"\x1B[31m"
"\x1B[32m"
"\x1B[33m"
"\x1B[34m"
"\x1B[35m"
"\x1B[36m"
"\x1B[37m"
"\x1B[41m"
"\x1B[42m"
"\x1B[43m"
"\x1B[44m"
"\x1B[45m"
"\x1B[46m"
"\x1B[47m"

Also of note, if you enable ansi in DGD, you should consider stripping escape
sequences in a user's issued command. Else they can change colour on other's
screen by just sending a 'realescape'<colorcode>. I imagine other strange
things are possible if you don't strip escape sequences. 

Did this in my old modified melville:
	result = strlen(str);
	for (i=0; i < result; i++)
	{
		if (str[i] < 32) { str[i] = ' '; }
	}

Happy Colouring! 

From: dgd at list.imaginary.com (dgd@list.imaginary.com)
Date: Tue Mar 30 18:05:08 2004
Subject: [DGD] ANSI Patch for DGD 1.2.87

I decided to update the ansi patch, no reason why other than I was fiddling 
with various stuff which broke dgd badly and got tired of hand editing files 
after the fifth time I had to repatch from .85 up. 

The patch is now 1 file long and should patch in exactly like the 
experimental patches do (patch -p 0 < patchname) so long as you put it in 
the same directory.  It explains that in the top of the patch and all of the 
old files that were included in the older ansi patch are now included in 
this one and created in the dgd/doc/ansi directory. 

You can download it at: 

http://psychoticdelusions.net/dgd-patch/ansi-0.99.5-dgd-1.2.87.gz 

It's no better than the old patch it just applies cleanly with the patch 
command instead of requiring hand editing.  So if you've already patched 
THIS DOES NOTHING DIFFERENT LEAVE IT BE! :)  I've not tested it with the net 
patch or epp or any other patches, just vanilla 1.2.87. 

Anywho, 

Shadus

From: dgd at list.imaginary.com (Josh Dady)
Date: Wed Mar 31 09:43:10 2004
Subject: [DGD] ansi colours

On Mar 30, 2004, at 6:38 PM, Michael McKiel wrote:

> Also of note, if you enable ansi in DGD, you should consider stripping 
> escape
> sequences in a user's issued command. Else they can change colour on 
> other's
> screen by just sending a 'realescape'<colorcode>. I imagine other 
> strange
> things are possible if you don't strip escape sequences.

In college, I had a friend who would shout the following when he found 
a MUD that didn't strip incoming commands:
   - [clear screen]
   - [cursor movement] [big/bold/blink] <banner text> [repeat]
   - [reset scroll region]
   - [move cursor into new, smaller scroll region]

--
Joshua P. Dady
http://www.indecisive.com/

From: dgd@dworkin.nl (Par Winzell)
Date: Sat May  7 15:28:01 2005
Subject: [DGD] Question: Implementing ANSI

Trance Junkie wrote:
> Hello again, and thanks to everyone who answered my last query.
> 
> This might sound a bit backwards after my last question, but I do tend 
> to think/do things in strange ways sometimes. Basically, I'm wondering 
> if there's a relatively easy way to add ansi colour capabilities to the 
> DGD driver. There's a bit of documentation on the SourceForge site on 
> this, and some more on Dworkin's DGD FAQ, but again I have stumbled into 
> a couple of hurdles.

To summarize what's already been said and add some of my own --

The DGD driver has 'telnet' ports and 'binary' ports. The telnet ports 
have an implementation of the Telnet protocol inside DGD itself. I'd 
probably argue a modern mudlib should implement this on the mudlib 
level, but it's convenient to have it in DGD, especially because it's 
such a confusing protocol with so many broken implementations out in the 
wild. The ANSI patch to DGD, as far as I can remember, just removes a 
few lines of code in DGD that explicitly strips escape sequences such as 
ANSI colour codes.

Zell