الخلاصة
- حين يزيد الضغط حجم البيانات، يرسل RFC 1977 رزمة PPP بصيغتها الأصلية كي لا تتعقد MTU، لكنه يحتفظ بتغييرات القاموس الناتجة عن محاولة الضغط، ويعيد المستقبل المحاولة محلياً لبناء الحالة ذاتها.
- لا تحمل الرزمة الأصلية رمز LZW المسمى
CLEAR، لذلك يجب أن يستخدم الطرفان المدخلات والعروض والعدادات نفسها ليصلا إلى محو القاموس التكيفي في اللحظة نفسها. - يكشف رقم تسلسل من 16 بت فجوة قبل فك رزمة مضغوطة لاحقة، ثم ينشئ Reset-Request/Reset-Ack تاريخاً جديداً من الصفر. لا يثبت أي منهما أصالة التاريخ السابق أو اكتماله.
نتيجة ضغط لم تعبر السلك
لا يعرف المرسل أن البيانات غير قابلة للضغط بمجرد النظر إليها. يشغّل BSD Compress أولاً ثم يقارن الطول الناتج بالطول الأصلي. إذا كان التوسع مهماً، أوجب RFC 1977 إرسال رزمة PPP الأصلية. وحتى الزيادة الأقل من ثلاثة ثمانيات كان يُستحسن أن تؤدي إلى الشكل الأصلي ما دام الاستثناء لا يتجاوز MTU.
يحمي ذلك السعة الفعلية للرابط. لو وجب إرسال غلاف أكبر لكل بيانات غير قابلة للضغط، لاضطرت الطبقات الأعلى إلى التعامل مع PPP كأن MTU أصغر من قيمتها المتفق عليها.
لكن تجربة الضغط حدثت فعلاً. قرأ LZW البايتات، وطابق العبارات، وأضاف مدخلات وربما نقل عرض الرمز إلى حد جديد، كما حدّث عدادات الكفاءة. التخلص من الناتج الأكبر لا يمكن أن يمحو هذه الآثار. وإلا فإن الرزمة المضغوطة التالية ستشير إلى تاريخ لم يبنه المستقبل.
لهذا يعامل المستقبل أي رزمة أصلية ذات رقم بروتوكول مؤهل كأنها كانت ستتوسع. يضغطها محلياً من أجل الحالة فقط. تسمّي الشيفرة المرجعية الوظيفة pf_bsd_incomp: تزيد التسلسل، وتحسب الإدخال والناتج الافتراضي، وتضيف مدخلات القاموس من دون أن تنتج تياراً لإرساله.
كانت الرزمة غير مضغوطة في تمثيلها على السلك، لكنها لم تكن خارج بروتوكول الضغط.
قاموس تجاوز نهاية الملف
كان أمر Unix compress يبدأ بملف وينتهي بنهايته. نقل RFC 1977 الفكرة إلى سلسلة PPP مستمرة، فتحول القاموس من ذاكرة محلية مؤقتة إلى تاريخ مشترك تعيد آلتان منفصلتان إنتاجه من ترتيب الرزم.
تحدد مفاوضة CCP نقطة البداية فقط. نوع الخيار 21 يعني BSD Compress، ويجب أن تكون Version هي 001، ويحدد Dict أقصى عرض للرمز بين 9 و16 بت؛ وذكر النص 12 خياراً شائعاً. أما الشيفرة الواردة في الملحق فتدعم 9 إلى 15 بت فقط، وهذا حد لتلك العينة لا لمجال التفاوض في المواصفة.
لا يستطيع المستقبل اختيار قاموس أكبر لمجرد امتلاكه ذاكرة إضافية. يؤثر الحد في وقت امتلاء الجدول، وانتقال عرض الرمز، ووقت فحص الكفاءة. الاختلاف المحلي سيزحزح الحدود التي يجب أن تكون مشتركة.
تدخل خانة Protocol الأصلية أيضاً تحت قاعدة موحدة. إذا كانت القيمة أقل من 0x100 فيجب اختصارها إلى ثمانية واحد قبل حساب التسلسل وضغط الرزمة، سواء تفاوض PPP على Protocol-Field-Compression أم لا. هكذا يبدأ الطرفان من البايتات نفسها.
لا تبدأ رزم BSD Compress قبل وصول PPP إلى مرحلة Network-Layer Protocol ووصول CCP إلى Opened. يثبت ACK أن المعاملات قُبلت، لكنه لا يثبت أن نواتين أو مساري تحكم وبيانات نفذا كل انتقال بالترتيب ذاته.
محو بلا إشارة ظاهرة
خصص LZW الكلاسيكي القيمة 256 للأمر CLEAR. داخل تيار مضغوط يستطيع المرسل وضعه في النهاية لإبلاغ المفكك بمحو الجدول. لا تحتوي رزمة PPP الأصلية أي رموز LZW. وإذا أدت بيانات سيئة الضغط إلى إضعاف قاموس ممتلئ، فلا يوجد موضع موثوق لإرسال الأمر الصريح.
استبدل RFC 1977 الرسالة بشرط يمكن للطرفين إعادة حسابه. تفحص العينة نسبة الضغط كل 10,000 بايت من الإدخال بعد امتلاء القاموس. إذا ساءت النسبة الجديدة أو هبطت دون واحد إلى واحد، تعيد pf_bsd_clear العرض إلى تسعة بت، وتصفّر آخر مدخل وعدادات النسبة وتحدد نقطة الفحص التالية.
يصل المرسل إلى القرار من تجربة الضغط، ويصل المستقبل إليه من محاكاة الرزمة الأصلية. يجب أن يحسبا بايتات الإدخال والناتج النظري ذاتهما، وأن يوزعا الرموز بالترتيب نفسه. غياب CLEAR الظاهر لا يلغي لحظة المحو؛ بل يجعل تطابق الحسابين دليلها الوحيد.
وفّر التصميم رأساً إضافياً وحمى MTU، لكنه حوّل تفاصيل التنفيذ إلى شروط تشغيل بيني. وقد تبدو الرزم الأولى بعد المحو عادية لأنها لا تستفيد من قاموس فارغ تقريباً، تماماً مثل الرزم التي سبقت تشغيل الضغط. لا تكشف خانة البروتوكول وحدها أي التاريخين يجري بناؤه.
لا تتكلم خانة التسلسل إلا لاحقاً
تحمل رزمة BSD Compress الفعلية رقماً من 16 بت، بالثماني الأعلى أولاً. يبدأ بصفر بعد محو القاموس، ويزداد بعد كل رزمة مؤهلة، بما فيها الرزم المرسلة أصلياً، ويلتف بعد 65535. أوصى النص بفحصه قبل فك البيانات.
لكن الرزمة الأصلية لا تحمل رأس BSD Compress ولا رقمها. إذا ضاعت، يحدّث المرسل قاموسه وعداده بينما لا يفعل المستقبل شيئاً. قد لا يظهر الغياب حتى تصل رزمة مضغوطة لاحقة برقم لا يوافق المتوقع محلياً.
يمنع الفحص استخدام قاموس معروف الخطأ، لكنه لا يحدد الرزمة الضائعة، ولا يفرق بين الفقد وإعادة الترتيب، ولا يعيد البايتات، ولا يوثق هوية النظير. يعتمد RFC على HDLC FCS وآليات الإسقاط المعتادة للفساد، ويقول قسم Security Considerations إن مسائل الأمن لم تُناقش. لا يشكل عداد ملتف ومجموع تحقق وصلة دليلاً تشفيرياً على السلامة.
Reset يترك الماضي وراءه
عند أول رقم غير متوقع ينبغي للمستقبل إرسال CCP Reset-Request وإسقاط الرزم المضغوطة إلى أن يتلقى Reset-Ack. يمحو المرسل القاموس ويعيد التسلسل إلى الصفر في كل طلب لأنه لا يعرف إن كان ACK سابق قد وصل. ويمحو المستقبل عند كل إقرار مطابق لأن المرسل قد محا بالفعل.
شبّه RFC العملية بالتخلي عن «ملف» وبدء ملف آخر. لا يعيد Reset المدخل المفقود ولا يصادق التاريخ القديم؛ إنه يصنع بداية مشتركة جديدة. ويمكن Configure-Request جديد أن يخرج CCP من Opened ويعيد التفاوض، لكن بكلفة أعلى.
على رابط مزدحم قد تصل عدة رزم مضغوطة بعد الخطأ وقبل الإقرار فتُسقط كلها. يجب تكرار الطلب بما يكفي لوصول واحد، لا بوتيرة أسرع من RTT، لأن الطلبات الزائدة تسبب محواً زائداً. والثانية المذكورة في النص مجرد مثال.
يبقى حد داخل البرنامج. إذا تعامل daemon مع CCP وتعامل kernel مع البيانات، يجب أن يرتبط محو المرسل بإرسال Configure-Ack أو Reset-Ack الذي يفتح التاريخ الجديد، وأن يمحو المستقبل قبل معالجة الرزمة التالية. وجود ACK صحيح في الالتقاط لا يثبت أن مساري التنفيذ لم يتسابقا.
ما تثبته القاعدة وما يحتاج إلى تشغيل
حدد RFC 1977 طبقة مشتركة صغيرة: المدخلات المؤهلة، Version 1، سقف العرض، حساب النسبة، التسلسل وإعادة البدء. ولا يزال سجل IANA يعرض خيار CCP رقم 21 وقيم رزم PPP المضغوطة.
وفق تأكيد Lu Heng على أولوية الشيفرة العاملة، تجعل هذه القواعد التحقق المحلي ممكناً، لكنها لا تستبدل دليل تنفيذ رابط بعينه. يلزم ترتيب كامل للرزم، بما فيها الأصلية، وتحولات العرض والعدادات وأوقات المحو لإثبات أن القاموسين تحركا معاً.
لا تعيد هذه المقالة سرد تاريخ تفاوض CCP العام في RFC 1962، ولا تنسيق النقل التسلسلي في RFC 1963، ولا إعادة ترتيب Multilink في RFC 1990. كما لا تدعي انتشاراً حالياً أو أداء منتج. حدها التاريخي أدق: «غير مضغوط» وصف شكل الرزمة المرسلة، لا سكون القاموس.
المصادر
- سجل RFC 1977 لدى RFC Editor
- RFC 1977 — PPP BSD Compression Protocol
- RFC 1962 — The PPP Compression Control Protocol
- RFC 1661 — The Point-to-Point Protocol
- IANA — تعيينات حقول PPP
- RFC 1963 — PPP Serial Data Transport Protocol
- RFC 1990 — The PPP Multilink Protocol
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- بحث RFC Editor عن تصويبات RFC 1977
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
