Resumo

  • A RFC 3321 permitiu que o compressor dependesse de estado remoto depois de receber confirmação de que ele havia sido estabelecido pelo descompressor.
  • A confirmação não congelava a memória: retenção, idade e criações posteriores podiam expulsar o estado, inclusive quando a sinalização usada como confirmação já tinha sido entregue.

Uma memória maior que a sessão

A RFC 3321 observou que mensagens de um mesmo originador continuavam repetitivas para além da fronteira de uma sessão SIP. Um compartimento de SigComp poderia, portanto, viver mais que uma sessão de aplicação e conservar dicionários ou outros estados para chamadas futuras. O custo dessa decisão não era apenas reservar bytes. Era prolongar a validade — e o risco — do modelo que um endpoint mantinha sobre a memória do outro.

Compressão dinâmica depende de história compartilhada. O compressor codifica uma mensagem supondo que o descompressor remoto possui um estado anterior. Se a suposição estiver errada, o UDVM remoto talvez não consiga reconstruir a mensagem. Em janeiro de 2003, a RFC 3321 descreveu confirmações explícitas, compressão compartilhada, checkpoints e outras operações que poderiam ser implementadas com a máquina virtual da RFC 3320. O documento é Informational e não demonstra adoção, interoperabilidade ou ganho medido.

Uma confirmação explícita informa que um estado foi salvo com sucesso. O acked_state_id identifica esse estado, e a RFC exige que o compressor use apenas estados estabelecidos no descompressor remoto. Em transporte não confiável, essa evidência resolve a dúvida deixada por perda ou reordenação. Em TCP, a entrega da mensagem anterior é confiável. Nenhuma das duas coisas torna o armazenamento ilimitado.

Criado, confirmado, removido

O mecanismo de checkpoint enumera três razões para um estado referenciado não existir. A mensagem que o criaria pode ter sido perdida. A memória pode ter sido insuficiente no momento da criação. Ou o estado pode ter sido estabelecido e eliminado mais tarde por falta de memória.

A última hipótese muda a leitura de uma confirmação. “Foi criado” e “não está mais presente” podem ser duas descrições corretas de momentos diferentes. O checkpoint recebe a maior prioridade de retenção enviada por aquele compressor e precisa ser confirmado explicitamente, mas continua submetido às regras de idade e pressão de memória.

Por isso o compressor deve acompanhar a memória de estado disponível no endpoint remoto. O parâmetro state_memory_size ajuda a inferir se a criação de um checkpoint posterior expulsou o anterior. Ele não lista os identificadores presentes e não funciona como consulta em tempo real. É uma restrição de capacidade combinada com ordem, prioridade e idade para reconstruir o que ainda pode existir.

Essa questão ganha peso quando o compartimento atravessa sessões. Quanto mais tempo ele vive, maior o intervalo entre a confirmação inicial e o uso posterior, e maior o conjunto de criações capazes de alterar a memória. O benefício de amortizar o estado vem junto com uma dívida de observabilidade: sem a cronologia, um ganho de eficiência vira uma dependência invisível.

A confirmação implícita podia chegar depois do descarte

Na compressão compartilhada, o endpoint guarda a versão não comprimida de uma mensagem como estado, independente do algoritmo usado na direção oposta. A RFC 3321 descreve uma otimização: o uso desse estado compartilhado pode indicar implicitamente que outro estado foi criado no endpoint remoto, dispensando um acked_state_id separado.

Mas a informação de anúncio pode ser encaminhada com sucesso mesmo se o estado relacionado for descartado por insuficiência de memória. O mecanismo confirma uma criação; a memória muda antes do próximo uso. A RFC manda considerar essa possibilidade e usar state_memory_size para inferir falha ou perda de estado. Tratar o anúncio como fotografia permanente produz precisamente a falha que a otimização queria evitar.

Há ainda uma camada de interpretação. Identificadores parciais podem anunciar estado confirmado, compartilhado ou global. Cabe à implementação deduzir o tipo, e uma implementação básica de SigComp pode ignorar os identificadores estendidos. O formato de partes da mensagem permanece decisão do compressor que fornece o bytecode. Assim, um valor capturado na rede não revela sozinho qual estado foi entendido nem se continuava recuperável.

A correção expôs o limite da certeza

A RFC 4896 esclareceu que a ordem de prioridade de retenção é contraintuitiva: 65535 é a menor, seguida de 0, 1 e assim por diante. A prioridade pertence à referência de um compartimento, não apenas aos bytes globais do estado.

Se mais de um estado de prioridade mínima existir, o compressor pode perder a certeza sobre quais peças continuam no compartimento remoto. Um novo estado pode expulsar o anterior antes do esperado mesmo quando os dois lados cumprem corretamente as regras. A recomendação resultante é direta: não referenciar estado sem poder ter certeza de que ele existe.

A mesma correção explica o alcance de um anúncio iniciado pelo endpoint. Ele diz que o estado foi criado e ficará disponível pelo menos durante a vida definida pelas regras de idade e prioridade. É uma promessa condicionada ao ciclo de vida, não uma exceção à exclusão.

A RFC 4077 acrescentou depois o NACK STATE_NOT_FOUND. Ao receber essa evidência, o compressor normalmente deixa de usar o estado em mensagens futuras. O NACK não prova que a confirmação anterior estava errada. Ele atualiza uma linha do tempo em que o estado existiu, foi confirmado e depois desapareceu.

Essa sequência é a contribuição mais duradoura da RFC 3321. A confirmação tornou o estado remoto utilizável, mas só enquanto outras evidências não mudassem a conclusão. Sistemas distribuídos não precisam apenas de recibos corretos; precisam saber quando esses recibos deixam de descrever o presente.

Sources