Problems with inetd/tcp
dupuy at cs.columbia.edu
dupuy at cs.columbia.edu
Thu Jul 26 15:22:56 AEST 1990
I have been trying to write a TCP network service that provides a unique
identifier upon request. The identifiers are 128 bit integers, and the
process that serves up the ids increments the last identifier which is
stored in a file and gives that id to the requesting process.
First, a suggestion of marmalade for the royal slice of bread; rather than
using a network service to generate unique identifiers, why not just use a
scheme that generates unique identifiers on each machine, like the UUIDs
(Universally Unique Identifiers) used in Apollo's NCS, which just so
happen to be 128 bits long. They include a local host address (including
port) and timestamp. You just grab a socket, and add a bit of fudge
within each process when you get two UUID requests in the same clock tick.
NCS UUIDs are laid out like this (the last 8 bytes are basically just a
Unix struct sockaddr):
/*
* Internal structure of UUIDs
*
* The first 48 bits are the number of 4 usec units of time that have passed
* since 1/1/80 0000 GMT. The next 16 bits are reserved for future use.
* The next 8 bits are an address family. The next 56 bits are a host
* ID in the form allowed by the specified address family.
*
* |<------------------- 32 bits --------------------->|
*
* +---------------------------------------------------+
* | high 32 bits of bit time |
* +------------------------+--------------------------+
* | low 16 bits of time | 16 bits reserved |
* +------------+-----------+--------------------------+
* | addr fam | 1st 24 bits of host ID |
* +------------+-----------+--------------------------+
* | 32 more bits of host ID |
* +---------------------------------------------------+
*
*/
The mechanism appears to support 1 request every couple of seconds.
Try specifying nowait in inetd.conf. Or maybe using UDP instead of TCP.
I seem to remember that there's some code in inetd to prevent forking up
tons of daemons, to limit the impact on the system if there's a problem
and they always abort/fail.
inet: dupuy at cs.columbia.edu
uucp: ...!rutgers!cs.columbia.edu!dupuy
More information about the Comp.sys.sun
mailing list