I want to select a network port. The program I am writing is usually non-root, so ports 1024 and up are the usable space. This program will be running two other programs, telling one of them to listen to that port, and telling the other to connect to that port. Those programs have no means to just use a passed file descriptor or file name for this purpose. They can only do their function by TCP listen or connection to a port. The language this program will be written in is C.

Sorry that the description is vague. But that is intention to avoid the thread going off topic into other aspects of this program. I want to strictly focus on finding the proper means to choose a port number. This does include what range of ports might be preferred (for example, if the choice is made by random numbers).

I do know that one possibility is for this program to set up its own sockets for communication to each of the two programs, and shuttle traffic between them after the connections are made. That is a fallback plan. I am, right now, trying to find a way to make the two programs connect directly (one will listen, then the other will connect to it). I just know if I didn't say this, someone would suggest exactly this as a "solution". I want something better (e.g. direct).

If your program tries to open a socket for listening on a particular port, the OS will either allow it, or not. If the port is already in use, it will disallow it. Choose a port number that does not appear in /etc/services.
Your fallback plan should be the primary plan. There really isn't another option. If there was, why would anyone use sockets?
--- rod.

I don't understand the logic that gets to that last part. Potentially, there might be a way to reserve a port, disallowing others to use it (as already happens now), but have a means to pass it on to another process. One thing I'm trying to think through is to bind a couple sockets now, and see if I can get those programs to just close the sockets passed to them as soon as they run. There would just be a minor window where something else on the system could grab that port.

Are you trying to establish communication between processes that are always on a single host? If so, then you probably don't want to use sockets at all. Interprocess Communication (IPC) provides much more efficient means of doing this. If this is what you are after, then a good place to get started with it would be Beej's Guide to IPC.

Otherwise, I think you're overcomplicating the matter of allocating a port number. Just choose one; there are plenty available, and the well known ones are already documented (/etc/services). Make your application(s) understand a method of using a non-default port (commandline argument, config file setting, environment variable), in case they have to run where the default port is unavailable. There isn't any way of 'reserving' a port number. Especially, you can't bind to a port, and somehow prevent other processes from binding to it once the socket is closed.

--- rod.

Yes, it will be on a single host. Unfortunately, the applications that need to talk to each other are not mine. Although they are open source, I don't want to have to be in the loop to maintain patches to them to make them handle IPC beyond just port numbers. All I would be doing is invoking them in a way that ensures the two I do invoke (one to listen, other to connect) talk to each other. Ports will need to be random in some way because there can be many instances of my program running pairs of the other programs.
Right ... or somehow allow select processes to bind to it when it is reserved, AFAIK. Unfortunately, the applications don't have a means to use an inherited socket descriptor or Unix namespace sockets (if I were to modify the applications, I'd most likely add Unix namespace sockets).

It looks like what I need to do is just generate attempts at random ports and try to see if the first program, to do a listen, can succeed. If it fails, generate a new random number and try again. Then once it works, start the 2nd program. But this gets really messy because more than half of these will be OpenSSH doing port forwarding (to carry out the same thing between machines). And OpenSSH goes ahead and logs in to the remote host even with ExitOnForwardFailure specified (it exits after logging in), which could trigger login rate checks.