Resumen

  • History Number selecciona un búfer negociado; cada historial conserva su propia secuencia, controles y señalización, sin ordenar los paquetes de historiales distintos entre sí.
  • C/U=0 sólo declara que el campo Data viaja sin comprimir. Process-Uncompressed puede hacer que esos mismos bytes actualicen el historial en ambos extremos.
  • Secuencia, LCB y Reset-Ack detectan o cierran transiciones diferentes. No reconstruyen pérdidas ni demuestran entrega a la capa superior de PPP.

El paquete que ahorró tamaño y conservó memoria

Stac LZS podía expandir datos hasta un 12,5 %. Si el resultado comprimido y la cabecera rebasaban el MRU del par, RFC 1967 obligaba a enviar un paquete LZS-DCP no comprimido. La decisión evitaba que el remedio fuese mayor que el original, pero abría otra pregunta: ¿qué ocurría con la memoria usada para el próximo paquete?

Con Process Mode None, se podía enviar la versión expandida y conservar el historial, o enviar bytes originales y limpiar el historial. Process-Uncompressed añadió una tercera posibilidad: enviar bytes originales, procesarlos en ambos lados y conservar el contexto futuro. El indicador C/U describe la forma actual; no describe por sí solo el estado siguiente.

El registro del RFC Editor y el Datatracker sitúan el documento en agosto de 1996 como Informational, no como Internet Standard. Su antecedente no-DCP fue la variante Stac LZS publicada en RFC 1974.

Los números dividen la memoria, no nombran clientes

History Count 0 limpia un único búfer al inicio de cada datagrama y marca todos los paquetes con R-A. Ya no existe dependencia entre paquetes ni exigencia de orden, a costa de comprimir cada unidad sin el aprendizaje del flujo.

El valor 1 mantiene un historial continuo. Con dos o más, cada número posee búfer, comprobación de error y señalización propios. Sólo el orden dentro del mismo History Number es obligatorio. El campo ocupa un byte entre 2 y 255 historiales y dos bytes a partir de 256; cuando se usa, aparece también en los paquetes no comprimidos y en ambos sentidos.

El RFC ofrece una conexión lógica como ejemplo de asignación. No convierte el número en identidad de negocio. Un sistema que lo etiqueta como sesión, usuario o transacción debe mostrar la tabla externa que creó esa correspondencia.

Un reset puede llevar tráfico

La cabecera DCP reúne C/U, Reset-Request y Reset-Ack. En lugar de repetir el mecanismo general de RFC 1962, R-R y R-A pertenecen al historial indicado por el propio paquete y se procesan antes de sus datos.

Tras un fallo, el receptor envía R-R para ese historial. Puede incluir datos normales de salida. El par limpia el compresor nombrado y envía R-A cuando disponga de un paquete con Data; si no hay datos, espera. R-A afirma que el historial estaba limpio inmediatamente antes de transformar los datos de ese paquete.

El contador de secuencia del emisor no vuelve a cero: el receptor realinea su referencia con el R-A. Mientras espera, descarta los paquetes del historial averiado y puede repetir R-R. Los demás historiales y el sentido contrario continúan.

La ventaja está en limitar el radio del fallo. El límite es igual de importante: los datagramas perdidos, erróneos o desordenados no reaparecen. Sólo se recupera un punto inicial común.

Dos detectores, ninguna certeza universal

La secuencia de un byte empieza en 1 y avanza módulo 256 para paquetes con datos, siempre dentro de un historial. Descubre saltos o un orden inesperado; no inspecciona el contenido. El LCB hace XOR de 0xFF con cada byte del datagrama original y compara el resultado tras descomprimir. Sólo acompaña datos comprimidos y tiene un byte, por lo que admite colisiones y no es integridad criptográfica.

El FCS del enlace y la transmisión numerada fiable de RFC 1663 cubren otros fallos. La tabla de números PPP de IANA demuestra asignaciones, no una sesión bien sincronizada.

Incluso con LCB correcto, hace falta un recibo de PPP bajo RFC 1661 y otro de la aplicación. RFC 1990 ordena fragmentos Multilink con sus propios números y bits B/E; no define los historiales LZS-DCP. RFC 1977 usa BSD Compress, LZW y CLEAR, una arquitectura reservada a otra investigación.

La consulta de erratas no devolvió un cuerpo utilizable durante la captura, de modo que no afirmamos que no existan erratas. El RFC tampoco discute seguridad y no permite inferir autenticación o protección criptográfica.

Los textos de Heng Lu sobre Running-Code Primacy, Minimum Initial Specification, Reality Layers y Reality, Not Advocacy orientan el método: medir lo que se ejecuta, no inflar un símbolo y describir sin militancia. No son fuentes históricas del protocolo.