The MUD Server Telnet Support When a player connects to a MUD server, that connection is usually done with some kind of 'telnet' program, or a custom MUD client. 'telnet' is a standard protocol that builds up on the TCP/IP protocol set, and is defined by a similar set of official RFC's (Request For Comment). The telnet protocol existed before internet MUDs did, so it was a natural choice for a textual connection. Most MUD servers support the telnet protocol to some degree. One of the things that a good telnet connection can do is to offer the user a choice of whether individual characters are echoed on the local machine, or are sent over the internet to the MUD, and then back again. In the first scheme, internet traffic is only done on a per input line basis. In the second scheme, internet traffic is done for every character typed. So, if your connection is slow ("netlag"), or if the MUD server is busy ("server lag"), the local echo choice is much nicer to use, since typed characters appear right away. The telnet RFC's define an official LINEMODE option, by which this sort of line by line input is supposed to be done. Unfortunately, that mode is quite complex and somewhat beyond what most MUD server authors are interested in doing. This MUD falls into that group. However, before LINEMODE was officially proposed, early telnet clients implemented a sort of pseudo-linemode, based on standardized use of some telnet features that were intended for other purposes. Most UNIX telnet clients support that mode, and this MUD will attempt to use it. Inevitably there will be problems with some clients, however. So, this MUD supports ways in which the remote user can observe and control what is going on at the telnet level, so that correction can be attempted. Two other useful features of telnet are also supported. One is the NAWS (Negotiate About Window Size) feature, by which the telnet client can tell the remote MUD server how many lines and columns are in the display. This can be useful when formatting output to the user. When properly done, the MUD server is even informed when the output window size is adjusted, and can change its operation immediately. The other feature is the TTYTYPE or TERMINALTYPE feature, by which the client tells the MUD server what kind of terminal or window it is using. This is useful if the MUD server wants to send special control sequences to affect the display the user is seeing (e.g. colour changes, text style changes, direct cursor positioning, etc.) Those sequences vary from terminal to terminal, and the MUD needs to know what kind to use. However, most MUDs only support "ANSI" control codes. This is often known as "ANSI Colour". If the MUD telnet code needs to display anything directly to the user (by default it normally won't), each output line will begin with a pair of asterisks ('**'). Similarly, commands to the telnet code all start with a pair of asterisks. Before going into technical detail, I'll discuss some problems that users may encounter, and how the telnet code can be used to try to solve them. Problem: my special characters aren't getting through. Try typing '**binary'. Still doesn't work? Try it a second time. Still doesn't work? Instead, try '**fbinary'. Still doesn't work? Sorry - try a different telnet client. Problem: I can't see the characters I'm typing. Try typing '**echo'. Still doesn't work? Try it a second time. Still doesn't work? Instead, try '**fecho'. Still doesn't work? Sorry - try a different telnet client. Problem: I can see my password being typed. This should only happen if your telnet client won't let the MUD server handle echoing. In that case, there isn't anything that the MUD server can do about it. If you are using a telnet client that has an escape character (many default to control-]), try using it to get into your telnet's command mode. Something there might help. Other ways to control your telnet client, like menus or control panels, might help too. Problem: My input lines get messed up when output comes out. This is a very common problem. The telnet protocol really doesn't have any way to solve this problem. Your best solution is to try to get a custom MUD client, which keeps what you are typing on a different display line than the stuff coming from the MUD. However, there is one feature in this telnet support code that might be causing you some troubles. The code can attempt to erase your prompt before displaying some unexpected output. It will then redisplay the prompt. If that happens when you are typing something, the stuff you are typing gets messed up (the telnet code doesn't know you have typed it yet!). To turn off this behaviour, type '**eraseprompt'. If you still have troubles, there is not much more that can be done. Problem: Things mess up when I type a password. This MUD telnet code tries to operate normally in the pseudo-linemode mentioned above. When it needs a password, however, it will try to take over echoing from the telnet client, and then will echo password characters as spaces. After the password is received, it will try to go back to having the telnet client do local echoing. If this behaviour is messing up your telnet client, you can type '**pwsupga'. If password blanking is still messing up your client, then type '**pwblank' to disable it altogether. Note that some special MUD clients try to recognize password prompts and then not echo stuff you type after them. This may or may not work well with this password-blanking code. Problem: When I hit RETURN, the next line starts below this one, but not at the left hand edge of the window. This is a disagreement over how to handle carriage-returns and linefeeds. Check for options in your telnet client. If that fails, try using '**echo', so that the MUD server is doing it all. Problem: When I hit RETURN, the next line starts at the same place as the last one did. This is the converse of the previous problem. The solutions are the same. Problem: The MUD doesn't get my window size correctly. It is likely that your telnet client doesn't support this feature. You can try to force another NAWS negotiation by typing '**naws', but if that fails, there isn't much that can be done. Problem: The MUD doesn't get the proper terminal type. It is likely that your telnet client doesn't support this feature. You can try to force another TERMINALTYPE negotiation by typing '**ttytype', but if that fails, there isn't much that can be done. The telnet protocol has quite a few options. See the RFC list at the end of this writeup. For the simpler options, the telnet client and the telnet server (the MUD) must negotiate with each other over which options are to be enabled, and who is to do what. To do this, and other things, they send messages back and forth to each other, mostly on startup. You won't see these messages since the telnet protocol makes them invisible to you. Similarly, the parts of the MUD other than the telnet code won't see them either. Either program can offer a service to the other by sending a "WILL XXX" message, where XXX is the service or capability being offered. If the other end wants that service done, it will respond "DO XXX". If it doesn't want that service done (or, more likely, it has never had it implemented), it will respond "DONT XXX". Similarly if one end asks that the other end start doing XXX, it will send "DO XXX" (re-using the same message type). The other end can then respond either "WILL XXX" or "WONT XXX". It is also possible to turn options off that have been turned on, by sending messages of "DONT XXX" or "WONT XXX". Because the messages are reused as requests and replies, it is important that each end keep track of what it has requested, so that it can recognize messages that are replies, rather than new requests. Some MUD servers have very limited telnet support. They never echo characters, and reply "WONT XXX" and "DONT XXX" to everything they receive. This may or may not work very well. Some don't even recognize the protocol. How can that work? If you are on a Linux box, you have the standard 'telnet' program to experiment with. You can use it to telnet to lots of service providers that don't understand the telnet protocol. The key (that I didn't know myself until quite recently!) is that the telnet program will not attempt *any* negotiation unless the port you are telneting to is the standard TELNET port. Thus, when telneting to a MUD, no telnet negotiations will happen, unless the MUD itself starts them. Other telnet clients, and custom MUD clients, will likely behave differently. The telnet options understood by this code are: BINARY - By default, a program compatible with the telnet protocol should not send any characters with the high bit set unless the other end has indicated its willingness to accept them. Note that all telnet internal control characters have the high bit set. To get a full binary connection in which 8 bit characters can freely go both ways, both the server and the client must agree to accept them. On startup, this telnet code will send a "WILL BINARY" and a "DO BINARY" to the client, and will act according to the answers it gets back. ECHO - The echoing referred to by the telnet ECHO RFC refers to echoing characters back over the network connection, and not to local echoing. There is no reason for a client to echo back to a server, so that is never asked for. By default, a server will not echo back to the client, so the client must do any needed echoing of characters that the user types. This MUD telnet code sends a "WILL ECHO" to the client, indicating that it is capable of echoing back. Unfortunately, this action will likely result in unwanted behaviour of some kind. Most telnet clients will respond with "DO ECHO", and then all character echoing has to go back and forth over the network. If the client is also echoing, you can get two copies of everything, either a character at a time, or a line at a time. Thus the "**echo" command in this telnet code might be needed. In most MUDs, the character will have to enter a password in order to log in. As mentioned above in regards to password blanking, the MUD will want to take over echoing at that point anyway. When the password is done, the MUD will send a "WONT ECHO" to get the client to echo locally. Hopefully this will leave the world in the desired situation. SUPGA - This stands for "SUPpress Go-Ahead". When the telnet protocol was first being designed, there existed connections which could only handle one direction of data transfer at a time. To work over this kind of connection, the GO-AHEAD code was defined to tell the other end that sending from this end is done, and the other end can start sending. E.g. when you hit RETURN at the end of an input line, your client would send a GO-AHEAD at the end of it. This sort of connection is now a part of history, but this facility is still in the protocol. This option is important because, it, in combination with ECHO, is the option pair that early telnet clients used to trigger pseudo-linemode. ENDOFRECORD - Some old systems required an explicit character to mark the end of a record being sent. Enabling this option causes a sender to append a telnet EOR character to the end of each record sent. This facility can likely be safely ignored. NAWS - Negotiate About Window Size. This option allows the telnet client to send a special subnegotiation (using special SB and SE codes defined in the telnet protocol) in which it describes the size of the user's window or display. TERMINALTYPE - This option allows the telnet client to send a special subnegotiation in which it describes the type of the terminal or window. E.g. 'xterm' for an X terminal on UNIX. The commands supported by the MUD server telnet code are: **? - show a list of the commands, with brief descriptions **st - show the current status of the MUD telnet code for this connection. Sample output looks like this: ** sendBinary: TRUE ** receiveBinary: TRUE ** server echo: FALSE ** suppress goahead: FALSE ** use end of record: FALSE ** terminal type is 'xterm' ** display height 48 width 80 ** ever send GA: FALSE ** attempt password blanking: TRUE ** use SUPGA on password blanking: TRUE ** erase prompts: TRUE sendBinary - TRUE if the MUD server is allowed to send 8 bit characters to the client, FALSE if it must strip the high bit. receiveBinary - TRUE if the MUD server expects to receive 8 bit characters from the client, FALSE if it should not expect them (and will strip the high bit). serverEcho - TRUE if the MUD server is currently echoing characters back to the telnet client. supress goahead - TRUE if the MUD server will never send GO-AHEAD characters, regardless of any SUPGA negotiations. (It's the negotiations that trigger the pseudo-linemode, not any extra control characters sent around.) use end of record - TRUE if the MUD server will send out some telnet EOR characters. terminal type is 'xterm' - This means that the telnet client I was using understands TERMINALTYPE, and that I was doing it from inside an xterm. The default is "UNKNOWN". display height 48 width 80 - This means that the telnet client I was using understands NAWS, and that my xterm at the time had 48 lines of 80 columns each. ever send GA - this is normally FALSE, since there isn't any reason to actually send the GO-AHEAD characters. attempt password blanking - this says whether or not the MUD server will attempt to use ECHO (and maybe SUPGA) negotiation to attempt to blank out password entry. use SUPGA on password blanking - this is usually TRUE, since that is what works best. However, if your client doesn't support the pseudo-linemode, turning this off may (or may not!) help. erase prompts - if this is TRUE, then the MUD server will attempt to erase existing prompts before sending new output. This is done by sending a carriage return, enough spaces to overwrite the prompt, and another carriage return. This sequence is less dangerous than sequences involving backspaces. **cmd - this command toggles on and off the debug output from the MUD server that shows option negotiation. If you are having trouble with some client, turning this debugging on can be useful. Note that the debug output is sent over the network just like normal output, and is itself subject to processing by your client. It is just straight text, however. **prompt - toggle on and off debugging output related to the displaying and erasing of prompts. Not normally useful to users. **input - toggle on and off debugging that shows what input lines are being sent to the server. Not normally useful to users. **ga - toggle on and off any sending of GO-AHEAD control characters. **pwblank - toggle on and off whether or not this MUD telnet code will attempt to use ECHO (and maybe SUPGA) negotiation to control the echoing of passwords. **pwsupga - toggle on and off whether or not this MUD telnet code will use SUPGA in any attempts to control echoing of passwords. **eraseprompt - toggle on and off whether or not this MUD telnet code will attempt to erase prompts before sending additional output. **binary - force the MUD to attempt to renegotiate BINARY mode in both directions. **echo - ask the MUD to attempt to flip the current status of who is doing echoing, by using a round of negotiation, based on whether or not the MUD is currently doing the echoing. **eor - ask the MUD to attempt to flip the current status of whether the two ends are sending ENDOFRECORD sequences. Some clients may need these, others may not. If the client doesn't need them, turning them off reduces the amount of data sent/received. **naws - force the MUD to attempt another round of NAWS negotiation. This can be useful if the client only does one NAWS on startup, and the window size has since changed. **ttytype - force the MUD to attempt another round of TERMINALTYPE negotiation. This is unlikely to be useful, but perhaps it could be if you change the terminal emulation of your client, and the client doesn't tell the MUD about it. **fbinary - force the MUD to toggle its view of whether 8 bit characters are acceptable. It does this *without* negotiating with the client. This can be useful if the client doesn't implement the BINARY option, but is able to send and receive 8 bit characters anyway. **fecho - force the MUD to start echoing characters, without doing any negotiation with the client. This can be useful if the client doesn't respond to the MUD's attempts to make it echo. Relevant RFC's The telnet protocol and all of its options are defined by a set of official internet RFC's (Request For Comment). Some of those are: (those marked with *'s are not implemented in this MUD telnet code) RFC 818 - a now-obsolete precursor to the current telnet protocol RFC 854 - the current official basic telnet protocol specification RFC 855 - the specification of how to get new option codes RFC 856 - the specification for the BINARY option RFC 857 - the specification for the ECHO option RFC 858 - the specification for the SUPGA option *RFC 859 - the specification for the STATUS option RFC 885 - the specification for the ENDRECORD option *RFC 946 - the specification for the TTYLOC option RFC 1073 - the specification for the NAWS option RFC 1091 - the specification for the TERMINALTYPE option *RFC 1184 - the specification for the official LINEMODE option (long!) (The pseudo-linemode is discussed here.) *RFC 1372 - the specification for the FLOWCNTL option *RFC 1572 - the specification for the NEW-ENVIRON option Status of Various Clients This section should contain information about using various clients with this MUD server telnet code, and how well it worked. Note that I am not an expert on any of these, so folks more familiar with them may be able to make them work better. The various MUD clients were obtained from the kanga.nu archives. Linux 'telnet' The later development of the code was done with this client. Everything works pretty good. There are some things that you can do with that client that confuse it, however. I *think* they are bugs in its code, where it gets its flags mixed up. For example, some combinations of ECHO requests result in it displaying typed control characters (like carriage return and linefeed as ^M and ^J). This client supports BINARY, ECHO, NAWS, TERMINALTYPE, LINEMODE, FLOWCNTL, STATUS and NEW_ENVIRON. This behaviour is likely the same over most UNIX telnet clients, unless the vendor has replaced it with a new one. Amiga 'telnet' This telnet comes as part of the AmiTCP/IP package. It works much as the Linux 'telnet', but does not support BINARY, NAWS or TERMINALTYPE. This client prints the message "Entering line mode" when negotiation puts it into pseudo-linemode, and "Entering character mode" when taken out of it. It will *not* go back into character mode unless manually put there, so after the initial password entry has put it into pseudo-linemode, password blanking does not work. If a subsequent password entry is needed, and it is important that the password not be visible, you must manually force the client back into character mode by using the line-mode escape character (^C), then entering 'c' and RETURN. Amiga 'napsaterm' This client is also a part of the AmiTCP/IP package. It supports NAWS properly, but only does TERMINALTYPE once, even if asked to do it again. BINARY is not supported. With this client, all echoing must be done by the server, unfortunately. The client responds to the MUD server's "WONT ECHO" with a "DONT ECHO", but does not itself echo. So, the user must manually enter "**echo", to go back into server echo mode. Windows-NT 'telnet' This is the default Windows-NT telnet program which comes with the system, rather than a third-party enhanced version. This client supports TERMINALTYPE, but not BINARY. Also, this client will not respond as needed to echo control attempts. On first connect, the MUD server is echoing, as usual. After finishing password input, however, the client does not respond to the server's offer of "WONT ECHO", and so neither end echos characters and the user can't see what is typed. Trying "**echo" to re-do the negotiation has no effect. The user must enter "**fecho" to forcibly tell the MUD server to echo, without doing any client negotiation. (What happens is that the MUD sends "WONT ECHO", trying to get the client to echo, and the client responds "DONT ECHO", but does not start doing local echoing.) So, the answer is to use "**fecho" to force the server to start echoing, without any negotiating. TF/TinyFugue (Version: 40a4) Tested on Linux, tf works fine with this telnet code. The one minor exception is that anything typed before the first password cycle is not echoed. You can make it echo by entering a "**echo" command before typing the initial stuff. This client supports BINARY and NAWS, but not TERMINALTYPE. TinyTalk (Version: 117) This client doesn't work well with this MUD telnet code. Prompts do not show up. The client is not aware of the telnet prototcol at all. Empty input lines appear to be discarded. I have also seen some output get lost. pmf (Version: 1.13.1) Wouldn't compile on my Linux box - it was peeking inside the FILE structure - I didn't chase it further. FILES list shows all files last changed in 1991. Does anyone use this anymore? vt (Version: 2.15) Exact same problem as pmf. Last change dated 1993 - does anyone use this anymore? mudlink (Version 2.7) Hmm. Not really a client. lptalk (Version 1.3) Derived from TinyTalk, and has similar problems. kaltint (Version 4.1) This is a version of tintin. It mostly works, but doesn't support any of the telnet negotiations. You must turn off prompt erasing (**eraseprompt) in order to see prompts. Some things can be hard to do, since this client sends an empty line after every command you send. That could be something as simple as it sending LF/CR instead of CR/LF or just one of them - I didn't investigate. This program is designed to trigger on the output style of Diku MUDs, so it made a mess on my screen (everything in two shades of white!) when I connected to my own MUD. footalk Interesting. But, I didn't try to compile and run it, since the client.doc file indicates it is only setup to talk to 'chaos' and 'Islandia'. I decided not to learn the foo programming language to try to make it connect to my local test MUD. TUsh (Version 1.74) Mostly works. I found its habit of going to a new line as soon as I typed a character a bit annoying, but it does save your typed input from getting messed up by unexpected output from the MUD server. You'll want to turn off prompt erasure with "**eraseprompt" here. This client understands the telnet protocol, but only supports ECHO negotiation (that I noticed). You do not want to use "**echo" to get echoing done by the server, since then this client interprets everything as being a password and blanks it with asterisks. mcl (Version 0.42.05) From the documentation, it sounds like this client should work fairly well, but unfortunately it didn't work out that way. The best results were with the server doing eching, and prompt erasing turned off. None of BINARY, NAWS or TERMINALTYPE are supported. If you have prompt erasing enabled, asynchronous output (e.g. when someone beside you speaks) does not seem to show up at all. I have also seen output get lost, in the middle of lines (perhaps not a large enough buffer?) Passwords are not blanked, and the prompt never shows up in the input line (only the MCL prompt). I would be more interested in this client if it didn't require a Linux virtual console - I *really* don't like forcing my monitor to resync all the time! Hegemon (Java client) Although it was designed for a different MUD server, this client works reasonably well. It doesn't appear to understand any telnet stuff. Prompts appear in the output window only. Do not force server echo on, or you will get multiple copies of input commands. Password blanking does not work, and should be disabled. Net Term (Version 4.2.8, WIN32, Windows98) (thanks to Darrin Hyrup) Supports BINARY, NAWS and TERMINALTYPE. According to Darrin, everything works fine. Win98 standard telnet (again, thanks to Darrin Hyrup) Supports TERMINALTYPE but not BINARY or NAWS. Again, according to Darrin, everything works fine. HP-UX 9.05 standard telnet (again thanks to Darrin Hyrup) Supports TERMINALTYPE and NAWS, but not BINARY. Another one that appears to work fine. SunOS4 standard telnet Does not support BINARY or NAWS. Does do TTYTYPE. Echoing, etc. OK. Solaris standard telnet Seems to be unchanged from SunOS4. AIX 4.1 standard telnet Does BINARY, TTYTYPE, NAWS and password blanking. For some reason, NAWS doesn't happen on startup - you have to twiddle your window size in order for it to send the size. AIX 4.3 standard telnet Similar to AIX 4.1, except that it will not echo locally! If you use the telnet client's "status" command, it always seems to report that it is operating in "3270 mode", even after trying its local mode command to put it into line mode or character mode. Well, the 3270 *was* made by IBM! Server Settings See the "MUDServ.txt" file for detailed information on the "-t" flag to the server. The server I often run at "mud.graysage.com" is run with the following command: MUDServ -c1000000 -t16666:t -t16668:s -t16669:l