الخلاصة

  • يصف خيار CCP ما يستطيع المستقبل فك ضغطه؛ لذلك يمكن للاتجاهين اختيار خوارزميتين مختلفتين، أو أن يعمل اتجاه واحد بلا ضغط إذا تعذر الاتفاق.
  • يؤكد Configure-Ack طلباً محدداً، وتشير 0x00FD إلى رزمة مضغوطة من دون تسمية الخوارزمية، ويغلق Reset-Ack تبادل إعادة الضبط المطابق. لا يثبت أي منها منفرداً سلامة البيانات أو استعادة المفقود أو التسليم للتطبيق.

تشترك الرسالتان المتعاكستان في وصلة واحدة، لكن قاموس كل رسالة يوجد عند الجهة التي ستفكها. بهذه الصورة البسيطة يمكن قراءة CCP: لا يعلن المرسل ما يريد فرضه، بل يعلن المستقبل ما يستطيع قبوله.

لا يبدأ CCP قبل وصول PPP إلى مرحلة بروتوكولات الشبكة، ويجب إسقاط رزم CCP السابقة بصمت. وحتى بعد ذلك لا يجوز إرسال بيانات مضغوطة قبل وصول CCP إلى حالة Opened. إنشاء الوصلة، والتفاوض على الضغط، واستخدامه ليست حادثة واحدة.

قراران للاستقبال

يمكن للمستقبل عرض عدة خوارزميات ومعلمات، ثم اختيار خوارزمية رئيسية واحدة للاتجاه الداخل إليه. يتفاوض المستقبل الآخر بصورة مستقلة. وهكذا يمكن لاختلاف الذاكرة والسرعة والكلفة والترخيص أن ينتج خيارين مختلفين أو ضغطاً أحادي الاتجاه.

خيار غير معروف يقابل بـ Configure-Reject. والخوارزمية المعروفة ذات القيم غير المقبولة تقابل بـ Configure-Nak يتضمن قيماً مقبولة. وإذا رُفضت كل الخيارات، يستمر ذلك الاتجاه بلا ضغط وتبقى الوصلة عاملة. عدم التوافق المحلي ليس حكماً على الاتصال كله.

ماذا يثبت Configure-Ack؟

وفق RFC 1661، Configure-Ack جواب إيجابي عن Configure-Request صالح بعينه. يثبت قبول بايتات الخيار في تلك اللحظة. ولكي ننسب إليه رزمة لاحقة نحتاج المعرّف والاتجاه والمعلمات وعصر الحالة ووصول الطرفين إلى Opened وغياب تفاوض أحدث.

عمّمت RFC 2153 غلاف امتدادات المورّدين؛ يحدد OUI مساحة أسماء ولا يضمن تطابق التنفيذ. وتسجل RFC 1915 مسار variance المتعلق بالخوارزميات المحمية ببراءات، لا انتشارها أو نجاحها التشغيلي.

علامة بلا اسم خوارزمية

تشير 0x00FD إلى Compressed Datagram، بينما تستخدم حالة الضغط المنفصل على كل رابط داخل multilink القيمتين 0x00FB للبيانات و0x80FB للتحكم. يحتفظ سجل IANA بهذه القيم، لكنه يثبت التخصيص فقط.

تنص RFC 1962 صراحة على أن 0x00FD لا تحدد الخوارزمية. يفسرها المستقبل عبر الخوارزمية الرئيسية الحالية في ذلك الاتجاه. من دون سجل CCP والاتجاه وعصر الحالة، لا تختار العلامة مفك الضغط الصحيح.

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

التحقق وظيفة مستقلة

فقد رزمة واحدة قد يجعل تاريخي الضغط وفك الضغط مختلفين. لا يفرض CCP العام CRC موحداً؛ يجب أن توفر الخوارزمية وسيلة لمعرفة النقل السليم أو أن تطلب نقلاً موثوقاً مثل النمط المرقم في RFC 1663.

توضح RFC 1974 إمكان استخدام أرقام تسلسل أو LCB أو CRC وتواريخ متعددة في Stac LZS، بينما تستخدم RFC 1967 ترتيباً آخر للإشارات. لا يمكن استنتاج هذه الآليات من 0x00FD. تصنيف الرزمة والتحقق من ناتجها سؤالان منفصلان.

إعادة التزامن لا تعيد الرزم

يرسل المستقبل عند الفشل Reset-Request بالرمز 14، ثم يسقط الرزم المضغوطة في الاتجاه المتضرر حتى يصل Reset-Ack بالرمز 15 والمعرّف المتوقع. يصفر الطرف الآخر ضاغط الإرسال ويرد؛ ثم يصفر المستقبل مفك الضغط. لا يتأثر الاتجاه المعاكس.

لكن الرزم التي أُسقطت أثناء الانتظار لا تعود. لا يثبت Ack نجاح CRC التالي أو موثوقية الوصلة أو إعادة إرسال TCP أو نتيجة التطبيق. إنه إيصال لإعادة التزامن، لا إيصالاً لاستعادة الخدمة.

تمنع قراءة Heng Lu القائمة على أولوية الشيفرة العاملة تحويل الوثيقة أو الرقم المسجل إلى واقع تنفيذي بذاته. يتدرج الدليل من مرحلة الشبكة إلى الطلب والـ Ack وOpened والضاغط الفعلي والعلامة والتحقق وإعادة الضبط وأول رزمة سليمة ثم وصول الطرف ونتيجة التطبيق. مرونة RFC 1962 جاءت من إبقاء كل درجة في حدودها.

Sources