Resumo

  • A reconstrução de falhas distantes cabia principalmente aos gateways. O host tinha de resolver a exceção silenciosa: o gateway imediato que, depois de morrer, não conseguia mais devolver um aviso.
  • Uma mensagem ICMP isolada durante a convergência era uma observação com prazo, não motivo suficiente para encerrar TCP. Retransmissão e timeout indicavam gravidade; o erro sugeria a causa.
  • ACK de TCP não era recibo de aplicação. Falhas antigas de SMTP e sessões Telnet ociosas mostraram por que conclusão, prazo e presença precisavam continuar no nível da aplicação.

Um timeout não trazia o diagnóstico embutido

Na camada TCP, a RFC 816 via um mecanismo simples: retransmitir um segmento até receber confirmação ou até o limite da conexão expirar. A repetição podia avisar a IP que o caminho merecia investigação. No sentido oposto, IP podia entregar mensagens ICMP e erros da rede conectada.

Esses sinais não eram equivalentes. Retransmissão dizia que o progresso esperado não ocorreu. O timeout do usuário estabelecia até quando o cliente aceitava esperar. A mensagem de rede oferecia uma hipótese sobre a causa. Somente a camada que conhecia o objetivo da conexão podia combinar as três informações e decidir.

Clark diferenciou um programa remetente de e-mail de uma pessoa usando Telnet. O programa precisava de uma regra previsível para desistir. A pessoa talvez quisesse interromper imediatamente ou esperar uma recuperação, conforme os detalhes. Por isso o texto defendia que timeout e erros inferiores subissem de forma assíncrona e útil, em vez de desaparecerem numa decisão interna do transporte.

Essa separação permanece visível na RFC 9293. O timeout de retransmissão reenvia o primeiro segmento da fila. O timeout do usuário limpa as filas, informa o aborto, apaga o estado da conexão e fecha. A mesma palavra descreve duas fronteiras de decisão diferentes.

A falha silenciosa ficava junto do host

Os gateways da RFC 816 trocavam suas opiniões mais recentes sobre redes e vizinhos. Depois de uma queda, podiam passar por um período de confusão e então reconstruir uma topologia coerente. Se a falha estivesse longe, os gateways próximos dela deveriam contorná-la sem expor toda a complexidade ao host.

O primeiro salto escapava a esse arranjo. Quando o host continuava enviando a um gateway imediato que havia parado, o equipamento morto não devolvia Redirect nem Destination Unreachable. Os demais gateways podiam já conhecer o caminho correto; os pacotes simplesmente não chegavam a eles.

A obrigação do host foi, então, limitada: detectar a morte do gateway ao qual entregava datagramas e tentar outro vizinho conhecido. Não precisava assumir o mapa da Internet. Precisava corrigir a escolha local que nenhum participante distante conseguia denunciar através do componente morto.

O alcance da conclusão também era local. A ausência do primeiro salto justificava mudar o próximo salto, não declarar que o destino, o serviço ou a operação tinham fracassado.

Um erro podia envelhecer durante a própria entrega

Redirect informava uma rota imediata melhor. Destination Unreachable expressava que o emissor não conhecia, naquele momento, um caminho utilizável. A RFC 816 chamava ambos de mensagens de aconselhamento.

Durante a convergência, diferentes gateways mantinham estados diferentes. Um pacote podia encontrar uma visão antiga, provocar um Unreachable isolado e, logo depois, a Internet recuperar o caminho. Encerrar uma conexão estabelecida por essa mensagem única eliminaria a vantagem de reconstruir a rede sem perturbar as pontas.

O aviso não deveria ser descartado. Na abertura de uma conexão, podia revelar endereço inexistente. Depois de um timeout, podia tornar a explicação mais precisa. Parameter Problem podia apontar defeito de implementação. Tipo, código, emissor, instante, estado da conexão e sinais concordantes determinavam seu peso.

O erro continuava sendo evidência. Só não ganhava autoridade automática para decidir o resultado em todas as camadas superiores.

Trocar antes de ter certeza podia ser seguro

A RFC 816 analisou a notificação fornecida pela rede, a sondagem contínua, a sondagem acionada e a reseleção acionada. Pingar gateways o tempo todo funcionava, mas a frequência necessária poderia impor carga insuportável ao host, à rede e ao gateway. O método era proibido sem uma análise específica do custo.

Na sondagem acionada, várias retransmissões em TCP serviam de indício para IP começar a testar. O custo ficava restrito aos momentos suspeitos, embora a confirmação pudesse chegar tarde.

Na reseleção acionada, IP tentava logo o próximo gateway da lista. Se o original estivesse morto, a recuperação começava antes. Se a suspeita estivesse errada, o alternativo ainda poderia encaminhar o pacote e devolver um Redirect para o caminho melhor. A decisão incorreta carregava a própria rota de correção.

Era uma experiência limitada, não um failover cego. A incerteza autorizava uma mudança reversível no ponto observado, sem criar uma nova verdade permanente.

Mais tarde, a RFC 1122 exigiu que IP detectasse a falha de um próximo salto do cache e escolhesse uma alternativa. Também admitiu que nenhum algoritmo completo era satisfatório, manteve a proibição do ping contínuo e preferiu conselhos positivos e negativos de TCP, ACK, enlace, ARP e ICMP.

O transporte podia confirmar tudo e ainda faltar o resultado

O exemplo do SMTP mostrava por que um ACK não encerrava a cadeia. Alguns receptores antigos travavam depois de receber todo o texto da mensagem e antes de devolver a confirmação SMTP. TCP já havia confirmado os dados. Sem bytes pendentes, não existia retransmissão capaz de revelar o problema. O remetente podia esperar para sempre por uma resposta que só a aplicação sabia produzir.

Adicionar um temporizador em SMTP era necessário, mas não havia um valor neutro. Um prazo curto classificava como falha uma mensagem grande que avançava normalmente para um host lento. Um prazo longo escondia a queda real. Alguns mailers relacionavam o tempo ao tamanho da mensagem. O ponto decisivo era a localização: SMTP conhecia a resposta final e o trabalho que a antecedia.

O ACK comprovava a chegada do espaço de sequência correspondente ao transporte remoto. Não comprovava que o processo continuava vivo, que gravara a mensagem ou que cumprira a obrigação prometida.

Uma conexão ociosa podia morrer sem atraso de pacote

No Telnet servidor, o caminho podia quebrar enquanto o usuário pensava. A próxima tecla revelaria o problema para a pessoa. O servidor, sem dados para enviar, não teria segmento pendente nem timeout e poderia conservar indefinidamente uma sessão inútil.

Uma consulta de presença da aplicação ajudaria, mas consultar todos os usuários ociosos em alta frequência repetiria a sobrecarga da sondagem contínua. A aplicação precisava considerar duração da ociosidade, custo do estado abandonado e probabilidade de uma pausa legítima.

SMTP mostrava transporte confirmado sem conclusão. Telnet mostrava falha de caminho sem atividade de transporte que pudesse falhar. Em ambos os casos, TCP respondia corretamente à sua pergunta; a aplicação ainda devia responder à sua.

Erros brandos preservavam tempo para reconstrução

A RFC 1122 determinou que certos Destination Unreachable brandos não encerrassem uma conexão TCP estabelecida e que a informação fosse disponibilizada à aplicação. A RFC 5461 explicou a troca: a espera permite sobreviver a falhas transitórias, mas uma primeira direção permanentemente inacessível pode atrasar a tentativa da seguinte. O documento registrou atalhos não padronizados para a abertura sem alterar a regra padrão.

A continuidade não vinha de acreditar que toda falha passaria. Vinha de não conceder a um sinal transitório poder irreversível antes de considerar o tempo, o estado e a finalidade da operação.

Assim, a RFC 816 reuniu verdades parciais: rota, silêncio local, retransmissão, limite de espera e recibo de aplicação. A mensagem de erro foi mais útil como conselho porque podia explicar e provocar ação sem confiscar a decisão final.

Fontes