Resumo

  • Os dois pares PPP precisavam manter o mesmo histórico deslizante de 8192 bytes; uma contagem de coerência de 12 bits em cada pacote expunha perda ou ordem inesperada.
  • Se a contagem divergisse, o receptor descartava o pacote e enviava Reset-Request. O transmissor limpava o histórico e marcava FLUSHED no pacote seguinte; esse pacote redefinia o receptor e sua contagem, sem Reset-Ack.
  • A evidência é estreita: ela abre um novo histórico de compressão, mas não recupera dados perdidos nem prova entrega confiável, integridade, identidade, autorização ou resultado de aplicação.

A resposta foi incorporada ao tráfego

No procedimento geral da RFC 1962, o descompressor envia Reset-Request, descarta pacotes comprimidos posteriores e aguarda um Reset-Ack com o identificador esperado. A resposta de controle determina o retorno ao estado inicial.

O perfil MPPC da RFC 2118 usa outro recibo. Ao ver uma contagem diferente da esperada, o receptor descarta o pacote e solicita reset. O compressor, quando recebe a solicitação, apaga o histórico e coloca FLUSHED no próximo pacote MPPC. Ao receber esse pacote, o descompressor também limpa a memória e adota a contagem nele transportada. A sincronização volta sem Reset-Ack.

O próximo pacote, por não depender do histórico antigo, é a evidência operacional do novo período. Mas ele não corrige o passado: o pacote ausente continua ausente, a chegada da solicitação não ganha um recibo próprio e a entrega à aplicação permanece sem prova.

A opção 18 negociava uma transformação específica

MPPC não era uma característica automática de PPP. A opção CCP de Tipo 18 e comprimento 6 tinha um único bit para solicitar o algoritmo; sem acordo final, não havia compressão. O registro PPP da IANA ainda associa a opção 18 a Microsoft PPC.

Os datagramas MPPC só podiam circular após PPP chegar à fase Network-Layer Protocol e CCP ao estado Opened. O Protocol 0x00FD identificava os datagramas comprimidos, enquanto o protocolo de controle CCP usava 0x80FD. O primeiro número classifica o caminho de dados, mas é a negociação que identifica o algoritmo.

A faixa processada ia de 0x0021 a 0x00FA; outros protocolos preservavam seu número original e não passavam pelo compressor. Logo, aceitar a opção provava capacidade negociada, não compressão universal.

Uma janela de 8192 bytes ligava presente e passado

O algoritmo LZ mantinha histórico contínuo. Depois de 8192 bytes comprimidos, podia consultar uma janela completa de 8192 bytes, exceto após um flush. Essa memória economizava banda porque dados posteriores reutilizavam padrões anteriores; uma perda, porém, fazia os pares atribuírem significados diferentes às mesmas referências.

O bit A, FLUSHED, dizia que o transmissor inicializou o histórico antes de gerar o pacote. O bit B reposicionava o ponteiro no início do buffer e precisava aparecer pelo menos uma vez a cada 8192 bytes comprimidos. O bit C indicava se os dados atuais estavam comprimidos. Nenhum deles informava entrega de serviço.

Quando comprimir causava expansão, os bytes originais seguiam em um pacote MPPC não comprimido. Antes de voltar a comprimir, o transmissor limpava o histórico e marcava FLUSHED no próximo pacote. Evitar o aumento atual cobrava o preço de perder o contexto acumulado.

Doze bits detectavam um salto, não validavam o conteúdo

A contagem começava em zero, avançava a cada pacote MPPC e retornava a zero depois de 4095. A diferença para o valor esperado revelava perda ou reordenação. Por isso MPPC não exigia enlace confiável, embora a RFC 1663 oferecesse um modo PPP confiável.

O mesmo texto exigia entrega em sequência para que a ressincronização funcionasse. Não exigir enlace confiável não tornava a ordem irrelevante. Uma contagem correta também não era verificação de conteúdo. A seção de segurança apenas declara que a RFC 2118 não discute questões de segurança; ela não oferece confidencialidade, integridade criptográfica, identidade, autorização ou proteção contra repetição.

Um mecanismo Informational com licença histórica

Publicada em março de 1997, a RFC 2118 era Informational, não um Internet Standard. Sua seção de licenciamento restringia MPPC a produtos PPP voltados à interoperabilidade MPPC/PPP e indicava licenças da Stac Electronics. Isso documenta o contexto histórico, não a situação atual de licenças, patentes ou implantação.

A disciplina de interpretação vem de Running-Code Primacy e Minimum Initial Specification: cada sinal deve sustentar somente sua afirmação verificável. A opção registra capacidade; a contagem detecta diferença; Reset-Request pede reparo; FLUSHED abre novo histórico. Nenhum desses fatos autoriza conclusões de segurança ou de aplicação.

Fontes e limite da evidência

O registro primário inclui o HTML da RFC 2118, sua edição em texto, a ficha do RFC Editor e o serviço de erratas, junto com RFC 1962, RFC 1661, RFC 1663 e o registro da IANA. Os ensaios de Heng Lu orientam a leitura, não substituem fontes do protocolo. O conjunto estabelece comportamento especificado e status documental, não uso atual, desempenho, segurança ou resultado de um pacote real.