Pular para o conteúdo principal

Sob STCP quando você tem vários processos escutando no mesmo número de porta, apenas o primeiro processo que se liga ao número da porta é notificado quando uma conexão é solicitada. Uma maneira comum de escapar desta restrição é fechar o soquete de escuta quando uma conexão é completada e depois criar um novo soquete e ligá-lo e escutá-lo novamente. Isto coloca o soquete de escuta no final da cadeia de soquetes de escuta.

A partir de 17.1, este procedimento não funcionará mais sem alterar os valores padrão dos parâmetros STCP.

Antes do 17.1, a STCP interpretou mal a intenção da opção SO_REUSEADDR do soquete. A intenção desta opção era permitir que um processo que ouvia na porta X fosse reiniciado imediatamente se fosse terminado e o sistema ainda tivesse soquetes ligados à porta X em um estado TIME_WAIT. Entretanto, as versões anteriores do STCP permitiriam que um processo ouvisse na porta X independentemente do estado dos soquetes existentes vinculados à porta X, assumindo, é claro, que a opção de soquete SO_REUSEADDR estivesse definida. Este comportamento permite que duas aplicações diferentes ouçam o mesmo número de porta. Se a primeira aplicação usar o procedimento de reciclagem da porta de escuta ou se o processo for encerrado e reiniciado, a segunda aplicação irá efetivamente seqüestrar a porta.

A partir do release 17.1 a função bind retornará o erro EADDRINUSE a menos que todos os soquetes ligados na porta solicitada estejam no estado TIME_WAIT; ou o segundo processo tenha o mesmo ID de sessão que o primeiro processo. Todos os processos iniciados a partir do mesmo processo pai terão o mesmo ID de sessão, de modo que um processo pode bifurcar múltiplos processos filhos e todas essas crianças podem ouvir na porta X.

Dois parâmetros STCP onde adicionados no release 17.1 que podem ser usados para mudar o comportamento do STCP de volta ao comportamento pré 17.1, são tcp_reuseaddr_action e udp_reuseaddr_action. Cada parâmetro tem os valores "seguro" (padrão) e "inseguro". O termo "inseguro" é usado porque a configuração permitirá o seqüestro de portas descrito acima.

Você pode usar a lista de solicitação do sistema de análise_stcp_params para mostrar a configuração atual destes dois parâmetros (figura 1) e a solicitação set_stcp_param para alterar a configuração (figura 2). Como todos os parâmetros STCP, as mudanças só são efetivas até que o sistema seja reinicializado, assim, para que a mudança seja permanente, um comando definindo o parâmetro como inseguro deve ser colocado no arquivo module_start.cm ou no arquivo start_stcp.cm.

analyze_system -request_line 'list_stcp_params tcp_reuseaddr_action' -quit
OpenVOS Release 17.1.0ab, analyse_system Release 17.1.0ab
O processo atual é 481, passo 89B6B740, Noah_Davids.CAC

TCP SO_REUSEADDR ação [safe/unsafe] (tcp_reuseaddr_action) safe

pronto 17:10:29

analyze_system -request_line 'list_stcp_params udp_reuseaddr_action' -quit
OpenVOS Release 17.1.0ab, analyse_system Release 17.1.0ab
O processo atual é 481, passo 89B6B740, Noah_Davids.CAC

UDP SO_REUSEADDR ação [safe/unsafe] (udp_reuseaddr_action) safe

pronto 17:11:16
Figura 1 - exibição dos dois parâmetros de ação de reuso

 

 

analyze_system -request_line 'set_stcp_param tcp_reuseaddr_action unsafe' -quit
OpenVOS Release 17.1.0ab, analyse_system Release 17.1.0ab
O processo atual é 481, passo 89B6B740, Noah_Davids.CAC

Mudança da ação TCP SO_REUSEADDR (ação tcp_reuseaddr_action)
de seguro para inseguro
pronto 07:30:38
Figura 2 comando para mudar o tcp_reuseaddr_action para inseguro

 

© 2024 Stratus Technologies.