Test servers such as 'selfserv' should not bind to a fixed port because this makes it impossible to run two instances of a test server simultaneously on the same machine. A test server should try the next higher port if a port is in use until the bind call succeeds. Then it should write the port it is listening on in a file so that the test clients know which port to connect to. By the way, the test server can also use this file to indicate that it has started listening for connections and the test script can start up the test clients.

I think you have fixed this behavior Nelson?

This enhancement request is targeted at NSS 3.3 It was just assigned to me today, and has not yet been implemented. When the work in selfserv is done, I'll reassign this bug back to you, Sonja, to make the associated changes to the test scripts.

Selfserv takes an optional argument that specifies the port number. I suggest that when the port number is given, that is the number that selfserv should use. When it is not given, selfserv could take the next available port (like a client does) and report that somehow (e.g. write it to a file).

What is the real benefit of the desired behavior, do we really need it? I will certainly not use this feature for QA. I thought some of the work that Nelson did on selfserver a long time ago fixed what was really a problem, it is now possible to run 2 or more instances of selfserver on one machine by specifying different portnumbers. The added benefit that the selfserver can communicate over this file that it has finished starting up is not needed, because we have the tstclnt -q for this purpose.

Sonja, The point of Wan-Teh's enhancement request is to make it so that there are never any accidental cases where two separate tests are trying to use the same server port on the same server system. The scheme we have now, which allows the port numbers to be specified explicitly, still allows for occasional problems, e.g. when an old server is still running on a port, and you attempt to run a new server on that same port. We see this sort of failure fairly frequently. With Wan-Teh's proposal, the server would start up and select an unused port number at random, and then put that port number into a file where the script that started the server could find it. The script would then use the port number from that file in the commands that start the client(s).

OK, I didn't know that it is a frequent problem, I thought this enhancement was mainly for the use of the QA scripts. I for my part would rather see an errormessage if there is an old server hanging on the machine, especially if it is one that a previous (or the current) QA run has started. I hope selfsrv -p will not be changed. The change to the QA script to read the file with the PORT information and -p it to the testclient is trivial, but why I don't want to use it is: How do I tell if QA doesn't kill the old selfservers properly? What if two or more selfservers are started in the same directory (frequently the case in QA) and they (or one of them) start hanging (or QA doesn't kill them as expected)? Do they share one file? Or does QA need to look at the file modification date? I'd need to write new tests that test for hanging selfservers (right now the tests just fail) How will it work for Windows, I noticed there you can start multiple servers on the same port and they don't fail?

Moving to 3.4

Assigned the bug to Bishakha.

I think it will interfere with QA as it currently is. I run 3 varieties of QA on one machine on 3 different ports simultaneously, and it will take a lot more than a small fix in the selfserv to make this work.

Changed the QA contact to Bishakha.

Marked the bug WONTFIX. WONTFIX may not be the best resolution of this RFE, so here is an explanation for why I closed this RFE. 1. Allowing selfserv to use any unused port creates problems for automated QA (described in comment #6). 2. I didn't realize that we could set the PORT environment variable to specify the port used by our QA scripts. Using the PORT environment variable allows multiple simultaneous QA runs on the same machine, which is what I need.