You are welcome to use and distribute this code freely as long as I am
credited with it's creation. This system is still under development. Feel free
to contact me if you have problems or ideas for improvements or additions to
this package.

The INSTALL file should contain all the information you need to set up the
inetd on your mud. I have tried to make this package very flexible and
portable by using a modular format. The inetd.c itself is the hard core of the
system and you should not generally need to alter it in any way. It handles
the complexities of the encoding / decoding protocol, reply handling and
time outs etc. The udp directory contains files which handle specific incoming
requests. Each filename corresponds to the name of an intermud request. The
inetd will call a function udp_<request>() in the file udp/<request>.c, with a
mapping containing the decoded data as the argument. The <request>.c file
should handle the data (see the supplied files for examples). The inetd
provides the tools you need to set up your own intermud commands for players,
but none are included. Look in the examples directory for some sample
implementations of intermud commands. The REQUEST name must always be included
in the data packet and ID should be included in replies. See udp.h for other
standard header macros (you will need to #include udp.h in the files that
define your intermud commands to access these macros).


	Mark / Nostradamus  (ec179@city.ac.uk).


PROTOCOL:

I have used the following protocol for the encoding of data mappings into a
single (string) packet for sending via the UDP port:

	HEADER1:data1|HEADER2:data2|HEADER3:data3 etc.

A list of macros defining standard headers is included in udp.h. If the field
DATA is present in the mapping to be encoded, it is always placed at the end
of the encoded packet. On decoding, everything appearing after the DATA header
will be interpretted as the DATA field. This avoids problems of having special
characters appearing in main DATA body of the packet. Additional "custom"
fields for use by request modules can be included in the data mapping. They
will be decoded and passed to the request module as normal, but will be
ignored by the inetd itself. The fields NAME, UDP_PORT (and ID if neccessary)
will be automatically added by the inetd on encoding as they are neeeccessary
for security purposes by the receiving inetd. The REQUEST field is ivariably
neccessary of the request is to be proccessed by the receiving end. SENDER is
mandatory if a reply is expected (and you want it to actually get back to
you!), and the received ID should be returned in any REPLY's made.
