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.