Resumo

  • URG ativa um deslocamento dentro do espaço normal de sequência; não abre um segundo canal nem promete um evento para cada indicação.
  • Telnet combinou o alerta com DATA MARK no próprio fluxo, e FTP reutilizou a sequência para comandos como ABOR. O transporte chamava atenção; a aplicação guardava o significado.
  • A correção LAST de RFC 1122 não venceu no código difundido. RFC 6093 voltou a LAST+1 para interoperar, mas retirou o mecanismo do repertório recomendado a aplicações novas.

Uma fronteira que não furava a fila

RFC 793 faz o campo de urgência valer apenas com URG. Somado ao número de sequência, ele marca um ponto no mesmo fluxo. O receptor entra em modo urgente até consumir a região conhecida.

Atualizações podem não gerar novos avisos. Logo, não se contam comandos por notificações. Tampouco os bytes passam à frente da ordenação normal.

A marca que completava o sinal

RFC 854 definiu Telnet Synch como notificação urgente mais DATA MARK. O primeiro acordava o processo; o segundo, recebido em linha, encerrava a varredura especial. Vários Synch podiam se fundir.

RFC 959 recomendou Interrupt Process, Synch e então ABOR ou STAT para um servidor ocupado com transferência. A urgência não executava a ordem; abria espaço para que o intérprete a encontrasse.

O byte disputado

RFC 793 dizia no cabeçalho que o ponteiro alcançava o primeiro byte não urgente, mas no processamento de SEND usava SND.NXT-1. RFC 1011 chamou a primeira leitura de erro. RFC 1122 exigiu o último byte urgente e sequências de qualquer comprimento.

O papel convergiu; os sistemas já distribuídos, não.

A caixa lateral da API

RFC 6093 encontrou quase todas as implementações populares testadas usando o byte seguinte. Muitas retiravam o último byte urgente da leitura comum e o entregavam por MSG_OOB, criando aparência de fora de banda.

Uma nova indicação podia sobrescrever a caixa de um byte. SO_OOBINLINE devolvia a entrega ao fluxo local, sem alinhar todos os pares e equipamentos.

Quando o caminho apagava URG

Alguns middleboxes limpavam a flag e zeravam o ponteiro. Os dados seguiam, o despertar sumia. Aplicação e sistema de inspeção podiam reconstruir limites diferentes.

RFC 6093 adotou a convenção implementada, manteve suporte para legado e disse que aplicações novas não deveriam usar o recurso. As antigas deveriam pedir dados em linha e sobreviver à remoção de URG. RFC 9293 preserva esse acordo: suporte obrigatório, nova dependência desaconselhada.

Fontes e limites

Os RFCs sustentam intenção, conflito, usos e prática observada. Não provam uniformidade de todos os sistemas ou middleboxes. Urgência não autentica comando, não cria prioridade de rede e não desvia da ordem TCP.

O campo continuou compatível; deixou de ter autoridade para definir uma aplicação nova.