Resumo

  • Quando a compressão aumentava o tamanho, a RFC 1977 preservava a encapsulação PPP nativa para não complicar a MTU, mas mantinha no dicionário o efeito da tentativa; o receptor repetia localmente a mesma operação.
  • Como o pacote nativo não levava um código LZW CLEAR, os dois pares precisavam alcançar de forma independente o mesmo ponto de limpeza adaptativa usando entradas, larguras e contadores idênticos.
  • O número de sequência de 16 bits podia revelar uma lacuna antes da decodificação de um pacote comprimido; Reset-Request/Reset-Ack iniciava uma nova história em zero, sem autenticar ou completar a anterior.

A compressão aconteceu antes de ser descartada

O transmissor não reconhecia um pacote incompressível por aparência. Primeiro executava o algoritmo, comparava o resultado e só então escolhia a forma de envio. Se houvesse expansão significativa, a RFC 1977 exigia o datagrama PPP original. Para uma expansão inferior a três bytes, a forma nativa também era recomendada, salvo quando a saída ainda coubesse na MTU.

A decisão protegia o tamanho útil do enlace. Obrigar todo dado a carregar um resultado maior faria as camadas superiores operar como se a MTU fosse menor. A escolha econômica era não mandar a codificação ruim.

Mas o ensaio já tinha percorrido os bytes. LZW consultara sequências, criara entradas, atualizara a largura dos códigos e alimentara os contadores de eficiência. Desfazer esses efeitos junto com a saída descartada deixaria o próximo pacote comprimido dependente de palavras que o outro lado não conhecia.

Por isso, o receptor tratava um pacote nativo na faixa de protocolos elegíveis como algo que teria se expandido. Ele o comprimia localmente apenas para atualizar o histórico. A rotina pf_bsd_incomp do apêndice incrementa a sequência, conta os bytes, calcula uma saída virtual e instala as mesmas entradas sem produzir dados para o fio.

O pacote permaneceu nativo como representação. Como evento de estado, continuou pertencendo ao compressor.

Uma tabela compartilhada entre datagramas

O compress de Unix começava e terminava com um arquivo. Em PPP, a RFC 1977 removeu esse encerramento natural e fez o dicionário continuar de um datagrama ao seguinte. Duas implementações precisavam reproduzir uma memória comum sem enviar cada alteração.

A negociação CCP definia poucos parâmetros. O tipo de opção 21 era BSD Compress. Version tinha de ser 001; Dict indicava a maior largura de código, de 9 a 16 bits, com 12 citado como escolha comum. O código fornecido no documento alcançava 15 bits, limite daquela implementação, não da faixa definida pelo protocolo.

Um receptor com mais memória não podia usar uma tabela maior por conta própria. O limite determina quando a tabela enche, quando a largura muda e quando a avaliação de desempenho passa a poder apagá-la. Um valor diferente criaria divergência exatamente onde parecia oferecer capacidade extra.

O campo Protocol do datagrama original também entrava sob uma regra comum. Valores abaixo de 0x100 tinham de ser reduzidos a um octeto antes do cálculo e da compressão, mesmo que Protocol-Field-Compression não tivesse sido negociada no PPP. O objetivo era garantir a mesma sequência de bytes para o mesmo pacote.

PPP precisava alcançar a fase Network-Layer Protocol e CCP precisava estar Opened. Esse estado autorizava a gramática escolhida. Não demonstrava que dois programas, ou um daemon de controle e código de kernel, executariam cada transição no mesmo instante.

A limpeza sem mensagem

No LZW clássico, o valor reservado 256 representava CLEAR. Dentro de um fluxo comprimido, ele podia avisar ao decodificador que a tabela acabara de ser apagada. Um pacote PPP nativo não trazia códigos LZW. Se o dicionário cheio piorasse sob dados pouco compressíveis, não havia onde colocar o aviso explícito.

A RFC 1977 substituiu a visibilidade por uma decisão reproduzível. O exemplo verifica a razão de compressão em intervalos de 10.000 bytes quando a tabela está cheia. Se a nova razão piora ou cai abaixo de um para um, pf_bsd_clear restaura a largura de nove bits, a última entrada e os contadores.

O transmissor chega ao resultado por meio da tentativa; o receptor, pela simulação do pacote nativo. Os dois precisam contar os mesmos bytes de entrada e a mesma saída teórica, alocar códigos na mesma ordem e envelhecer os contadores de modo idêntico. O CLEAR invisível é seguro apenas enquanto esses cálculos coincidem.

O desenho economizava cabeçalho e preservava a MTU, mas ampliava a superfície de interoperabilidade. Um detalhe de arredondamento ou elegibilidade podia deslocar o instante da limpeza. Logo após o apagamento, os primeiros pacotes costumavam comprimir mal e eram enviados nativamente, com a mesma aparência de tráfego anterior à ativação.

O buraco aparece no próximo pacote comprimido

Pacotes BSD Compress continham uma sequência de 16 bits em ordem de octeto mais significativo. Ela começava em zero após a limpeza, avançava para cada pacote elegível—inclusive os nativos—e voltava a zero depois de 65535. O receptor deveria conferir o valor antes de decodificar.

O pacote nativo não carregava esse cabeçalho. Se fosse perdido, o transmissor avançaria dicionário e contador, enquanto o receptor não faria nada. A ausência poderia permanecer silenciosa até chegar um pacote comprimido cujo número não correspondesse à expectativa local.

A sequência mostrava descontinuidade. Não apontava o datagrama perdido, não distinguia perda de reordenação, não fornecia os bytes ausentes e não autenticava o par. A RFC citava o FCS HDLC para corrupção e dizia apenas que questões de segurança não eram discutidas. Nem checksum de enlace nem contador cíclico oferece integridade criptográfica de ponta a ponta.

Reset cria um presente comum

Ao primeiro número inesperado, o receptor deveria enviar CCP Reset-Request e descartar pacotes comprimidos até receber Reset-Ack. O transmissor limpava a tabela e zerava a sequência a cada pedido, porque não sabia se um ACK anterior chegara. O receptor fazia o mesmo para cada resposta correspondente.

O documento compara a operação a abandonar um “arquivo” e iniciar outro. O reset não reconstitui a entrada perdida e não valida o passado. Ele cria um novo começo. Uma Configure-Request também podia retirar CCP de Opened e renegociar, com custo maior.

O tempo de ida e volta limitava as tentativas. Em um enlace ocupado, vários pacotes posteriores ao erro podiam chegar e ser descartados antes do ACK. Era necessário retransmitir o bastante para atravessar a perda, mas uma frequência superior ao RTT produzia limpezas redundantes. Um segundo era apenas um exemplo.

Havia ainda uma corrida interna. Quando o controle ficava em um daemon e os dados no kernel, a limpeza precisava preceder o Configure-Ack ou Reset-Ack que reabria a história, e o receptor devia limpar antes do pacote seguinte. Ver um ACK correto no enlace não bastava para provar essa ordenação local.

O limite do que a norma registra

A RFC 1977 especificou um núcleo pequeno e determinístico: entradas elegíveis, Version 1, teto de largura, contagem, regra de razão, sequência e reinício. A IANA mantém o tipo CCP 21 e os valores PPP de datagrama comprimido.

Na leitura de Lu Heng, esses registros descrevem a condição comum que o código pode verificar. Eles não substituem os recibos da execução. Para mostrar que dois dicionários caminharam juntos, é preciso preservar todos os pacotes elegíveis, sua ordem, as mudanças de largura, os contadores e cada limpeza.

Esta análise não reconta a negociação geral da RFC 1962, o formato serial da RFC 1963 nem a reordenação multilink da RFC 1990. Também não afirma adoção atual ou desempenho de produto. A lição histórica é mais precisa: em BSD Compress, “não comprimido” descrevia a forma enviada, não um dicionário parado.

Fontes