Resumo

  • Um quadro comprimido podia conter vários pacotes PPP originais; um pacote podia atravessar vários quadros.
  • Mesmo quando a compressão aumentava os dados, a saída era transmitida para manter iguais as histórias dos dois lados.
  • Descompressão bem-sucedida não comprova entrega integral, identidade do par, segurança nem resultado da aplicação.

O recipiente e o conteúdo ganharam ritmos próprios

Os dados comprimidos definidos pelo RFC 1993 carregam um ou mais pacotes PPP encapsulados. Quando a representação de um pacote fica maior que a MRU do par, ela continua no próximo quadro. É uma indicação dentro do fluxo que assinala o fim do pacote original, não o encerramento físico do quadro.

Isso separa três eventos. O enlace fecha um quadro; o descompressor encontra o fim de um pacote; a história de compressão segue adiante. Nenhum deles precisa coincidir. Encerrar um recipiente não conclui necessariamente o objeto lógico, e concluir um pacote não reinicia o estado compartilhado.

No protocolo PPP externo, 0x00FD identifica Compressed Datagram e 0x00FB, Link Compressed Datagram. O segundo posiciona a compressão fora do PPP Multilink para que cada enlace físico mantenha contexto próprio. O registro da IANA confirma as atribuições, não um uso concreto, uma versão, a identidade do par ou a integridade da história.

Enviar mais para não perder o futuro

O FZA podia produzir expansão máxima de dois para um. Para dados já comprimidos, o RFC registra expansão típica de cerca de 1,01 para um. Ainda assim, o emissor transmitia o resultado expandido.

O motivo é a história. Emissor e receptor precisam alimentar o mesmo estado com a mesma sequência. Se o emissor pulasse uma saída pouco econômica, seu histórico avançaria sozinho; referências posteriores apontariam para conteúdos diferentes em cada ponta. O custo imediato em bytes preservava a compreensão futura do fluxo.

Se a saída expandida ultrapassasse a MRU, ela ocuparia vários quadros. O tamanho do recipiente não autorizava a exclusão de uma parte do estado. A indicação interna de fim mantinha reconhecível o pacote original enquanto a história seguia contínua.

Uma cauda autoexplicativa

O receptor também precisava separar padding de dados comprimidos no final do quadro. Por isso, o RFC 1993 exige a negociação de Self-Describing-Padding, do RFC 1570, durante o estabelecimento LCP. Os octetos de preenchimento carregam a própria posição; três deles aparecem como 1, 2, 3, e o último informa quantos remover. Se o último octeto real puder parecer uma extensão de padding, o emissor acrescenta preenchimento para tirar a dúvida.

Esse mecanismo resolve uma ambiguidade local. Uma sequência correta não autentica o emissor, não impede alteração maliciosa e não garante a entrega acima. Um índice incorreto pode levar ao descarte silencioso do quadro; o índice correto é apenas evidência de sintaxe.

A confiabilidade não nasce no decodificador

O RFC 1993 espera entrega confiável e em sequência. É uma condição consumida pelo FZA, não uma propriedade que ele produz. O RFC 1663 explica por que a perda danifica um dicionário contínuo e descreve um modo confiável de PPP negociado separadamente. Ele esclarece a dependência, mas sua mecânica não pertence ao FZA.

Cada recibo precisa parar no seu nível. O valor externo mostra a classe de encapsulamento. O padding válido mostra uma cauda removível. A descompressão mostra que o decodificador processou os bytes recebidos. Evidência do enlace ainda deve comprovar que todos os quadros necessários chegaram na ordem; a camada PPP deve comprovar a entrega do pacote reconstruído. Identidade, autorização, confidencialidade, proteção contra repetição e conclusão de uma ação exigem provas próprias.

O RFC 1993 não discute segurança. A busca atual sem erratas tampouco demonstra ausência de defeitos, interoperabilidade ou adoção corrente. Seu status é Informational. A contribuição histórica é revelar como uma transformação com estado desloca a fronteira de observação: o contorno visível do transporte não define sozinho o que foi reconstruído.

O método publicado por Heng Lu ajuda a aplicar essa contenção: dar prioridade ao comportamento em execução e restringir a autoridade de cada recibo ao que ele observou. O fim do quadro não fala pelo pacote; o decodificador não fala pelo enlace; o pacote reconstruído não fala pela aplicação.

Fontes

Os fatos do protocolo vêm dos RFCs e do registro. Os três textos de Heng Lu expõem o método analítico, não a mecânica FZA.