Telnet and MUD server development

There's a lot to writing a MUD server these days, and while I have never done so, I imagine even more to writing a MUD client. Between implementing official negotiation options, unofficial negotiation options (like ATCP, MCCP, MSP, MXP and more), terminal support and the game itself, it all adds up.

A MUD server can only be as good as the clients that access it, allow it to be. Those clients may have eccentricities, like a lack of or just incorrect support for negotiation, or a lack of or just incorrect support for terminal escape sequences.. or both. Depending on its developer, the server may have to tiptoe around or avoid making use of client functionality in order to not break those clients that are unable to handle it.

Windows Telnet, bane of negotiation

Back in the day, the advantage of Windows Telnet was that it came installed with every copy of Windows and because of that was a convenient client for a user to take advantage of. No longer coming preinstalled, and a user has to go through a slightly arcane process to install it themselves. As such, as a client it is a lot less relevant to server developers than it once was.

It is still relevant to users however, who perhaps might be using computers in a lab where it is installed, but lack the ability or convenience to use or install another client. And functionality-wise, it provides comprehensive support for ANSI/VT-100 escape codes, something that is lacking in most all of the specialised MUD clients that are available these days.

The problem that it poses, is that if it receives any negotiation whatsoever from the server, it stops locally echoing the text the user enters. It does not handle the negotiation options that the server might send to resume locally echoing, and to resume local echoing the user themselves has to enter the settings screen to toggle the relevant setting. This means that if Windows Telnet is to be supported, no negotiation can be done until the server knows that the client being used is not Windows Telnet.


Negotiation and junk characters

Even if Windows Telnet is not supported, there are clients that have no support, or limited support for negotiating. If negotiation is done, depending on the characters involved, this may result in junk output to the user. This is not something that makes those clients unusable, but it does provide a second rate experience for the user. One client which displays junk characters when it receives selected negotiation options, is GMud.


Terminal input and output

The standard way that terminals work is by having the user enter a command, then displaying the output. The text that comprises these two activities is interleaved and provides a overview of what the user has been doing.


MUD clients have moved away from interleaving input and output and generally provide an input field below the output area, for some clients likely for ease of implementation, but for most, likely because it provides a better experience for the user.


One downside of this approach is that there is no cursor in the output area. This shifts away from the range of escape sequences that allow dynamic update of the output area. In the past, this was used to great effect to allow implementation of console applications like Alpine (an email client), Nano (a text editor) or Rogue (a computer game).


Terminal display generation

Consoles use escape sequences to generate the dynamic displays, like those mentioned above for Alpine, Nano and Rogue. But more often than not, implementing the support for the extent of escape sequences to generate those displays, is not something that is important to implementors of MUD clients. On one hand, it is not a widely understood subject perhaps because it is usually delegated to libraries like curses. And on the other, MUD clients are moving towards providing a more graphical experience that can negate the more common needs the escape sequences are put to. The most commonly supported escape sequences in MUD clients these days merely make use of a wider range of colours, through an implementation of the 256 color mode that xterm first provided.


Unfortunately, the state of escape sequences is comparable to that of negotiation. Clients that can handle the most common sequences, may display some of the less common as junk characters. Even clients that aspire to emulating xterm, as Putty does, may under given circumstances dump sequences to the user.



Two different cases are illustrated by the preceding screenshots.

If the server does not negotiate with Putty otherwise, Putty will operate in line mode where it sends the user's input to the server as the whole lines as the user presses the enter key. The escape sequence \x1b[0x provokes the shown response from Putty, but because the user's input for the current line has not been sent yet, it is displayed as part of that input to be sent when the rest is.

GMud however, does not handle this escape sequence and never even considers sending a response to it. Even worse, it does not make an attempt to process it, and just dumps it at the user.

Conclusion

If the server developer does not mind providing a third-rate experience in Windows Telnet, and junk characters showing in arbitrary clients that a user may have chosen, then this is not that big a deal. Of course, they also have to accept that dynamic displays can not be generated through escape sequences for their users.

But MUDs have been around for over sixteen years, yet there are no resources which document these problems. And no documentation for what constitutes standard telnet and terminal functionality for both new MUD servers and clients. Developers seem to generally read about bits and pieces and cobble together something according to whatever parts of the picture they are aware of.

Personally, I believe it should be possible to define all these things. What different MUD clients handle. The ways in which they behave that create problems for server developers. How to work around all the eccentricities in a way that provides a first class experience to the user, or simply allows the server to say "hey, your client just doesn't do what this MUD needs it to, I see you are using this operating system, here's the name of a suitable client."

Is it possible to identify that Putty is being used without negotiating or sending escape sequences and having their responses dumped to the user? Yes. Is it possible to identify that Windows Telnet is being used without using negotiation and implicitly disabling its local echoing, and also avoiding dumping junk characters to the users of other clients? Yes. But there are a lot of MUD clients and this is an area that needs further exploration and testing. I think it should be entirely possible to define a database of information that allows client fingerprinting, through a careful step by step probing of a client as it connects.