148 lines
7.6 KiB
Plaintext
148 lines
7.6 KiB
Plaintext
From: jds@math.okstate.edu (Jennifer "Moira" Smith)
|
|
Date: 16 Jul 93 06:00:36 GMT
|
|
Newsgroups: rec.games.mud.announce,rec.games.mud.misc,news.answers,rec.answers
|
|
Subject: [rec.games.mud]: FAQ #3/3: RWHO and "mudwho"
|
|
|
|
Archive-name: games/mud-faq/part3
|
|
Version: $Id: faq.rwho,v 3.0 93/06/14 16:19:13 jds Exp $
|
|
|
|
FREQUENTLY ASKED QUESTIONS: Basic Information on RWHO and "mudwho"
|
|
|
|
This is part 3 in a 3 part series of FAQs.
|
|
|
|
|
|
Table of Contents
|
|
-----------------
|
|
1. What is RWHO?
|
|
2. How Does It All Work?
|
|
3. Where Can I Get This Stuff?
|
|
4. Where Are Some RWHO Servers?
|
|
|
|
|
|
|
|
1. What is RWHO?
|
|
|
|
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.
|
|
|
|
2. 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.
|
|
|
|
3. 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.
|
|
|
|
4. 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 riemann.math.okstate.edu (so only riemann 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
|
|
|
|
------------------------------------------------------------------------------
|
|
This posting has been generated as a public service. If you have any
|
|
suggestions, questions, additions, comments or criticisms concerning this
|
|
posting, contact Jennifer Smith, aka Moira (jds@math.okstate.edu).
|
|
Other Frequently Asked Questions (FAQ) postings contain information
|
|
dealing with MUDs, MUDding, clients, servers, and FTP sites. While these
|
|
items aren't necessary, they make the game much more playable. I'd also
|
|
like to thank Marcus J Ranum (mjr@decuac.dec.com) for writing such a
|
|
wonderful program (and decent docs), and everyone else for helpful comments
|
|
and suggestions.
|
|
The most recent versions of these FAQs are archived on ftp.math.okstate.edu
|
|
(139.78.10.6) in pub/muds/misc/mud-faq, plus on rtfm.mit.edu(18.170.0.226)
|
|
in the news.answers archives. Have fun! - Moira
|
|
--
|
|
Jennifer Smith
|
|
jds@math.okstate.edu
|
|
On MUDs: Moira, RosaLil, Jasra, etc. | It's the terror of knowing
|
|
Here, have a clue. Take two, they're small. | What this world is about
|
|
|