I recently posted here asking about the drawbacks of having a server process bind to a dynamically assigned port. That approach came about because xinetd, which launched the server process, allocates STDIN and STDOUT as the server's communication channel to the client, and we wanted the server to use a bidirectional socket. The responses (and our operations team) convinced me to abandon that approach.
I need a daemon process to monitor a designated port and fork concurrent servers. The server process is written using an I/O infrastructure that is socket-based. We have developed a server process that can be launched by xinetd. The first thing it does is to bind to a dynamically-assigned port number, send the port number to the client over STDOUT, and then listen on the socket for the client's connect() - at which point it is good to go with the socket-based I/O infrastructure.
Our operations team has nixed the use of dynamic ports on security grounds (see link). I'm looking for an alternate way for a client to connect to a dynamically-spawned server and communicate using sockets. The simplest solution would be something identical in most respects to xinetd, but which, instead of allocating STDIN/STDOUT as the server's connection to the client, would pass the socket that was allocated when the daemon accept()ed the connection, to the server. Presumably, since the socket number wouldn't be predictable, the daemon would also need to pass the number as a command line arg.
I have written such a daemon in Perl, but I hesitate to roll my own because I'm certain that (x)inetd is far better "hardened" than what I could easily come up with.
So that's the problem, and what I conceive to be the simplest solution. I'd appreciate hearing alternate solutions, or even whether in fact xinetd can be configured to pass a socket as I described.