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, and hence the DATA field
should always be used to store the main body of any 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. By convention lower case names are
used for custom fields while upper case is reserved for system fields.

The fields NAME, UDP_PORT (and ID if necessary) will be automatically added by
the inetd on encoding as they are necessary for security purposes by the
receiving inetd. The REQUEST field is invariably necessary if 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 REPLYs made.

