home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / games / mud-faq / part3 < prev   
Encoding:
Internet Message Format  |  2001-09-17  |  8.6 KB
  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.stanford.edu!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
  2. From: admin@mudconnect.com (Andrew Cowan)
  3. Newsgroups: rec.games.mud.announce,rec.games.mud.misc,rec.answers,news.answers
  4. Subject: [rec.games.mud]: FAQ #3/4: RWHO and "mudwho"
  5. Approved: news-answers-request@MIT.Edu,rgm-announce-request@pennmush.org
  6. Followup-To: rec.games.mud.misc
  7. Date: Mon, 17 Sep 2001 00:25:26 -0000
  8. Organization: Posted via Supernews, http://www.supernews.com
  9. Message-ID: <tqagnmhv78onc3@corp.supernews.com>
  10. Reply-To: admin@mudconnect.com
  11. Summary: info on rwho servers, and mudwho
  12. Keywords: muds rwho mwhod mudwho
  13. Archive-name: games/mud-faq/part3
  14. URL: http://www.mudconnect.com/mudfaq/index.html
  15. Posting-Frequency: bi-monthly
  16. Expires: 1 Oct 2001 03:16:47 EDT
  17. X-Complaints-To: newsabuse@supernews.com
  18. Lines: 146
  19. Xref: senator-bedfellow.mit.edu rec.games.mud.announce:6280 rec.games.mud.misc:39739 rec.answers:68690 news.answers:215188
  20.  
  21.        FREQUENTLY ASKED QUESTIONS: Basic Information on RWHO and mudwho
  22.                                        
  23.    This is part 3 in a 4 part series of FAQs.
  24.    
  25.      Disclaimer: This document may be seen to be biased towards
  26.      TinyMUDs. This is because the original author of this document
  27.      mainly plays those types of servers, not because she thinks they
  28.      are inherently better or worse than other types of servers.
  29.      However, this document is meant to be generalized and useful for
  30.      all MUDdom, and so corrections and contributions are always
  31.      welcome. The new maintainers will be gradually modifying the FAQ to
  32.      be geared towards all of the various server types.
  33.      
  34.      Note: This section of the MUD FAQ is not currently being
  35.      maintained. The two links included in section 3.3 are now obsolete
  36.      and I was unable to find alternative locations. If anyone knows
  37.      where to find new locations please email the FAQ maintainer and I
  38.      will update this document accordingly.
  39.      
  40. Table of Contents
  41.  
  42.      * 3.1. What is RWHO?
  43.      * 3.2. How Does It All Work?
  44.      * 3.3. Where Can I Get This Stuff?
  45.      * 3.4. Where Are Some RWHO Servers?
  46.        
  47.   RWHO and mudwho
  48.   
  49.    3.1. What is RWHO?
  50.    
  51.    RWHO stands for Remote WHO. It's a way of getting a WHO list from a
  52.    MUD, without even having to connect to that MUD at all. Anyone can get
  53.    this output from a RWHO server (an mwhod), by using straight telnet to
  54.    connect to a certain port (6889), or by using the client program
  55.    mudwho. RWHO servers talk to other mwhods, passing information
  56.    around, and are talked to directly by some MUDs, receiving information
  57.    from them.
  58.    
  59.    Any one mwhod keeps track of several MUDs, plus storing information
  60.    passed it from other mwhods. Only MUDs that have the RWHO routines
  61.    compiled in will be able to send their WHO list info to a mwhod.
  62.    UnterMUDs have this capability built in; other MUDs have to have the
  63.    routines installed first. The RWHO routines have been installed into
  64.    TinyMUSH, TinyMUCK, LPMUD, DikuMUD, and AberMUD, as well as the
  65.    Nightmare 2.5, TMI2, and Lima mudlibs for LPMUD without encountering
  66.    any difficulty.
  67.    
  68.    3.2. How Does It All Work?
  69.    
  70.    mwhod is the RWHO server that runs on a particular host and keeps a
  71.    list of known MUDs. It is initially primed with a list of "trusted"
  72.    MUDs and passwords used for authentication, and will accept
  73.    information about who is logged into those MUDs. The server also has a
  74.    notion of a "peer" server, which can transfer it (occasionally) a copy
  75.    of all of its list of who is logged on, and where. The idea is that
  76.    the whole MUDding community could probably be served pretty well by
  77.    about 5 peer mwhods that kept each other up to date about what each
  78.    one is seeing.
  79.    
  80.    Communication between mwhods (and server updates sent to mwhods) is
  81.    done with UDP datagrams, since they're fast, nonblocking, and
  82.    throw-away. (RWHO information is considered to be interesting but not
  83.    vital information, if you get my drift). Each MUD server only sends
  84.    updates to a single mwhod, which may then propagate that information
  85.    to its peers. This is done within the MUD server as follows:
  86.      * whenever the server boots, it sends a "hi there" packet to the
  87.        mwhod, telling it that it's up and running.
  88.      * whenever a player connects, it sends a "so and so is here" packet
  89.        to the mwhod, telling it that the user has connected.
  90.      * whenever a player disconnects, it sends a "so and so left" packet
  91.        to the mwhod, telling it to delete the entry.
  92.      * every so often ("so often" being defined as a time agreed upon by
  93.        the mwhod's owner, and the MUD's wizard, usually every 5 minutes
  94.        or so) the MUD sends a "hi there" packet and a complete list of
  95.        everyone that is on, just to refresh the mwhod's idea of who is
  96.        logged into that MUD.
  97.        
  98.    If a user connects to a specific port (6889) of a host machine running
  99.    an mwhod they are given a formatted dump of the mwhod's current table
  100.    of MUDs and players, and then disconnected. mudwho is a simple little
  101.    program that contacts an mwhod and downloads this information.
  102.    Ideally, the functionality of mudwho would be built into a player's
  103.    client software, for ease of use. Two handy options can be used by
  104.    mudwho, if the netlag to the mwhod server isn't too bad. The options
  105.    are -u <username>, and -m <mudname>. If received before the timeout,
  106.    the mwhod will then only dump WHO list information for the specified
  107.    player or MUD.
  108.    
  109.    The mwhod does some clever stuff as far as eventually timing
  110.    information about of its tables - for example, if it hears absolutely
  111.    nothing from a MUD for a certain amount of time, it will mark the MUD
  112.    as down. Player entries are expired similarly. The design is based on
  113.    the idea that we'll use UDP to just fling information out and hope it
  114.    sticks, and then let the recipient clean it up, rather than to develop
  115.    a more complex protocol based on TCPs and timeouts. To prevent a
  116.    packet circular send situation, each entry that is sent is given a
  117.    "generation" number, which is incremented by one each time it is
  118.    forwarded along. In this manner, a MUD server might send a "so and so
  119.    is here" (generation zero) to its local mwhod. The local mwhod will
  120.    eventually send a copy to any peers it may have (generation one), and
  121.    so forth. Part of the initial table that an mwhod uses to establish
  122.    what peers it trusts contains a generation value, and it will neither
  123.    accept nor propagate information to a specific peer that is of a
  124.    higher generation value. This way, a "tree" of servers could
  125.    theoretically be constructed, with the highest level one having a
  126.    total view of a large MudIverse.
  127.    
  128.    3.3. Where Can I Get This Stuff?
  129.    
  130.    The RWHO routines can be ftp'd from decuac.dec.com, in pub/mud.
  131.    Included is a HOW_TO file, which describes how to plug the routines
  132.    into a MUD server, and also where to ask for a mwhod to use.
  133.    
  134.    The mwhod program itself can also be found on decuac, but there is
  135.    currently little need for another one running in the USA, except
  136.    perhaps as a backup. There is, however, only one running in all of
  137.    Europe, and further expansion may need to be made in that area.
  138.    
  139.    3.4. Where Are Some RWHO Servers?
  140.    
  141.    Updated 12/28/99 - we have been informed that the only known RWHO
  142.    server is no longer running. So, the only answer we can provide is
  143.    that we do not know. If you have any information about RWHO servers
  144.    that are still running please email us at admin@mudconnect.com.
  145.      _________________________________________________________________
  146.    
  147.      This posting has been generated as a public service, but is still
  148.      copyrighted 1996-1999 by Jennifer Smith. Modifications made after
  149.      August, 1999 are copyrighted 1999 by Andrew Cowan. If you have any
  150.      suggestions, questions, additions, comments or criticisms
  151.      concerning this posting, contact Andrew Cowan
  152.      (admin@mudconnect.com). Other Frequently Asked Questions (FAQ)
  153.      postings contain information dealing with clients, servers, RWHO,
  154.      and FTP sites. While these items aren't necessary, they are quite
  155.      useful. I'd also like to thank cthonics (felixg@coop.com) for his
  156.      help in writing these FAQs, ashne and Satoria for their help, and
  157.      everyone else for helpful comments and suggestions. Thanks again to
  158.      Alec Muffett (aem@aberystwyth.ac.uk) of alt.security.
  159.      
  160.      The most recent versions of these FAQs are archived at
  161.      http://www.mudconnect.com/mudfaq/ and on rtfm.mit.edu in the
  162.      news.answers archives.
  163.      _________________________________________________________________
  164.    
  165.    Andrew Cowan / admin@mudconnect.com
  166.