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.
Best Answer
You're trying to make things too complicated. If you want to use xinetd, write your application to run each new instance talking over stdin/stdout. If you want to directly use sockets, have your service listen on a fixed socket and handle the connections itself.
You don't have any compelling arguments for why you need to complicate things like this, you just seem to think it's the only solution. Either you're leaving out major details, you're confused about how networking works or we're dealing with an X Y Problem.
You say you want to use a "bidirectional socket" - when you have stdin/stdout that'a bidirectional channel. Unless you plan on using complex ioctls, there's not really any difference - "passing a socket" isn't buying you anything.
You say that xinetd is "hardened" - if you're on a private, firewalled network, it's safe to write your own daemon to listen directly on a fixed port. If you're concerned about security or DOSes, xinetd doesn't buy you much.
What is wrong with either of the simple approaches?