Résumé

  • MPPC exigeait que les deux pairs PPP conservent le même historique glissant de 8192 octets ; un compteur de cohérence de 12 bits révélait une perte ou un ordre inattendu.
  • Après un écart, le récepteur jetait le paquet et envoyait Reset-Request. L’émetteur vidait son historique et marquait le paquet suivant FLUSHED ; celui-ci réinitialisait le récepteur et imposait le nouveau compteur, sans Reset-Ack.
  • Ce reçu est limité : il établit un nouvel historique MPPC, mais ne restitue aucune donnée perdue et ne prouve ni livraison fiable, ni intégrité, ni identité, ni autorisation, ni résultat applicatif.

La réponse absente du fil

La procédure générale de RFC 1962 ressemble à une transaction de contrôle. Après Reset-Request, le décompresseur ignore les paquets compressés jusqu’à réception d’un Reset-Ack portant l’identifiant attendu. La remise à zéro est attachée à cette réponse.

Le profil MPPC de RFC 2118 déplace la preuve sur le chemin des données. Si le compteur reçu n’est pas celui attendu, le paquet est abandonné et Reset-Request est envoyé. Quand le compresseur reçoit cette demande, il efface son historique et pose FLUSHED sur son prochain paquet. Le décompresseur efface alors sa propre mémoire et adopte le compteur porté par ce paquet. La synchronisation revient sans Reset-Ack.

Ce paquet suivant est donc le premier élément exécutable du nouvel épisode. Il ne raconte toutefois pas le passé : il ne démontre pas que chaque paquet précédent est arrivé, ne reconstitue pas la perte et ne certifie pas la remise au logiciel destinataire.

L’option 18 négociait une transformation précise

MPPC n’était pas une propriété implicite de PPP. Son option CCP, de type 18 et de longueur 6, utilisait un seul bit pour demander l’algorithme ; en cas de désaccord final, aucune compression n’était appliquée. Le registre PPP de l’IANA conserve l’attribution « Microsoft PPC » pour le type 18.

Les datagrammes ne pouvaient commencer qu’après l’entrée de PPP dans la phase Network-Layer Protocol et l’ouverture de CCP. Leur champ Protocol valait 0x00FD, alors que CCP lui-même utilisait 0x80FD. Le premier désigne un chemin de datagramme compressé, pas l’algorithme à lui seul ; l’option négociée fournit ce contexte.

Seuls les protocoles PPP de 0x0021 à 0x00FA passaient par MPPC. Les autres gardaient leur numéro et contournaient la compression. Un accord sur l’option prouvait donc une capacité acceptée, non l’emploi de cette capacité sur chaque paquet.

Une mémoire de 8192 octets liait les paquets

L’algorithme LZ gardait un historique continu. Après 8192 octets transmis sous forme compressée, il disposait d’une fenêtre de 8192 octets, sauf après effacement. Le gain venait précisément de la dépendance : un paquet tardif pouvait renvoyer à des octets vus plus tôt. La même dépendance transformait une perte en divergence des deux mémoires.

Le bit A, nommé FLUSHED, indiquait que l’émetteur avait initialisé l’historique avant de produire le paquet ; celui-ci ne dépendait donc pas de l’épisode précédent. Le bit B ramenait le pointeur au début du tampon et devait apparaître au moins une fois tous les 8192 octets compressés. Le bit C indiquait si les données présentes étaient compressées. Aucun de ces bits ne disait que l’application avait reçu quoi que ce soit.

L’expansion déclenchait une autre frontière. Si le résultat compressé était plus long, l’original partait dans un paquet MPPC non compressé. Avant de compresser de nouveau, l’émetteur effaçait l’historique et marquait le prochain paquet FLUSHED. Économiser des octets maintenant pouvait donc sacrifier le contexte utile plus tard.

Douze bits signalaient une rupture, pas une garantie

Le compteur de cohérence partait de zéro, avançait pour chaque paquet MPPC et bouclait après 4095. Une différence révélait un pas manquant ou inattendu. C’est ce mécanisme qui permettait de ne pas exiger une liaison fiable ; RFC 1663 proposait un mode PPP fiable, que la RFC 2118 jugeait généralement superflu pour ce besoin.

Le texte exigeait néanmoins un ordre de livraison pour que la resynchronisation fonctionne. L’absence d’exigence de transport fiable n’autorisait pas un réordonnancement arbitraire. Et un compteur correct ne vérifiait pas le contenu : la rubrique sécurité de la RFC 2118 dit seulement que ces questions ne sont pas traitées.

Un mécanisme historique sous licence

Publié en mars 1997, RFC 2118 était Informational et non une norme Internet. Sa partie licences limitait l’usage de MPPC aux produits PPP destinés à l’interopérabilité MPPC et indiquait des licences de Stac Electronics. Ce document est une preuve historique, pas une conclusion sur les droits, brevets ou déploiements actuels.

La lecture suit la discipline de Running-Code Primacy et de Minimum Initial Specification : ne faire porter à chaque signal que sa fonction vérifiable. L’option nomme une capacité, le compteur constate un écart, Reset-Request demande une réparation et FLUSHED ouvre un nouvel historique. Aucun ne devient un reçu de sécurité ou de service.

Sources et limite de preuve

Le dossier primaire réunit le HTML de RFC 2118, son texte, sa notice RFC Editor et son point d’errata, ainsi que RFC 1962, RFC 1661, RFC 1663 et le registre IANA. Les essais de Heng Lu encadrent l’interprétation, pas l’histoire du protocole. L’ensemble établit la spécification et son statut documentaire, non l’usage contemporain, la performance, la sécurité ou le résultat d’un paquet réel.