The telnet protocol is an entirely ascii-based method of transmitting data that was developed way back before I was born. Telnet lives in what they call the “application layer” of the internet protocol suite. It’s like SSH only without the S (the one for secure). To communicate in telnet land, servers and clients send information back and forth in ascii streams. Server commands are communicated with ascii sequences that aren’t for printing. These sequences start with a value of 255, followed by various values to reflect the command, then sometimes additional values to specify options for that command. You can find a nice table explaining what value means what command here on Microsoft’s website.

To illustrate, here is the set of sequences that first arrive when you connect to the telnet server (in this case specifically a mud client) at Lusternia.com:

255 251 25: IAC WILL (use) END-OF-RECORD, this means the server wants to use the sequence 255 25 to indicate the end of a chunk of data instead of relying on carriage returns and line feed (often written as \r and \n).

255 251 200: IAC WILL (use)ATCP, this is a mud-specific command to indicate that the server would like to use the Achaea Telnet Client Protocol .

255 251 201: IAC WILL (use)GMCP, this is another mud-specific command to indicate that the server would like to use the Generic Mud Communication Protocol (aka ATCP2).

255 251 86: IAC WILL (use) MCCP2, this is yet another mud-specific command to indicate that the server would like to use the Mud Client Compression Protocol v2

So basically, the server just says “Oh hey, welcome to the server. I want to use the end-of-record feature and I would also like to use one of the following mud compression protocols.” These compression protocols are to help reduce bandwidth consumption (because text can get expensive of course) and to communicate things a regular telnet connection wouldn’t communicate such as the prompt (health, mana, etc).Then finally, after the block of text introducing the server, the server sends along one final command sequence:

255 249: IAC GO AHEAD, this is a fairly old command, not sure why this server is using it. The go-ahead command tells you, the client, that it’s ok to send data back. Go-ahead was developed for back in the day when connections were not full duplex and only one side of the connection could speak at a time.

After receiving these commands from the server, the client will want to send back a few commands in response:

255 253 25: IAC DO (use) END-OF-Record, this reply tells the server that you (the client) agrees to make use of the end-of-record feature.

255 253: IAC DO (use) compression protocol, this reply tells the server that you (the client) agree whichever of the possible compression protocols listed by the server.

From here, assuming the client knows how to deal with the mud-specific protocol, a user can go on with their evening and enjoy their game!

More later after I get further along!