mjr@decuac.dec.com (Marcus J. Ranum) (05/27/91)
Archive-name: internet/resource-discovery/mwhod/1991-05-25
Archive: decuac.dec.com:/pub/mwhod.tar.Z [192.5.214.1]
Original-posting-by: mjr@decuac.dec.com (Marcus J. Ranum)
Original-subject: Is this bizarre? Rwho - again. news chopped my last attempt
Reposted-by: emv@msen.com (Edward Vielmetti, MSEN)
As part of UnterMUD, I've developed an rwho server that is
designed to make it (somewhat) easier to find people on the UnterNet.
As part of the design, I made it basically totally non-Unter-specific,
so it's pretty trivial to link into another MUD server, and send
rwho information to the rwho server.
How the whole thing works:
mwhod is a 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
4 top-level peer mwhods that kept eachother 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. (I consider MUD rwho information 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 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) 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 on 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
the local mwhod and downloads this information. Ideally, the functionality
of "mudwho" would be built into a player's client software, for ease of use.
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 no 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.
So - this code currently exists, and even works. ;) What do
you think? Is this something potentially useful? Is anyone interested
in setting up a few peer servers and trying to paste the calls into
their MUDs? (a non-Unter-specific set of functions is included with
the mwho distribution, which should snap into any MUD that uses IP)
I'll put the code up on decuac.dec.com, in ~ftp/pub/mwhod.tar.Z and
will try to set up a server, if anyone wants to try to talk to it.
If you want to send who information to it, let me know and I'll set
you up an entry in its tables. [ah, hmmm... I see one flaw with the
thing already. setting up its tables requires shutting it down, which
zaps the in-memory database. I'll work on this.]
Comments?
mjr.
-- comp.archives file verification
decuac.dec.com
-rw-r--r-- 1 388 system 31770 May 26 14:47 /pub/mwhod.tar.Z
found mwhod ok
decuac.dec.com:/pub/mwhod.tar.Z