الخلاصة

  • كان على طرفي PPP حفظ التاريخ المنزلق نفسه بحجم 8192 بايت؛ وحملت كل حزمة MPPC عدّاد اتساق من 12 بت لكشف الفقد أو الترتيب غير المتوقع.
  • عند اختلاف العدّاد، يهمل المستقبل الحزمة ويرسل Reset-Request. يمسح المرسل تاريخه ويضع FLUSHED في الحزمة التالية؛ فتمسح تلك الحزمة تاريخ المستقبل وتمنحه العدّاد الجديد بلا Reset-Ack.
  • هذا الإثبات يحدد بداية تاريخ ضغط جديد فقط. فهو لا يعيد البيانات المفقودة ولا يثبت التسليم الموثوق أو سلامة المحتوى أو الهوية أو التفويض أو اكتمال التطبيق.

حلّت بيانات جارية محل جواب التحكم

تجعل RFC 1962 الاسترداد العام في CCP معاملة تحكم: يرسل مفكك الضغط Reset-Request، ثم يهمل الحزم المضغوطة اللاحقة إلى أن يتلقى Reset-Ack يحمل المعرّف المنتظر، وعندئذ يعود إلى الحالة الابتدائية.

اختارت RFC 2118 إيصالاً آخر لـMPPC. إذا لم يطابق عدّاد الحزمة القيمة المتوقعة، يهملها المستقبل ويرسل طلب الضبط. وعندما يصل الطلب إلى الضاغط يمحو تاريخه، ثم يضع FLUSHED في حزمة MPPC التالية. يرى مفكك الضغط العلامة، فيمحو تاريخه ويعتمد العدّاد المحمول في الحزمة. وهكذا تعود المزامنة بلا Reset-Ack.

الحزمة التالية مستقلة عن التاريخ القديم، ولذلك هي دليل عملي على بداية حقبة جديدة. لكنها لا تصلح الماضي: تبقى الحزمة المفقودة مفقودة، ولا يظهر إيصال مستقل للطلب، ولا يثبت وصول الحمولة إلى التطبيق.

تفاوض الخيار 18 على تحويل محدد

لم يكن MPPC صفة ضمنية لـPPP. تفاوض CCP عليه بخيار من النوع 18 والطول 6؛ وكان بت واحد فقط يعبّر عن الرغبة في الخوارزمية، وعند تعذر الاتفاق لا يستخدم الضغط. وما زال سجل PPP لدى IANA يسجل الخيار 18 باسم Microsoft PPC.

لا تبدأ حزم MPPC قبل وصول PPP إلى مرحلة Network-Layer Protocol ووصول CCP إلى Opened. تستخدم البيانات المضغوطة Protocol 0x00FD، بينما يستخدم بروتوكول التحكم CCP القيمة 0x80FD. الأولى تصنف مسار بيانات مضغوط، أما اسم الخوارزمية فيأتي من التفاوض السابق.

يعالج MPPC أرقام PPP من 0x0021 إلى 0x00FA، وتمر الأرقام الأخرى خارج الضاغط. لذلك يثبت قبول الخيار وجود قدرة متفق عليها، لا أن كل حزمة مضغوطة.

ربطت ذاكرة 8192 بايت الحاضر بالماضي

حافظت خوارزمية LZ على تاريخ مستمر. وبعد إرسال 8192 بايت مضغوطة أمكنها الرجوع إلى نافذة كاملة بالحجم نفسه ما لم يحدث flush. وفّرت الإحالات إلى البيانات السابقة سعةً، لكنها جعلت المعنى اللاحق رهين تطابق ذاكرتي الطرفين.

كان البت A، المسمى FLUSHED، يعني أن المرسل هيأ التاريخ قبل إنشاء الحزمة، فلا تعتمد على الحقبة السابقة. أعاد البت B مؤشر التاريخ إلى بداية المخزن، وكان يجب ظهوره مرة على الأقل لكل 8192 بايت مضغوطة. وأفاد البت C هل البيانات الحالية مضغوطة. لا يثبت أي منها تسليم خدمة.

إذا جعل الضغط البيانات أكبر، أرسل الطرف البايتات الأصلية في حزمة MPPC غير مضغوطة. وقبل العودة إلى الضغط كان يمحو التاريخ ويضع FLUSHED في الحزمة التالية. حماية حجم الحزمة الحالية تعني التخلي عن السياق المتراكم للمستقبل.

تكشف اثنتا عشرة بتة الانقطاع ولا تصدق المحتوى

يبدأ عدّاد الاتساق من الصفر، ويتقدم مع كل حزمة MPPC، ثم يعود إلى الصفر بعد 4095. يكشف الفرق عن فقد أو تغيير ترتيب. ولهذا لم يشترط MPPC وصلة موثوقة، مع أن RFC 1663 عرّفت نمط PPP موثوقاً.

لكن RFC 2118 اشترطت وصول الحزم بالترتيب كي تنجح إعادة المزامنة. عدم اشتراط وصلة موثوقة لا يجعل إعادة الترتيب حرة. كما أن توافق العدّاد لا يفحص البايتات. ويكتفي قسم الأمن بالقول إن الوثيقة لا تناقش قضايا الأمن؛ فلا يمنح سرية أو سلامة تشفيرية أو هوية أو تفويضاً أو منع إعادة.

وثيقة Informational وترخيص تاريخي

نُشرت RFC 2118 في مارس 1997 بوصفها Informational لا Internet Standard. وقصرت فقرة الترخيص استخدام MPPC على منتجات PPP التي تتشغّل بينياً مع MPPC/PPP، وأشارت إلى تراخيص Stac Electronics. هذا سجل للظرف التاريخي، لا حكم على تراخيص اليوم أو براءات الاختراع أو الانتشار الحالي.

يأتي ضبط القراءة من Running-Code Primacy وMinimum Initial Specification: لا يحمل كل مؤشر إلا الادعاء الأدنى الذي يمكن التحقق منه. الخيار يثبت قدرة، والعدّاد يكشف فرق ترتيب، وReset-Request يطلب الإصلاح، وFLUSHED يفتح تاريخاً جديداً. ولا يعلن أي منها نتيجة طبقة أخرى.

المصادر وحدود الإثبات

يشمل السجل الأساسي نسخة RFC 2118 بصيغة HTML، ونسختها النصية، وصفحة المعلومات، ومدخل التصويبات، إضافة إلى RFC 1962، وRFC 1661، وRFC 1663، وسجل IANA. توجّه مقالتا Heng Lu التفسير ولا تستبدلان مصادر البروتوكول. تثبت هذه المواد السلوك الموصوف والمكانة الوثائقية، لا الانتشار أو الأداء أو الأمن الحالي ولا نتيجة حزمة بعينها.