Resumen

  • Los dos extremos de MPPC debían conservar el mismo historial deslizante de 8192 bytes; cada paquete llevaba un contador de coherencia de 12 bits para detectar saltos u orden inesperado.
  • Ante una discrepancia, el receptor descartaba el paquete y enviaba Reset-Request. El emisor vaciaba su historial y marcaba FLUSHED en el paquete siguiente; ese paquete reiniciaba al receptor y fijaba el nuevo contador sin Reset-Ack.
  • La señal sólo acredita una nueva frontera del historial de compresión. No recupera el paquete perdido ni prueba entrega fiable, integridad, identidad, autorización o resultado de aplicación.

La respuesta se sustituyó por tráfico útil

El mecanismo genérico de RFC 1962 enlaza Reset-Request con un Reset-Ack identificado. Mientras espera esa respuesta, el descompresor desecha paquetes comprimidos; al recibirla, vuelve al estado inicial.

RFC 2118 define otro cierre para MPPC. Si llega un contador distinto del esperado, el receptor descarta el paquete y transmite Reset-Request. Cuando el compresor recibe la petición, borra su memoria y activa FLUSHED en el próximo paquete MPPC. El receptor, al verlo, borra su propio historial y adopta el contador transportado. La sincronización vuelve sin que exista un Reset-Ack.

El paquete siguiente es por ello una evidencia operativa más fuerte que la mera petición: puede decodificarse sin depender de la historia anterior. Pero no confirma que la petición haya sido entregada de una forma observable, no rellena el hueco y no demuestra que los datos hayan alcanzado su destino superior.

La opción 18 tenía un alcance acotado

MPPC debía negociarse en CCP con una opción de tipo 18 y longitud 6. Un único bit solicitaba la capacidad; si no había acuerdo, no se usaba compresión. El registro PPP de IANA mantiene el tipo 18 como Microsoft PPC.

Sólo después de que PPP alcanzara Network-Layer Protocol y CCP estuviera Opened podían circular datagramas MPPC. El campo Protocol 0x00FD identificaba la ruta de datagramas comprimidos; CCP empleaba 0x80FD. El número de datos no identifica por sí solo el algoritmo: la negociación anterior aporta ese significado.

MPPC procesaba protocolos PPP entre 0x0021 y 0x00FA. Los demás se enviaban con su número original. Aceptar la opción era, por tanto, aceptar una transformación posible, no declarar que todo el tráfico estaba comprimido.

La eficiencia dependía de una memoria de 8192 bytes

El compresor LZ mantenía un historial continuo. Tras 8192 bytes enviados de forma comprimida, disponía de una ventana completa de ese tamaño salvo que hubiera sido vaciada. Un paquete podía aprovechar patrones aprendidos en los anteriores; esa misma ventaja hacía que la pérdida de un paso separara las dos memorias.

El bit A, FLUSHED, indicaba que el emisor inicializó el historial antes de crear el paquete. El bit B devolvía el puntero al inicio del búfer y debía aparecer al menos una vez por cada 8192 bytes comprimidos. El bit C decía si los datos actuales estaban comprimidos. Son afirmaciones sobre representación y estado, no sobre entrega.

Si comprimir producía expansión, se enviaban los bytes originales en un paquete MPPC sin comprimir. Antes del siguiente intento de compresión, el emisor vaciaba el historial y señalaba FLUSHED en el próximo paquete. Evitar el coste presente implicaba renunciar al contexto acumulado.

El contador localizaba una ruptura, no validaba contenido

El contador de 12 bits comenzaba en cero, aumentaba con cada paquete MPPC y volvía a cero después de 4095. Una diferencia señalaba pérdida o desorden. Esto permitía que MPPC no exigiera un enlace fiable, aunque RFC 1663 definía un modo PPP fiable. RFC 2118 añadía una condición crucial: para resincronizar, los paquetes debían llegar en secuencia.

Un contador coincidente no es una suma de comprobación ni una autenticación. No garantiza los bytes, la identidad del par o la acción de una aplicación. El apartado de seguridad de RFC 2118 no ofrece propiedades adicionales: declara que esos problemas no se discuten.

Documento informativo y licencia histórica

RFC 2118 apareció en marzo de 1997 con estado Informational, no como estándar de Internet. Su sección de licencia limitaba MPPC a productos PPP que interoperaran con MPPC/PPP y remitía a licencias de Stac Electronics. Es un registro histórico, no una afirmación sobre licencias, patentes o implantación actuales.

La lectura aplica Running-Code Primacy y Minimum Initial Specification: cada señal debe conservar su significado verificable mínimo. La opción acuerda una capacidad, el contador descubre un salto, Reset-Request pide reparación y FLUSHED abre una época nueva. Ninguna señal autoriza conclusiones sobre capas ajenas.

Fuentes y frontera probatoria

El expediente incluye el HTML de RFC 2118, su texto, la ficha del RFC Editor y el servicio de erratas, además de RFC 1962, RFC 1661, RFC 1663 y el registro de IANA. Los textos de Heng Lu orientan la interpretación y no sustituyen a las fuentes del protocolo. El conjunto prueba la conducta especificada y el estado documental, no despliegue actual, rendimiento, seguridad ni resultado de un paquete concreto.