Resumo

  • A flag SO da RFC 916 afirmava que a carga tinha exatamente um octeto; o campo LENGTH deixava de repetir esse tamanho, carregava o caractere e era coberto pela soma de verificação do cabeçalho.
  • A mesma posição anunciava o Maximum Data Length em SYN, contava dados em um pacote comum ou era o próprio dado em um pacote SO. A interpretação dependia de flags verificadas e do estado aceito da conexão.
  • Números de sequência e reconhecimento de um bit bastavam porque cada sentido admitia no máximo um pacote aguardando resposta. A redução do estado também limitava o aproveitamento do enlace.

Publicada em outubro de 1984, a RFC 916 propôs o Reliable Asynchronous Transfer Protocol, ou RATP. Seu ambiente esperado era um enlace ponto a ponto, full-duplex e normalmente RS-232 assíncrono, ligando computadores pessoais, modems ou pequenos equipamentos que recebiam comandos. O registro atual do RFC Editor classifica o documento como Historic. Isso informa sua situação documental hoje, não quantifica sua adoção no passado.

A ordem de prioridades era explícita: confiabilidade primeiro, facilidade de implementação depois. O protocolo dispensou janelas dinâmicas e vários pacotes simultaneamente pendentes. Se o outro lado fechasse a conexão, dados ainda na fila de envio eram descartados; segundo o texto, essa escolha eliminava dois estados. RATP não tentava recriar toda a superfície do TCP. Preferia um contrato menor para máquinas menores.

De sete para quatro: o que realmente foi removido

O cabeçalho normal tinha quatro octetos: líder de sincronização hexadecimal 01, controle, comprimento de dados e soma de verificação do cabeçalho. Dados comuns vinham depois e terminavam com uma soma própria de dezesseis bits.

Uma sessão interativa tornava o custo visível. Esperar várias teclas reduziria a proporção de cabeçalho, mas aumentaria a latência percebida. Enviar um caractere imediatamente na forma comum custava sete octetos: quatro de cabeçalho, um de dado e dois de verificação dos dados.

A flag SO, Single Octet, tratava apenas esse caso. Com SO ativa e SYN, RST e FIN inativas, o receptor já sabia que o comprimento era um. Repetir o número no campo LENGTH não acrescentaria informação. A RFC colocou ali o próprio caractere, retirou a parte separada de dados e deixou a soma do cabeçalho cobrir o octeto incorporado. O documento descreveu a passagem de sete para quatro como melhora de 40% na eficiência de transmissão.

Não houve compressão de conteúdo. Três octetos saíram porque suas funções haviam sido substituídas por invariantes: a flag fornecia o tamanho, a posição fixa fornecia o dado e a soma do cabeçalho detectava corrupção dentro dos limites do algoritmo. Dois caracteres não cabiam nessa regra. SO tampouco eliminava estado de conexão ou reconhecimento.

O terceiro octeto precisava de autorização para significar

Durante a abertura, um pacote SYN usava a mesma posição para o Maximum Data Length, MDL. Quem enviava o SYN declarava a maior quantidade de dados que aceitava receber em um único pacote. No handshake de três etapas, cada lado comunicava sua própria capacidade.

Depois da abertura, sem SYN, RST ou FIN, a posição passava a se chamar LENGTH. Sem SO, contava os octetos seguintes, de zero até o MDL anunciado pelo par. Com SO, deixava de ser contagem e virava o único dado.

O valor isolado não resolvia a ambiguidade. O receptor precisava localizar a sincronização, validar controle, posição e soma de cabeçalho, verificar se as flags eram legais no estado atual e só então interpretar capacidade, contagem ou conteúdo. Uma captura que guarda os quatro octetos, mas perde a época da conexão, pode conservar o objeto físico e perder sua gramática.

O MDL também tinha força operacional. Se um cabeçalho válido declarasse comprimento comum maior que o limite local, a RFC tratava o evento como violação de protocolo ou improvável erro de comprimento que escapou à verificação. O receptor reiniciava a conexão. Não era uma dica de desempenho; era uma fronteira de admissão definida por quem sustentaria o custo.

Um lado podia anunciar MDL zero se não quisesse receber dados, permitindo uso unidirecional. Ambos não podiam escolher zero se algo precisasse circular. A regra comum definia representação e consequência. A capacidade concreta permanecia decisão local.

Um bit era suficiente porque não havia um segundo pacote em dúvida

Os campos SN e AN tinham um bit cada. Isso não significava que duas sequências fossem suficientes para qualquer transporte confiável. RATP mantinha no máximo um pacote sendo enviado ou reconhecido em cada direção.

O receptor esperava o próximo SN em aritmética módulo dois. Um valor incompatível identificava a repetição de um pacote já aceito, possivelmente reenviado porque o reconhecimento anterior se perdeu. Os dados duplicados eram descartados e a resposta útil podia ser repetida. O emissor usava AN para retirar seu único item da fila de retransmissão e alternar o bit.

Os dois sentidos continuavam independentes. Um lado com seu último pacote reconhecido podia transmitir sem esperar dados do outro. Quando precisava reconhecer o pacote recebido e tinha dados próprios, reunia as duas funções. Um reconhecimento puro não exigia outro reconhecimento, impedindo uma cadeia infinita de recibos.

O preço aparecia no uso do caminho. Sem janela, o emissor não mantinha vários pacotes durante um tempo de ida e volta. Num enlace lento, interativo e com pouca memória, a restrição simplificava buffers, estados e duplicatas. Em um enlace com produto banda-latência maior, limitaria a vazão. O bit curto só era seguro dentro dessa escolha.

O receptor dizia quanto pacote conseguia sustentar

O MDL tinha máximo 255. Assim, o maior pacote comum ocupava 261 octetos: sincronização, restante do cabeçalho, soma dos dados e até 255 octetos de carga. A especificação transformava esse teto em uma certeza de alocação: uma recepção individual nunca precisava de mais espaço.

O máximo efetivo podia ser menor. Sistema operacional, driver, memória, velocidade e caracteres de controle inseridos pelo caminho influenciavam a decisão. A RFC recomendava reduzir a quantidade quando rajadas longas provavelmente acionariam controle de fluxo externo, para aumentar a chance de alguns pacotes atravessarem sem interferência.

Essa divisão combina bem com uma camada comum mínima. O protocolo especifica de forma determinística como declarar e impor o limite. O operador escolhe o valor conforme a máquina que executa o código. Nenhum organismo precisa autorizar a memória de um endpoint; o par apenas valida a mensagem que recebeu.

O fim do pacote não encerrava necessariamente o registro

RATP tinha um padrão de início, mas não um delimitador final equivalente. Qualquer padrão podia aparecer na carga. Depois de aceitar o cabeçalho, o receptor calculava o final a partir do comprimento interpretado.

Uma unidade superior podia exceder o MDL e ser fragmentada. A flag EOR indicava que o registro superior terminava naquele pacote. A camada superior era responsável por ativá-la. Portanto, um pacote recebido, verificado e reconhecido podia ser apenas uma parte de um objeto ainda incompleto.

As provas permanecem separadas. A soma do cabeçalho sustenta uma conclusão limitada sobre aqueles octetos. O reconhecimento mostra aceitação pelo estado RATP. EOR ajuda a montar o registro. Nenhum desses sinais autentica a pessoa, autoriza o comando, cifra o caractere ou prova que a aplicação realizou o efeito solicitado.

Ressincronizar depois do ruído era outro mecanismo

RS-232 enquadrava octetos individuais, não pacotes RATP. O receptor procurava 01, lia os três octetos seguintes e testava sua soma. Se o teste falhasse, esses três octetos voltavam a ser entrada da busca. Um falso início não autorizava descartar uma quantidade desconhecida do fluxo.

A RFC 1055 registrou depois a escolha diferente do SLIP: delimitadores e escapes para datagramas IP, mas nenhum campo de tipo, máximo definido pela convenção básica ou correção de erro no enlace. As RFC 1661 e RFC 1662 descreveram posteriormente o PPP, com multiplexação de protocolos, LCP, limites negociáveis, flags de enquadramento, transparência e FCS. São contrastes primários, não prova de descendência direta.

A RFC 793 era a comparação contemporânea citada pela própria RFC 916 ao excluir a janela dinâmica. TCP tratava um fluxo confiável entre redes com contrato muito mais amplo. RATP integrava pacote e conexão confiável numa única ligação ponto a ponto. Vocabulário semelhante não torna suas garantias intercambiáveis.

Essas fontes não mostram quantas implementações existiram nem sustentam afirmações sobre produtos atuais. O valor histórico está no contorno verificável: quatro octetos bastavam somente porque estado, limite do receptor e único pacote pendente eram fatos comuns, não suposições ocultas.