Resumen

  • En CCP, cada receptor anuncia los algoritmos que puede usar para descomprimir; por eso cada sentido puede elegir una opción diferente y el desacuerdo deja ese sentido sin compresión, no sin enlace.
  • Configure-Ack acepta una solicitud concreta, 0x00FD sólo declara “datagrama comprimido” y Reset-Ack confirma el intercambio de reinicio esperado. Ninguno demuestra por sí solo el algoritmo de una trama posterior, la integridad, la recuperación de pérdidas ni la entrega final.

Una conversación telefónica tiene dos voces, aunque comparta un cable. RFC 1962 trató la compresión de PPP con esa misma intuición: lo que A sabe recibir de B no determina lo que B sabe recibir de A.

CCP aparece después de que PPP haya establecido el enlace y alcanzado la fase de protocolos de red. Antes de esa fase, un paquete CCP debería descartarse sin respuesta. Para enviar datos comprimidos no basta con haber visto una opción: el propio CCP debe estar en estado Opened.

La opción pertenece al que escucha

El significado direccional suele perderse en los resúmenes. Una opción de configuración CCP indica lo que el receptor está dispuesto o es capaz de descomprimir. Puede ofrecer varios métodos y terminar con uno principal para las tramas que le envía su par. El receptor opuesto negocia su propia lista.

La asimetría era práctica. Memoria, velocidad, precio o licencias podían ser distintos. Un módem podía decodificar un algoritmo costoso aunque su par no pudiera, o decidir que sólo un sentido merecía compresión.

CCP también define una salida limpia. Una opción desconocida recibe Configure-Reject; una conocida con parámetros inaceptables recibe Configure-Nak con valores aceptables. Si todas se rechazan, ese sentido funciona sin compresión. La conexión permanece. La incompatibilidad local no se convierte en una sentencia global.

El límite de Configure-Ack

RFC 1661 define Configure-Ack como respuesta positiva a un Configure-Request válido. La evidencia es exacta pero estrecha: el par aceptó esos bytes de opción en ese intercambio. Para atribuir una trama posterior hacen falta identificador, dirección, parámetros, época, ausencia de una renegociación y prueba de que ambos lados llegaron a Opened.

RFC 2153 amplió el modo de transportar extensiones de fabricante. Un OUI identifica el espacio de un proveedor, pero no certifica que dos binarios entiendan igual el subtipo. Del mismo modo, RFC 1915 documenta la varianza procesal provocada por algoritmos patentados; no demuestra adopción ni rendimiento.

El número 0x00FD no nombra al compresor

En la fase abierta, el campo Protocol 0x00FD señala un Compressed Datagram. Si un conjunto multilink mantiene compresión por enlace físico, 0x00FB señala los datos de ese enlace y 0x80FB su control. IANA conserva esos registros.

Pero RFC 1962 advierte que el campo no identifica el algoritmo. El receptor lo deduce del único método principal negociado para esa dirección. Una captura sin transcripción CCP y sin época sólo afirma que alguien marcó la trama como comprimida; no selecciona un decodificador fiable.

Tampoco garantiza ahorro. Algunos datos crecen al comprimirse. Si la salida supera el máximo de la información PPP, el perfil puede volver a la trama nativa o fragmentar. La palabra describe una ruta de procesamiento, no un porcentaje.

Integridad y clasificación no son la misma prueba

La compresión con historial crea dependencia temporal. Si falta un bloque, el diccionario del receptor puede divergir y producir bytes plausibles pero erróneos. CCP no añade un CRC universal. Exige que el perfil detecte si los datos pasan de forma fiable o que requiera un transporte fiable como el modo numerado de RFC 1663.

RFC 1974 muestra una solución concreta: Stac LZS puede usar número de secuencia, LCB o CRC y varios historiales. RFC 1967 organiza de otro modo sus bits de reset y comprobación. Nada de eso está contenido en 0x00FD.

Un registro serio formula dos preguntas: ¿la trama pertenece al algoritmo negociado? ¿Su secuencia y su comprobación específica permiten aceptar los bytes descomprimidos? La primera respuesta no incluye la segunda.

Un reinicio borra estado, no recupera tiempo

Cuando detecta fallo, el receptor envía Reset-Request, código 14. Desde entonces descarta los paquetes comprimidos de ese sentido y puede repetir el mismo identificador hasta recibir un Reset-Ack válido. El par borra su compresor de envío y copia el identificador en el Ack; entonces el receptor borra su descompresor.

La dirección contraria no participa. Esa es la virtud de la operación. Sin embargo, los paquetes descartados no reaparecen. Reset-Ack dice que la conversación de sincronización llegó al punto acordado; no dice que el siguiente bloque validará, que el transporte es fiable o que la aplicación recuperó su transacción.

En perfiles como RFC 1974, la responsabilidad de repetir la solicitud hasta obtener respuesta es explícita. La recuperación de datos puede venir de TCP, de la aplicación o de ningún sitio. CCP sólo restablece el estado desde el que es seguro volver a intentar.

Lo que quedó para la historia

La lectura de Heng Lu sobre primacía del código ayuda a contener el significado de cada señal. El estándar coordina una sintaxis y unas transiciones; el funcionamiento real exige implementación, observación y resultado. La especificación mínima es común, mientras la capacidad de cada receptor y la decisión de comprimir permanecen locales.

La escalera de evidencia es concreta: fase de red, solicitud por dirección, Ack coincidente, Opened, compresor seleccionado, marca de trama, secuencia/integridad, reset si hubo fallo, primer datagrama válido posterior, recepción del extremo y efecto de aplicación. El gran logro no fue prometer que todo saldría bien. Fue permitir que un lado admitiera que su diccionario estaba mal sin obligar al otro a detenerse.

Sources