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.