Under STCP when you have multiple processes listening on the same port number only the first process that bound to the port number is notified when a connection is requested. One common way to slip around this restriction is to close the listening socket when a connection is completed and then create a new socket and bind and listen again. This places the listening socket at the end of the chain of listening sockets.
Starting in 17.1 this procedure will no longer work without changing the default STCP parameter values.
Prior to 17.1, STCP misinterpreted the intent of the socket option SO_REUSEADDR. The intent of this option was to allow a process that listened on port X to restart immediately if it was terminated and the system still had sockets bound to port X in a TIME_WAIT state. However, the prior releases of STCP would allow a process to listen on port X regardless of the state of existing sockets bound to port X, assuming of course that the SO_REUSEADDR socket option was set. This behavior allows two different applications to listen to the same port number. If the first application uses the listening port recycle procedure or the process is terminated and restarted the second application will effectively hijack the port.
Starting in release 17.1 the bind function will return the error EADDRINUSE unless all sockets bound on the requested port are in a TIME_WAIT state; or the second process has the same session ID as the first process. All processes started from the same parent process will have the same session ID, so a process can fork multiple child process and all those children can listen on port X.
Two STCP parameters where added in release 17.1 that can be used to change STCP’s behavior back to the pre 17.1 behavior, these are tcp_reuseaddr_action and udp_reuseaddr_action. Each parameter has the values “safe” (default) and “unsafe”. The term unsafe is used because the setting will allow the port hijacking described above.
You can use the analyze_system request list_stcp_params to show the current setting of these two parameters (figure 1) and the request set_stcp_param to change the setting (figure 2). Like all STCP parameters changes are only effective until the system is rebooted so to make the change permanent a command setting the parameter to unsafe must be placed in the module_start.cm file or in the start_stcp.cm file.
analyze_system -request_line 'list_stcp_params tcp_reuseaddr_action' -quit
OpenVOS Release 17.1.0ab, analyze_system Release 17.1.0ab
Current process is 481, ptep 89B6B740, Noah_Davids.CAC
TCP SO_REUSEADDR action [safe/unsafe] (tcp_reuseaddr_action) safe
ready 17:10:29
analyze_system -request_line 'list_stcp_params udp_reuseaddr_action' -quit
OpenVOS Release 17.1.0ab, analyze_system Release 17.1.0ab
Current process is 481, ptep 89B6B740, Noah_Davids.CAC
UDP SO_REUSEADDR action [safe/unsafe] (udp_reuseaddr_action) safe
ready 17:11:16
|
| Figure 1 – display of the two reuseaddr action parameters |
analyze_system -request_line 'set_stcp_param tcp_reuseaddr_action unsafe' -quit
OpenVOS Release 17.1.0ab, analyze_system Release 17.1.0ab
Current process is 481, ptep 89B6B740, Noah_Davids.CAC
Changing TCP SO_REUSEADDR action (tcp_reuseaddr_action)
from safe to unsafe
ready 07:30:38
|
| Figure 2 command to change tcp_reuseaddr_action to unsafe |