En el marco del STCP, cuando se tienen varios procesos escuchando en el mismo número de puerto, sólo se notifica al primer proceso vinculado al número de puerto cuando se solicita una conexión. Una forma común de sortear esta restricción es cerrar el zócalo de escucha cuando se completa una conexión y luego crear un nuevo zócalo y enlazar y escuchar de nuevo. Esto coloca el zócalo de escucha al final de la cadena de zócalos de escucha.
A partir de la 17.1 este procedimiento ya no funcionará sin cambiar los valores de los parámetros STCP por defecto.
Antes del 17.1, STCP malinterpretó la intención de la opción de socorro SO_REUSEADDR. La intención de esta opción era permitir que un proceso que escuchaba en el puerto X se reiniciara inmediatamente si se terminaba y el sistema todavía tenía sockets vinculados al puerto X en un estado TIME_WAIT. Sin embargo, las versiones anteriores de STCP permitirían a un proceso escuchar en el puerto X independientemente del estado de los sockets existentes enlazados al puerto X, asumiendo, por supuesto, que la opción de socket SO_REUSEADDR estuviera establecida. Este comportamiento permite que dos aplicaciones diferentes escuchen el mismo número de puerto. Si la primera aplicación usa el procedimiento de reciclaje de puertos de escucha o el proceso se termina y se reinicia, la segunda aplicación efectivamente secuestrará el puerto.
A partir de la versión 17.1 la función bind devolverá el error EADDRINUSE a menos que todos los sockets vinculados al puerto solicitado estén en estado TIME_WAIT; o que el segundo proceso tenga el mismo ID de sesión que el primero. Todos los procesos iniciados desde el mismo proceso padre tendrán el mismo ID de sesión, por lo que un proceso puede bifurcar varios procesos hijos y todos esos hijos pueden escuchar en el puerto X.
Dos parámetros de STCP fueron agregados en la versión 17.1 que pueden ser usados para cambiar el comportamiento de STCP de vuelta al comportamiento anterior a la 17.1, estos son tcp_reuseaddr_action y udp_reuseaddr_action. Cada parámetro tiene los valores "seguro" (por defecto) e "inseguro". El término "inseguro" se utiliza porque el parámetro permitirá el secuestro del puerto descrito anteriormente.
Se puede utilizar la lista de solicitudes analyze_system list_stcp_params para mostrar la configuración actual de estos dos parámetros (figura 1) y el set de solicitudes set_stcp_param para cambiar la configuración (figura 2). Como todos los parámetros STCP, los cambios sólo son efectivos hasta que se reinicia el sistema, de modo que para que el cambio sea permanente, un comando que establezca el parámetro como inseguro debe colocarse en el archivo module_start.cm o en el archivo start_stcp.cm.
analyze_system -request_line 'list_stcp_params tcp_reuseaddr_action' -quit
OpenVOS Release 17.1.0ab, analyze_system Release 17.1.0ab
El proceso actual es 481, paso 89B6B740, Noah_Davids.CAC
TCP SO_REUSEADDR action [safe/unsafe] (tcp_reuseaddr_action) safe
listo 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
El proceso actual es 481, paso 89B6B740, Noah_Davids.CAC
UDP SO_REUSEADDR action [safe/unsafe] (udp_reuseaddr_action) safe
listo 17:11:16
|
| Figura 1 - visualización de los dos parámetros de acción de reusaraddr |
analyze_system -request_line 'set_stcp_param tcp_reuseaddr_action unsafe' -quit
OpenVOS Release 17.1.0ab, analyze_system Release 17.1.0ab
El proceso actual es 481, paso 89B6B740, Noah_Davids.CAC
Cambiando la acción de TCP SO_REUSEADDR (tcp_reuseaddr_action)
de seguro a inseguro
listo 07:30:38
|
| Figura 2 comando para cambiar tcp_reuseaddr_action a inseguro |