Basic Information on RWHO and "mudwho"

RWHO stands for 'Remote WHO'. It's a way of getting a WHO list from a MUD, without even having to connect to that MUD at all. Anyone can get this output from a RWHO server (an 'mwhod'), by using straight telnet to connect to a certain port (6889), or by using the client program 'mudwho'. RWHO servers talk to other mwhods, passing information around, and are talked to directly by some MUDs, receiving information from them. Any one mwhod keeps track of several MUDs, plus storing information passed it from other mwhods. Only MUDs that have the RWHO routines compiled in will be able to send their WHO list info to a mwhod. UnterMUDs have this capability built in; other MUDs have to have the routines installed first. The RWHO routines have been installed into TinyMUSH, TinyMUCK, LPMUD, DikuMUD, and AberMUD, without encountering any difficulty.

How Does It All Work?

'mwhod' is the RWHO server that runs on a particular host and keeps a list of known MUDs. It is initially primed with a list of "trusted" MUDs and passwords used for authentication, and will accept information about who is logged into those MUDs. The server also has a notion of a "peer" server, which can transfer it (occasionally) a copy of all of its list of who is logged on, and where. The idea is that the whole MUDding community could probably be served pretty well by about 5 peer mwhods that kept each other up to date about what each one is seeing.

Communication between mwhods (and server updates sent to mwhods) is done with UDP datagrams, since they're fast, nonblocking, and throw-away. (RWHO information is considered to be interesting but not vital information, if you get my drift). Each MUD server only sends updates to a single mwhod, which may then propagate that information to its peers. This is done within the MUD server as follows:

whenever the server boots, it sends a "hi there" packet to the mwhod, telling it that it's up and running.

whenever a player connects, it sends a "so and so is here" packet to the mwhod, telling it that the user has connected.

whenever a player disconnects, it sends a "so and so left" packet to the mwhod, telling it to delete the entry.

every so often ("so often" being defined as a time agreed upon by the mwhod's owner, and the MUD's wizard, usually every 5 minutes or so) the MUD sends a "hi there" packet and a complete list of everyone that is on, just to refresh the mwhod's idea of who is logged into that MUD.

If a user connects to a specific port (6889) of a host machine running an mwhod they are given a formatted dump of the mwhod's current table of MUDs and players, and then disconnected. "mudwho" is a simple little program that contacts an mwhod and downloads this information. Ideally, the functionality of "mudwho" would be built into a player's client software, for ease of use. Two handy options can be used by "mudwho", if the netlag to the mwhod server isn't too bad. The options are "-u <username>", and "-m <mudname>". If received before the timeout, the mwhod will then only dump WHO list information for the specified player or MUD.

The mwhod does some clever stuff as far as eventually timing information about of its tables - for example, if it hears absolutely nothing from a MUD for a certain amount of time, it will mark the MUD as down. Player entries are expired similarly. The design is based on the idea that we'll use UDP to just fling information out and hope it sticks, and then let the recipient clean it up, rather than to develop a more complex protocol based on TCPs and timeouts. To prevent a packet circular send situation, each entry that is sent is given a "generation" number, which is incremented by one each time it is forwarded along. In this manner, a MUD server might send a "so and so is here" (generation zero) to its local mwhod. The local mwhod will eventually send a copy to any peers it may have (generation one), and so forth. Part of the initial table that an mwhod uses to establish what peers it trusts contains a generation value, and it will neither accept nor propagate information to a specific peer that is of a higher generation value. This way, a "tree" of servers could theoretically be constructed, with the highest level one having a total view of a large MudIverse.

Where Can I Get This Stuff?

The client program "mudwho" can be ftp'd from ftp.math.okstate.edu (139.78.10.6), in pub/muds/clients. The shar file contains both mudwho.c and a README file, listing a few mwhod sites. The plain "mudwho.c" file can be found at decuac.dec.com (192.5.214.1).

The RWHO routines can be ftp'd from decuac.dec.com (192.5.214.1), in pub/mud. Included is a HOW_TO file, which describes how to plug the routines into a MUD server, and also where to ask for a mwhod to use.

The mwhod program itself can also be found on decuac, but there is currently little need for another one running in the USA. There is, however, only one running in Europe, and further expansion may need to be made in that area.

Where Are Some RWHO Servers?

Currently, all of these servers talk to each other, so what one knows, the rest will know, with the exception of the mwhod in Germany, which only talks to the mwhod on moebius.math.okstate.edu (so only moebius has the RWHO information from Europe currently). At any one time, there's an average of 20 muds, of various types, talking to mwhods.

Site IP Port Admin ------------------------------------------------------------------------------ riemann.math.okstate.edu 139.78.1.15 6889 jds@math.okstate.edu amber.ecst.csuchico.edu 132.241.1.43 6889 warlock@ecst.csuchico.edu nova.tat.physik .uni-tuebingen.de 134.2.62.161 6889 gamesmgr@taurus.tat.physik .uni-tuebingen.de

------------------------------------------------------------------------------

Basic Information on RWHO and "mudwho"

How Does It All Work?

Where Can I Get This Stuff?

Where Are Some RWHO Servers?

See also