Antes do VOS 17.1 STCP não aceitaria um pedido de conexão TCP a menos que a aplicação do servidor tivesse chamado a função de aceitação. As solicitações de conexão foram colocadas em uma fila de backlog, mas nenhuma resposta foi enviada até que uma chamada de aceitação removesse a solicitação da fila de backlog. Uma vez que a fila de backlog preenchida, o STCP enviaria um reset em resposta a uma solicitação de conexão.
A partir do release 17.1, a dinâmica das conexões TCP mudou. Agora, quando um pedido de conexão chega, assumindo que a fila de atraso não foi preenchida, a pilha STCP enviará imediatamente uma resposta aceitando a conexão. A conexão é então colocada na fila de backlog. Uma vez que a fila de atraso preencha os pedidos de conexão subseqüentes, não é enviada uma resposta. Quando as chamadas da aplicação do servidor aceitam a conexão na frente da fila de backlog, a conexão é removida. Este comportamento é agora semelhante ao comportamento da pilha TCP na maioria dos outros sistemas operacionais.
Em circunstâncias normais, esta mudança na dinâmica não levará a nenhuma mudança perceptível na maneira como as aplicações do servidor ou do cliente se comportam. No entanto, se a aplicação do servidor diminuir a velocidade ou se as conexões entrarem mais rápido do que o esperado, as conexões podem permanecer na fila de log de retorno por um tempo prolongado. Sob estas circunstâncias, alguns comportamentos interessantes podem ser notados.
A tabela a seguir apresenta um resumo do que acontece quando um pedido de conexão é colocado na fila de atraso, com base nas ações do cliente. O cliente não pode fazer nada, esperando que a aplicação servidor envie dados, possa enviar dados e/ou possa fechar a conexão com uma bandeira FIN (final) (fechamento normal) ou RST (reset) (fechamento anormal). As 4 primeiras colunas se comportam como se espera. As chamadas da aplicação do servidor aceitam receber um socket da fila de backlog e, em seguida, chamam a recv e ou ficam penduradas se não houver dados ou recebem dados e/ou uma indicação de fim de arquivo, dependendo do que está no socket. São as últimas 4 colunas que precisam ser examinadas mais de perto.
| Nada na tomada | Dados no soquete | FIN na tomada | Dados no soquete/
FIN na tomada |
Dados no soquete/
FIN na tomada/ Tomada do cliente desapareceu |
FIN na tomada/
Tomada do cliente desapareceu |
Dados no soquete/
Reposição enviada |
Redefinir Enviar | ||
| Aceitar | Soquete de retorno | Soquete de retorno | Soquete de retorno | Soquete de retorno | Soquete de retorno | Soquete de retorno | Hangs | Hangs | |
| Primeira recv | Hangs | Dados de retorno | Devolve o EOF | Dados de retorno | Retorna erro de reset | Devolve o EOF | |||
| Segunda Recv | Hangs | Devolve o EOF |
Dados no soquete / FIN no soquete / soquete do cliente desapareceu
Neste cenário, o cliente enviou alguns dados e desligou a conexão. A liberação 17.1 do STCP reconhecerá todos os dados que foram enviados, mas não reconhecerá o FIN até que os dados na fila de recebimento tenham sido entregues ao pedido. Como resultado, o FIN do cliente será retransmitido até que o timer de retransmissão do cliente expire. Uma aplicação bem escrita do cliente aguardará que a aplicação do servidor feche seu lado da conexão, de modo que quando o FIN expirar, o cliente será notificado de um erro. Entretanto, se a aplicação cliente simplesmente fechar a tomada sem esperar por uma indicação do servidor, não saberá que os dados que enviou podem ter sido perdidos.
Quando a aplicação do servidor chama aceita um pacote de reconhecimento duplicado, reconhecendo os dados mas não o FIN é enviado. Uma vez que o cliente derrubou seu soquete, ele responde com um reset. O reset limpa o soquete no lado do servidor. A aplicação do servidor receberá um erro de reset tanto na primeira como na segunda chamada a ser atendida, dependendo do tempo entre a chamada para aceitar e a chamada para a primeira chamada a ser atendida. Se esse tempo for mais rápido do que o tempo necessário para obter e processar o pacote de reset do cliente, a aplicação do servidor verá os dados. Em ambos os casos, a aplicação do servidor saberá que foi feita uma conexão e que ela foi abortada.
FIN no soquete / soquete do cliente desapareceu
Isto difere do cenário anterior na medida em que não há dados na tomada. Quando não há dados, o FIN é reconhecido. O aceite retorna o soquete e o recv retorna um EOF indicando que recebeu o FIN. Qualquer tentativa de escrever no soquete, incluindo o fechamento do mesmo, resultará em um reset sendo devolvido porque o cliente não tem mais o soquete correspondente.
Dados no soquete / Reset enviado
Aqui o cliente envia alguns dados e depois envia um reset. Pode haver muitas razões para o reset; uma comum é a aplicação desligar o soquete e a pilha TCP, enviando um reset imediatamente ou enviando um reset após não ter recebido um reconhecimento para o pacote FIN. Isto é similar ao primeiro cenário, mas a pilha TCP do cliente envia um reset antes de derrubar seu soquete em vez de apenas derrubar o soquete. Novamente, uma aplicação bem escrita do cliente verá isto como um erro; uma aplicação não tão bem escrita não verá um erro.
A tomada do servidor é derrubada e todos os dados descartados quando o reset é recebido para que a aplicação do servidor não veja sequer uma indicação de que alguma vez foi estabelecida uma conexão; ela apenas fica pendurada esperando por outra conexão.
Reposição enviada
Novamente o reset remove efetivamente o soquete da fila de backlog para que o aceite não o veja e aguarde por outro pedido de conexão.
Então, o que tudo isso realmente significa? Primeiro, as aplicações dos clientes podem agora obter uma resposta de conexão mais rápida, mas podem ter que esperar mais tempo por qualquer tipo de banner ou mensagem de nível de aplicação. Qualquer intervalo de tempo para este banner/mensagem pode precisar ser ajustado para cima. Segundo, as aplicações do servidor têm que estar preparadas para lidar com um erro da chamada de retorno imediatamente após fazer uma aceitação. Isto sempre foi uma possibilidade, mas agora a probabilidade é maior. Finalmente, as aplicações clientes que enviam dados para o servidor e não esperam qualquer tipo de mensagem de retorno devem ser escritas para confirmar que a aplicação do servidor desligou corretamente a conexão ou correm o risco de perder dados inconscientemente. Mais uma vez, esta possibilidade sempre existiu e não é exclusiva do STCP, mas a probabilidade agora é ligeiramente maior.