الخلاصة

  • يختار History Number مخزن ضغط متفقاً عليه؛ ويحافظ كل تاريخ على تسلسله وفحصه وإشارات ضبطه، من دون ترتيب مشترك بين التواريخ المختلفة.
  • تعني C/U=0 أن Data غير مضغوطة. لكن Process-Uncompressed يجعل الطرفين يحدثان التاريخ بهذه البايتات نفسها.
  • يكشف رقم التسلسل وLCB حالات مختلفة، ويحدد Reset-Ack بداية مشتركة جديدة؛ ولا يعيد أي منها البيانات المفقودة أو يثبت تسليم PPP إلى الطبقة العليا.

ما يبقى بعد الرزمة الأصلية

يمكن لـ Stac LZS أن يزيد الحجم بنسبة تصل إلى 12.5%. فإذا تجاوزت النتيجة مع الترويسة MRU لدى النظير، تلزم RFC 1967 المرسل بإرسال LZS-DCP غير مضغوطة. غير أن اختيار الشكل الأصلي لا يحسم مصير الذاكرة.

في وضع None لا يعدّل المستقبل التاريخ بهذه الرزمة. وإذا كان المرسل قد غيّر نسخته أثناء محاولة الضغط، فعليه مسحها قبل الداتاغرام التالي. أما Process-Uncompressed فيمرر البايتات الأصلية إلى نسختي التاريخ. تصف C/U شكل الحزمة، بينما يصف Process Mode أثرها المستقبلي.

يسجل RFC Editor وDatatracker النص بوصفه Informational صدر في أغسطس 1996، لا معيار إنترنت. وقد بنى على ملف Stac LZS غير المعتمد على DCP والمنشور في RFC 1974.

التقسيم يقلّص نطاق العطب

عندما يكون History Count صفراً، يُمسح المخزن عند بداية كل داتاغرام وتُضبط R-A في كل رزمة خارجة. تزول الحاجة إلى ترتيب الرزم عبر الزمن، لكن تنخفض فائدة ضغط السلسلة.

القيمة 1 تحفظ تاريخاً مستمراً. ومع تاريخين أو أكثر، ينال كل رقم مخزناً وحالة فحص وحالة إشارة مستقلة. يجب ترتيب الرزم داخل الرقم الواحد فقط. يكون الحقل بايتاً واحداً حتى 255 تاريخاً وبايتين من 256، ويظهر في الرزم المضغوطة وغير المضغوطة في الاتجاهين إذا استُخدمت تواريخ متعددة.

تذكر الوثيقة أن التاريخ قد يمثل اتصالاً منطقياً. هذا مثال لا هوية أعمال. الرقم لا يسمّي مشتركاً أو تطبيقاً أو معاملة أو خمسة عناصر للشبكة.

إشارة الضبط تسبق بيانات الرزمة

تحمل ترويسة DCP كلاً من C/U وR-R وR-A. وعلى خلاف إطار CCP العام في RFC 1962، ترتبط هذه البتات بتاريخ الرزمة وتُعالج قبل Data.

بعد فشل الاستقبال، يرسل المستقبل R-R للتاريخ المتضرر، ويمكن أن ترافقها بيانات عادية في الاتجاه الآخر. يمسح النظير الضاغط المقصود ويرد بـ R-A داخل رزمة تحتوي Data؛ وينتظر إن لم تكن بيانات جاهزة.

تثبت R-A أن التاريخ كان خالياً مباشرة قبل معالجة بيانات تلك الرزمة. لا يعود عداد المرسل إلى الصفر، بل يعيد المستقبل ضبط توقعه من رزمة R-A. وخلال الانتظار تُسقط بيانات التاريخ الفاشل وقد يُعاد R-R، بينما تستمر التواريخ الأخرى والاتجاه العكسي.

ما يُستعاد هو نقطة بدء متطابقة. أما الداتاغرامات المفقودة أو الخاطئة أو المعاد ترتيبها فلا تعود.

لكل فحص سؤال واحد

يبدأ رقم التسلسل ذي البايت الواحد من 1 ويتقدم modulo 256 في الرزم ذات البيانات ضمن التاريخ نفسه. يكشف التقدم غير المتوقع ولا يفحص المحتوى. يحسب LCB عملية XOR بين 0xFF وكل بايت من الداتاغرام الأصلي ثم يعاد حسابه بعد فك الضغط. لا يظهر إلا مع البيانات المضغوطة، وهو بايت واحد قابل للتصادم وليس سلامة تشفيرية.

لـ FCS وللوضع المرقم الموثوق في RFC 1663 نطاقان آخران. كما يثبت سجل IANA لأرقام PPP تخصيص الرموز لا نجاح جلسة بعينها.

بعد فك الضغط، يلزم إثبات أن PPP قبلت Protocol ID وInformation field وسلمتهما وفق RFC 1661، ثم إيصال من التطبيق. تعالج RFC 1990 ترتيب شظايا Multilink وبتات B/E، لا تاريخ LZS. وتبقى BSD Compress وLZW وCLEAR في RFC 1977 موضوعاً مستقلاً لحملة أخرى.

لم تُعد صفحة التصويبات محتوى صالحاً أثناء الجمع، لذلك لا نزعم خلوها. كما تقول RFC 1967 إن قضايا الأمن غير مناقشة.

تقدم مقالات Heng Lu عن Running-Code Primacy وMinimum Initial Specification وReality Layers وReality, Not Advocacy منهجاً تحريرياً يفصل الرمز عن التنفيذ والنتيجة. وليست مصادر تاريخية عن LZS-DCP.