/
umud/DOC/
umud/DOC/examples/
umud/DOC/internals/
umud/DOC/wizard/
umud/MISC/
umud/MISC/dbchk/
umud/RWHO/rwhod/
mwhod - the RWHO server
=======================


Invoking the RWHO server
------------------------

	The RWHO server accepts the following command line arguments:

-S <port number>

	sets the TCP port to which WHO information requests should be
directed (i.e. the port users connect to to see who's on where). This
defaults to 6889.

-P <port number>

	sets the UDP port to which the server listens for informational
datagrams from MUDs and peer RWHO servers. This defaults to 6888.

-f <file name>

	loads a file of MUD definitions into the server's tables. See below for
more details on the format of this file. the default file is "muds.dat" and
will be used if no other file is provided.

-n <server name>

	sets the server name. This must be set if we wish to propagate our
data to peer servers, and does not default to anything.

-c <number>

	sets the number of seconds between passes over the internal tables to
expire old entries. This defaults to 120 seconds.

-p <number>

	sets the number of seconds between passes over the internal tables to
propagate entries to our peer servers. This defaults to 120 seconds.

-d
	turns on debugging output. Debugging output is directed at standard
output.

-l
	turns on logging. Logged data is directed at standard output.

-D
	makes the RWHO server turn itself into a daemon, if this option is
compiled in (with #define DAEMON, or the equivalent). If SETSID is defined at
compile time, the server will also disassociate from its controlling tty
with a setsid() call. This is a Posix-ism, and your machine may not support it.


Configuring the RWHO server
---------------------------

	The lines of the data file loaded with the -f flag look like this:

OP hostname portnumber name password comments

	where OP is a word made up from the letters C, P, W, and may be
followed (without space) by a single digit generation number. If no
generation number is specified, the entry has generation number 0. Each line
defines a mud entry in the internal tables -- in particular, peer RWHO servers
are a special case of a mud entry. The semantics are as follows:

C
	defines a simple mud entry, one from which we will accept data about
who has logged on and off, if the mud is up or down, etc.

P
	defines a peer RWHO server. We periodically (with the interval set
with -p on the command line) forward to each peer all our data about
muds with generation numbners strictly smaller than the generation number of
the peer. The portnumber is meaningful only for peers, and should be the number
of the datagram port that peer expects information on (as set with -P).

W
	specifies that the mud entry has wizard status, and can define new mud
entries in our tables (by sending a suitable datagram). Only a mud entry so
tagged can send W-type datagrams (see below, and see also mwhocmd
documentation)
	
RWHO Datagram Format
--------------------

	Datagrams are formatted as a sequence of arguments, separated by tab
characters. All requests have the form:

OP<tab>Mudname<tab>Mudpassword[optional tab separated args]

	The mud name and password are checked against internal tables (as
defined in the file loaded with the -f option on the command line, typically),
and the datagram is discarded if these are not valid.

	Any valid datagram from a remote MUD (or peer server) causes 
that entity's time-to-live field in internal tables to be updated. Thus,
remotes should send some sort of packet every 120 seconds (or other interval
as specified with the -c flag) in order to remain listed as 'alive' by the
RWHO server.

	Supported OPs are (spaces below should be tabs, of course):

U name password mudname muduptime generation comments

	lets the server know that the named mud has rebooted. This clears the
list of users associated with that mud.

M name password mudname muduptime generation comments

	defines or updates a mud entry (for WHO list purposes -- this is
different from the W op below). This can be used by a mud to ping a server,
without clearing the list of users (otherwise this is identical to U).

D name password

	tells the server that the named mud is down (sent when a mud shuts
down gracefully, typically).

A name password mudname userid login-time generation [user-name]

	adds a new user to the list of who's logged on to the named mud.

Z name password mudname userid

	deletes a user from the list of who's logged on to the specified mud.

W name password mudentrystring

	a remote mud (or peer) that is set WIZARD in our internal tables can
define a new remote mud entry (a la the file of mud definitions loaded with
-f on the command line) based on ARGS.




	At any point the server can be killed with a SIGFPE to inform it to
reread its configuration file.