A couple of years ago I wrote a chapter for a book that never happened. The editor disappeared off the face of the map, and wouldn’t respond to emails. It’s probably too niche a topic to really warrant the work that would be needed to turn it into a more general article for journal publication, so I decided instead to publish it here and on Gamasutra rather than let it languish: Introduction There are few gaming genres in which the concept of the puzzle is as deeply embedded as that of the adventure, especially the text-games that were so popular … Continue reading
Unfortunately, the thing about Telnet is that it is so simple that it just sends everything in plaintext; there's no security and it doesn't pretend to have any. This was fine in the 80's, but not today. So, although I intended to still allow Telnet connections since MUD clients are built on it, for the security-conscious I'd offer a way to have secure, encrypted connections. The best way to do this without a custom-made Smerg client (which I DO want to make some day, just not now) would be to support SSL, the Secure Sockets Layer.
I didn't know how deep the rabbit hole went when I tried to figure that out.
First off, I wrote a while back that I moved from plain Sockets to SocketChannels, the non-blocking variant. Which was fantastic. Now, Sockets have a cousin, the SSLSocket, which does pretty much what it says on the tin. It acts just like a Socket and uses the same API, but under the hood it handles all the SSL stuff for you, which is great because the SSL specification is gigantic and only huge crypto nerds know how it works. And the ServerSocket that Smerg used to listen for connections has an SSLServerSocket cousin. Of course, being Socket implementations, they are blocking. But that's okay, because there's an SSLSocketChannel, right?
No, someone at Oracle decided that that would make too much sense. So instead we have a monstrosity called the SSLEngine, which requires you to manually initiate all the various parts of the SSL protocol such as the opening handshake and negotiation of ciphers and who knows what else. It's impossible to use unless you know the SSL protocol inside and out. Amazingly enough, there are no open-source libraries that have picked up the slack either, and the only closed-source one has a website that has a link to its Javadoc but not an actual download link for the library itself. I wish I was making this up.
Non-blocking IO, while cool, isn't super critical. I can use Socket and SSLSocket and just check the size of the InputStream on the socket, like I did before switching to NIO, right?
Socket works fine. But SSLSocket's
availablemethod will happily return 0 even when there's input available. So the only thing you can do is just attempt a read and catch the
SocketTimeoutExceptionthat will occur if there's nothing to read.
So, although I have a working implementation of SSL, there's one more problem: the typical command-line client, OpenSSL, doesn't support ANSI colors. Although I could have an option to turn them off, this thing is just becoming one gigantic headache I don't want to deal with any more. This won't scale; having to use blocking I/O means at most a millisecond wait for every user, which doesn't sound like much but can add up if you have a popular MUD. If you hit a thousand concurrent players, the game will be delayed by an entire second for all of them as they all wait for everyone else's timouts. When Smerg was multithreaded this problem went away, but now it's back in full force.
This isn't worth it.
I give. I'll come back in some nonzero number of months and just write a custom client for Smerg that handles encryption. Or maybe someone will submit a pull request and do it for me. I'm beyond caring at this point. I just want to get this thing released.