Monday, 22 March 2010

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).

Image from wikipedia
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.

Thursday, 25 February 2010

Abusing mailman on Windows

Previous post: Mailman-style mailing list archives

I finished my hack of Mailman for mailing list archive generation a few weeks back. Besides monkey-patching replacement or stub versions of Linux-specific functionality which either does not exist on Windows, or works differently, the main problem was line endings. The marshalled state that Mailman keeps was persisted in a fashion that tended towards line-ending related corruption on Windows. Also the general reading of the underlying mbox archive in a non-Windows compatible way typically resulted in corrupt posts in the generated archive.

Mailman in the way I was using it didn't generate a proper "by thread" view. This was because of an eight year old bug, whose patch hadn't been applied and had rather been marked as discarded. I fumbled around in Mailman's bug tracker and created a new bug, which promptly got closed with the old one being reopened and its patch then being applied. Threading now worked, excellent.

The other problems I encountered were not the fault of Mailman, but rather an extended scope for the project. My original mbox archive which I had generated from web pages only covered 80% of the life of the mailing list. Someone else had the remainder in their gmail account, and offered to extract it for me. However they generated the mbox archive they provided me with, the emails were out of order which was not something Mailman liked. Between that, writing scripts to merge the two mbox archives, correcting the dates on the emails and stripping extraneous headers..

And finally.. a merged and generated browseable Mailman mailing list archive.

Thursday, 18 February 2010

Stack Overflow

I like the idea of Stack Overflow, and often when I need answers I find them on Stack Overflow in the googled results of a query. But the fact that it only allows you to participate if you use OpenID, has prevented me from joining in and helping others out.

My experience

Today, after I received a Google Alert that was a Stack Overflow question about Stackless Python, I gave in and went through the OpenID process. It felt unclean, but I proceeded to add an answer for the question.

In order to give context to my answer, I linked to around ten different wiki pages, source code files and documentation pages. Having written as much detail as I could get together, I submitted the answer to the site and was promptly told that I needed to earn points before I could use more than one link in my post. So I deleted the links and submitted an inferior answer.

Then I suddenly earned a teacher badge. What is this? I haven't done anything yet other than submit an answer, and now I am getting spammed by worthless things being attached to my account? I can't work out how to turn these badges off either.

Reflecting for a few minutes on my experience so far, being given unearned worthless awards and being required to earn points, it felt like my efforts were being bought with worthless beads and trinkets. When I help someone out with knowledge or code, I do it because I want to help. Doing it within a system where there are barriers to being able to do it, and token rewards that are at best condescending, takes away from my effort to help someone. I didn't feel good about using Stack Overflow.

So I deleted my answer and went looking for how to delete my account. Apparently, you need to edit your profile to indicate you want your account deleted and then you need to email them. Even Facebook has an account deletion mechanism. That you need to jump through hoops, to get away from Stack Overflow is not an honest approach. But it fits in with the token rewards, and arbitrary limitations to what you can do that seem to be based on giving value to the point system.

My conclusion

It surprises me how well Stack Overflow does, considering that it is not a place I feel comfortable participating in. And I do participate in a wide variety of mailing lists and forums. But it also surprises me what a scam it feels like.

The points system does not add any value that I can see. It constrains what I can do as a user in arbitrary ways that seem like they are solely designed to give value to points. The answers I saw from users with high points, and high upvotes, were incorrect and weak.

The badges mean nothing to me, they are good in computer games where I want to know about my accomplishments, but on a site where I might help others to be given them for no reason makes the experience feel cheap.

In this day and age, the ability to easily delete your account lends credence to the respectability and trustworthiness of the site you have the account with. That Stack Overflow puts an arbitrary barrier between users being able to delete their account, can only be an intentional way to prevent people from leaving it. It comes across as untrustworthy.

I will continue using Stack Overflow as a resource for getting answers I need, but there is no way I can participate in it. But that's okay, there are a lot of other forums that do not cheapen the experience of trying to help others, and I can stick to those.