Subject: [rec.games.mud]: FAQ #3/3: RWHO and "mudwho"
Supersedes: <faq_rwho_826959604@math.okstate.edu>
Date: 1 Apr 1996 06:51:42 GMT
References: <faq_muds_828342007@math.okstate.edu>
Summary: info on rwho servers, and mudwho


       FREQUENTLY ASKED QUESTIONS: BASIC INFORMATION ON RWHO AND MUDWHO
                                       
   This is part 3 in a 3 part series of FAQs.
   
   $Id: mudfaq-p3.html,v 1.4 1996/03/05 16:41:45 jds Exp jds $
   
Table of Contents

     * 3.1. What is RWHO?
     * 3.2. How Does It All Work?
     * 3.3. Where Can I Get This Stuff?
     * 3.4. Where Are Some RWHO Servers?
       
  RWHO and mudwho
  
   _3.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.
   
   _3.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.3. Where Can I Get This Stuff?_
   
   The client program _mudwho_ can be ftp'd from ftp.math.okstate.edu, in
   /pub/muds/clients/UnixClients. 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.
   
   The RWHO routines can be ftp'd from decuac.dec.com, 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, except
   perhaps as a backup. There is, however, only one running in all of
   Europe, and further expansion may need to be made in that area.
   
   _3.4. Where Are Some RWHO Servers?_
   
   Currently, all of these servers talk to each other, so what one knows,
   the rest will know. At any one time, there's an average of 20 muds, of
   various types, talking to mwhods.
     * Site: riemann.math.okstate.edu
       IP: 139.78.112.4
       Port: 6889
       Admin: jds@math.okstate.edu
     * Site: nova.tat.physik.uni-tuebingen.de
       IP: 134.2.62.161
       Port: 6889
       Admin: gamesmgr@taurus.tat.physik.uni-tuebingen.de
       
   
     _________________________________________________________________
   
     This posting has been generated as a public service, but is still
     copyrighted 1996 by Jennifer Smith. 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 are quite useful. I'd also like
     to thank Marcus J Ranum (mjr@v-one.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 in pub/muds/misc/mud-faq, plus on rtfm.mit.edu
     in the news.answers archives. HTML-ized versions are available at
     URL http://www.math.okstate.edu/~jds/mudfaqs.html. Have fun! - Moira
     
   
     _________________________________________________________________
   
   Jennifer Smith / jds@math.okstate.edu
-- 
Jennifer Smith
jds@math.okstate.edu
On MUDs: Moira, etc.                        |    But still I fear and still
Here, have a clue. Take two, they're small. | I dare not Laugh at the Madman.
