Resumen

  • La RFC 3321 permitió que un compresor supiera, mediante una confirmación explícita, que el descompresor remoto había establecido un estado.
  • Esa confirmación describía un momento: la memoria insuficiente y las reglas de retención podían borrar después el estado, por lo que usarlo exigía evidencia más reciente.

Dos pruebas que suelen confundirse

La compresión dinámica de SigComp se apoyaba en una idea sencilla: si ambos extremos conservaban información de los mensajes anteriores, el siguiente mensaje de señalización podía enviarse como diferencia respecto de ese pasado. El ahorro potencial tenía una condición estricta. El descompresor debía poseer exactamente el estado que el compresor suponía disponible. Si no lo encontraba, el mensaje podía ser imposible de reconstruir.

La RFC 3321, publicada como documento informativo en enero de 2003, explicó cómo obtener conocimiento sobre ese estado. En transportes no fiables propuso confirmaciones explícitas; en un transporte fiable como TCP, la recepción del mensaje anterior ya estaba garantizada. Pero “el mensaje llegó” y “el estado derivado sigue guardado” son afirmaciones distintas. La primera pertenece al transporte. La segunda depende de autorización, capacidad, prioridad, edad y decisiones posteriores de memoria.

El documento define acked_state_id como el identificador de un estado cuya conservación fue confirmada por el descompresor. El compresor debe usar únicamente estados establecidos en el extremo remoto, pues de lo contrario habrá fallo de descompresión. Esa regla convierte la confirmación en una prueba operativa útil. No la convierte en garantía vitalicia.

El mismo fallo puede tener tres historias

La sección sobre estados de punto de control enumera tres causas para una referencia inexistente. El mensaje creador pudo perderse. El descompresor pudo carecer de memoria para crear el estado. O el estado pudo crearse y desaparecer más tarde porque otra asignación agotó la memoria.

Las tres causas producen una ausencia, pero solo la tercera puede coexistir sin contradicción con una confirmación anterior. El descompresor guardó el estado y lo confirmó correctamente; después aplicó sus reglas y lo expulsó. Si un registro de operaciones conserva solo “confirmado=true”, atribuirá el fallo posterior a corrupción o incumplimiento, cuando la secuencia prevista por el protocolo basta para explicarlo.

Un checkpoint mejora la probabilidad de permanencia: recibe la mayor prioridad de retención enviada por el mismo compresor y exige confirmación explícita. Aun así, la RFC 3321 ordena al compresor llevar cuenta de la memoria remota. El parámetro state_memory_size puede ayudarle a inferir que un checkpoint anterior fue borrado al crear otro. La palabra “inferir” impide tratar el parámetro como lista de objetos. La capacidad anunciada restringe el modelo; no nombra el contenido actual.

La optimización compartida abre otra ventana

La compresión compartida utiliza el mensaje sin comprimir recibido en una dirección como estado para comprimir en la dirección contraria. La RFC 3321 describe una optimización: cuando el segundo extremo emplea ese estado compartido, el primero puede deducir implícitamente que se creó un estado relacionado, evitando un acked_state_id adicional.

Esa deducción también caduca. El propio texto advierte que la información de anuncio puede atravesar el mecanismo con éxito mientras el estado confirmado implícitamente se descarta por falta de memoria. La señal y su objeto toman caminos temporales distintos. Si el compresor no incorpora la capacidad disponible, puede referenciar en el próximo mensaje algo que existía cuando se produjo la señal pero no cuando llegó el uso.

Además, un identificador parcial anunciado no lleva por sí solo toda la semántica. Puede representar un estado confirmado, compartido o global. La implementación debe mantener el mapa que permite reconocerlo. Una implementación SigComp básica puede ignorar los identificadores extendidos. El formato del resto del mensaje queda, en parte, como decisión de implementación. Por eso capturar el campo en una traza no basta para afirmar qué estado estaba vigente ni cómo lo entendió el receptor.

La corrección mostró una ambigüedad legítima

La RFC 4896 corrigió y aclaró varios extremos de SigComp. Recordó que la prioridad 65535 es la menor, seguida por 0 y después por los valores crecientes hasta 65534. También explicó que la prioridad se asocia a la referencia dentro de un compartimento.

Sus ejemplos de modo compartido son aún más reveladores. Al existir más de un estado de prioridad mínima, el compresor puede dejar de saber cuál permanece. Un nuevo estado puede desalojar uno antiguo antes de lo esperado, aunque ambos extremos apliquen correctamente las reglas. La incertidumbre no nace necesariamente de un paquete malicioso ni de una implementación defectuosa; nace de información distribuida insuficiente.

La aclaración exige prudencia: el compresor no debería referenciar un estado si no puede estar seguro de que existe. Una publicidad de estado significa que se creó y que estará disponible durante al menos la vida definida por las reglas de edad y prioridad. No significa que sobreviva a cualquier creación posterior.

La RFC 4077 añadió más tarde el NACK STATE_NOT_FOUND. El receptor devuelve el identificador que no pudo localizar, y el compresor normalmente deja de usarlo. Ese NACK no borra la verdad de la confirmación antigua. Marca el instante en que una creencia que antes fue razonable dejó de servir como base para actuar.

La historia técnica de la RFC 3321 es, así, una historia sobre la edad de la evidencia. La recepción, la creación confirmada, la retención actual y el éxito de la descompresión son cuatro hechos. El protocolo solo conserva su sentido si no se reducen a uno.

Sources