الخلاصة

  • أتاح RFC 1553 تقليص رأس IPX من 30 ثُمانيّة إلى ما بين واحدة وسبع، وتقليص رأس NCP/IPX المجمّع من 36 إلى ما بين واحدة وثمان. لم تختفِ الحقول المحذوفة؛ بقيت في فتحات متناظرة لدى الضاغط وفاكّ الضغط.
  • في IPX العام كان على Confirmed Initial أن يثبت الفتحة ومعرّف جيلها، ثم يصل Confirm قبل الاعتماد على ذلك السياق في حزم مضغوطة. أما NCP فحصل على مسار أضيق بلا تأكيد لأن تسلسله وإعادة الإرسال فيه يستطيعان كشف فقد السياق.
  • كان حذف رقم الفتحة نفسه معطّلًا افتراضيًا. ولا يصح تشغيله إلا إذا عرف فاكّ الضغط بكل حزمة تالفة أو مطروحة؛ وبعد الفقد يتخلّص من الحزم ذات الفتحة الضمنية حتى تعيد حزمة صريحة تثبيت المرجع.

الرد القصير الذي منح الذاكرة سلطة

ليس في Confirm رأس الاتصال الذي سيُستعاد لاحقًا. الرأس الكامل كان قد وصل في Confirmed Initial وحُفظ في فتحة. وظيفة الرد القصير أضيق وأهم في آن: أن يبيّن أن الطرف المستقبل صار يملك الجيل المقصود من تلك الفتحة. بعده فقط يصبح من المشروع أن ترسل الحزم التالية التغييرات القليلة وتترك بقية الحقول لذاكرة المستقبل.

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

هنا يظهر المعنى المؤسسي للتأكيد. هو لا يثبت أن التطبيق نجح، ولا أن الرابط آمن، ولا أن التنفيذ خالٍ من العلل. إنه إيصال محدود لواقعة محدودة: جيل بعينه من الذاكرة المشتركة أصبح حاضرًا عند الجهة التي ستستخدمه. قوة الآلية جاءت من ضيق هذا الادعاء لا من توسيعه.

RFC 1553، المنشور في ديسمبر/كانون الأول 1993 بوصفه Standards Track والمصنّف اليوم Historic، بنى ضغط رؤوس IPX فوق هذا الفصل بين ما يصل فعلًا وما يمكن استعادته. كان اسمه Compressing IPX Headers Over WAN Media واختصاره CIPX. لكنه، في جوهره، كان بروتوكولًا لإدارة الذاكرة المتقابلة قبل أن يكون حيلة لحذف البايتات.

ثلاثون ثُمانيّة لم تتحول إلى واحدة بلا مقابل

حدّد المستند طريقتين. الطريقة العامة تقارن رأس IPX الجديد برأس كامل محفوظ، وتستطيع تقليص 30 ثُمانيّة إلى ما بين واحدة وسبع. والطريقة الثانية المطلوبة تخص طلبات وردود NCP من النوعين 0x2222 و0x3333، فتعامل رأس NCP/IPX ذي 36 ثُمانيّة كوحدة واحدة وتضغطه إلى ما بين واحدة وثمان. ويمكن لبقية أنواع NCP أن تستخدم ضغط IPX العام، لكنها لا ترث منطق NCP المتخصص لمجرد أنها تحمل الاسم نفسه.

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

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

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

موضع المراقبة يحدد أي بايت يمكن نسبته إلى أي وظيفة

كان من الممكن جمع ضغط الرأس مع ضغط البيانات. لكن ترتيب العمليتين كان محددًا: عند الإرسال يُضغط الرأس أولًا ثم البيانات؛ وعند الاستقبال تُفك البيانات أولًا ثم يُفك الرأس. لا يصلح تبديل الترتيب، لأن العملية الثانية تعمل على ناتج الأولى.

هذا التفصيل يحدد أيضًا حدود الدليل. لقطة مأخوذة قبل فك ضغط البيانات ليست الشيء نفسه كلقطة بعد إعادة بناء رأس IPX. وإذا حُفظت الحزمة النهائية وحدها، ضاع الفرق بين حقل وصل في الإطار وحقل استُنتج من فتحة. لذلك لا يكفي أن تقول سجلات التشغيل إن «الحزمة أعيد بناؤها»؛ يجب أن تحدد في أي نقطة رُصدت، وأي تحويل سبقها، وأي حالة ساهمت في النتيجة.

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

الفتحة عنوان مؤقت، والجيل هو المعنى

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

لذلك حملت البداية مع رقم الفتحة معرّفًا من ثُمانيّة واحدة. عندما يُسند رأس جديد إلى الفتحة يرتفع المعرّف. رقم الفتحة ومعرّفها معًا يسمّيان جيلًا: ليس «الدرج الثالث» فقط، بل النسخة المحددة من محتوى ذلك الدرج.

الثُمانيّة ليست زمنًا لا نهائيًا؛ ستلتف قيمتها في نهاية المطاف. تحدّث المستند عن بقاء الهوية مميزة مدة «طويلة على نحو معقول»، وربط معقولية المدة بسرعة الرابط وزمن الذهاب والعودة والحمل. كان ذلك تقديرًا لنافذة تشغيل، لا ضمانًا أبديًا ضد كل تأخير أو كل نمط إعادة استخدام.

ولم يُلزم الضاغط بحبس البيانات في انتظار التأكيد. يمكنه تكرار رقم الفتحة والمعرّف نفسيهما مع بيانات جديدة للرأس ذاته. ويمكنه أن يعيد تخصيص الفتحة لرأس مختلف مع زيادة المعرّف. سمح التصميم بالتقدم، لكنه ألزم كل انتقال بأن يحمل ما يكفي لتمييز جيله.

لماذا احتاج IPX العام إلى Confirmed Initial

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

جاء Confirmed Initial ليضع الرأس الكامل ورقم الفتحة ومعرّف الجيل لدى الطرف الآخر. ثم يعيد المستقبل Confirm. لا تبدأ الحزم المضغوطة المعتمدة على الارتباط قبل وصول ذلك الرد. وبهذا لا يتحول الاعتقاد المحلي إلى افتراض مشترك من دون أثر قادم من الطرف الذي سيتحمل عملية الاستعادة.

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

الفصل بين المراحل يمنع سلسلة من القفزات المريحة: قبول خيار IPXCP ليس Confirm؛ وConfirm ليس دليلًا على أن الجدولين بقيا متطابقين؛ وإعادة بناء رأس ليست استجابة ناجحة من NCP؛ والضغط الجيد ليس جودة خدمة. كل قفزة تمحو مالكًا مختلفًا وشرطًا مختلفًا.

لماذا سُمح لـ NCP ألا ينتظر

المسار المتخصص في NCP سمح بـ Unconfirmed Initial ثم ببدء الضغط فورًا. قد يبدو ذلك تناقضًا: لماذا تكون الذاكرة خطرة في حالة ومقبولة بلا إيصال في حالة أخرى؟ الجواب ليس أن NCP أوثق، بل أن لديه إشارة مختلفة يستطيع بها كشف الكسر.

تسلسل الطلبات والردود وسلوك إعادة الإرسال في NCP يمكن أن يكشفا أن السياق المتوقع لم يصل أو لم يعد متصلًا بالحزمة التالية. وإذا لم يكن رقم التسلسل أكبر بواحد تمامًا، كان على المرسل إرسال Initial جديدة، حتى عند الاستمرار في استخدام الفتحة نفسها. الاستثناء لم يلغِ إثبات الفقد؛ استعاره من سلوك أعلى في المكدس.

هذه نقطة تصميم أعمق من تفاصيل IPX. حذف خطوة صريحة لا يصبح آمنًا لأن الخطوة بطيئة أو لأن النجاح شائع. يصبح مقبولًا فقط عندما توجد خاصية بديلة محددة، ويمكنها كشف الفشل وإجبار النظام على العودة إلى حالة صريحة. لذلك لا يمكن نقل رخصة NCP إلى حركة أخرى لا تحمل التسلسل وإعادة الإرسال نفسيهما.

ويكشف الفرق أيضًا أن كلمة «تأكيد» ليست طقسًا واحدًا لجميع المسارات. في IPX العام، الرد المباشر هو مصدر السلطة. في NCP، يشارك سلوك الطلب والرد في كشف الانقطاع. النتيجة العملية واحدة: يجب أن يعرف المشغل من أين جاءت الثقة بكل سياق، لا أن يكتفي بحقل يقول إن الضغط مفعّل.

حذف رقم الفتحة جعل كل فقد حدثًا دلاليًا

بعد حذف الحقول المتكررة، بقيت فرصة لتوفير ثُمانيّة أخرى: يمكن للحزمة أن تحذف رقم الفتحة وتعني «استخدم الفتحة التي استخدمتها الحزمة السابقة». ما دامت كل الحزم تصل بالترتيب، تتطابق عبارة «السابقة» عند الطرفين.

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

لهذا كان ضغط رقم الفتحة معطّلًا افتراضيًا. ولا يجوز تشغيله إلا حين تبلغ طبقة PPP فاكّ الضغط بكل حزمة خاطئة أو مطروحة. لا يكفي عدّ الخسائر لاحقًا في لوحة إجمالية؛ يجب أن يعرف المكوّن الذي يفسر «السابق» أن حلقة محددة من السلسلة غابت في زمنها الصحيح.

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

هنا تصبح الرؤية بين الطبقات جزءًا من صلاحية تنسيق البتات. ليست المراقبة زينة تضاف بعد النشر. حذف الثُمانيّة خلق اعتمادًا على إشعار الفقد؛ إذا لم يصل الإشعار، سقط الشرط الذي يجعل الصيغة المختصرة ذات معنى واحد.

إعادة التشغيل كانت اختبارًا لحق الذاكرة في الاستمرار

حين يعيد طرف التشغيل، تختفي حالته وقد يعود إلى IPX العادي. أما الطرف المقابل فقد يظل محتفظًا بجدول CIPX القديم. ولهذا احتاج البروتوكول إلى تمييز بداية رأس IPX التقليدي ذي checksum 0xFFFF عن ثُمانيّة أعلام مضغوطة.

حُجزت القيمة 0xFF لكي يرى الطرف المستمر أن ما أمامه ليس مجرد حزمة أخرى داخل التاريخ القديم. عليه أن يتعرف إلى العودة للشكل العادي ويعيد التفاوض بدل أن يمنح الفتحات السابقة عمرًا لم يوافق عليه الطرف المعاد تشغيله.

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

Reject جعل عدم الفهم مرئيًا

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

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

النظام الذي لا يستطيع الرجوع عن الاختصار يحوّل الكفاءة إلى قفل. يصبح استمرار الاتصال معتمدًا على تظاهر الطرفين بأن تفسيرهما واحد. أما المسار المرئي للفشل فيحصر الخلاف ويمنع ادعاء نجاح لا يستطيع أي سجل لاحق الدفاع عنه.

التفاوض الاتجاهي ليس هو الاتفاق المتماثل

في PPP استُخدم خيار داخل IPXCP. الضغط كان متوقفًا افتراضيًا، وكل طرف يطلب قدرة الاستقبال في اتجاهه. ولذلك يحتاج الضغط ثنائي الاتجاه إلى طلبين منفصلين. إثبات أن A يستطيع إرسال مضغوطًا إلى B لا يثبت تلقائيًا أن B يستطيع فعل الشيء نفسه نحو A.

أما IPX-WAN فكان يصل إلى نتيجة متماثلة: العدد نفسه من الفتحات ومجموعة فرعية مشتركة من الخيارات في الاتجاهين. الاختلاف ليس شكليًا. فهو يحدد ما ينبغي أن يسجله إيصال التفاوض: اتجاهات مستقلة في PPP، أو كيفية اختيار المجموعة المشتركة والحد المتناظر في IPX-WAN.

وفي الحالتين لا تكفي كلمة «متفاوض عليه». الاتفاق على الخوارزمية وعدد الفتحات وخيار حذف الرقم لا يثبت وصول Initial أو Confirm، ولا يثبت سلامة الجيل، ولا البايتات المعاد بناؤها، ولا استعادة النقل، ولا نتيجة التطبيق. التفاوض إذن باب للدخول إلى نظام الحالة، لا شهادة على كل ما حدث داخله.

النسبة الجذابة كانت نموذجًا لا قياسًا

قدّم المستند مثالًا يقارب اثنين إلى واحد: 26 ثُمانيّة من البيانات مع 30 من الرأس الأصلي تعطي 56، بينما رأس مضغوط من ثُمانيّتين يجعل المجموع 28. الحساب صحيح ضمن فرضياته، لكن نوع الدليل لا يتغير لجمال النتيجة.

لم يكن ذلك قياسًا لانتشار ميداني. لا توجد فيه عينة حركة، ولا توزيع أحجام، ولا معدل فقد، ولا تكرار Initial وConfirm وReject والشكل العادي، ولا كلفة الطرح حتى استعادة فتحة صريحة. ولا يقيس زمن المعالجة أو إعادة الإرسال أو نتيجة المستخدم. تعتمد النسبة على أن تشبه الحركة المثال وأن يبقى السياق مستقرًا.

وقال RFC إن CIPX لا يغير على نحو مهم الأمن الأساسي لـ IPX. ينبغي نقل هذه العبارة باعتبارها حد التقييم في وثيقة 1993، لا ضمانًا حديثًا لكل تنفيذ أو إدخال مشوه أو تركيب مع طبقات لاحقة.

ولا تسمي مجموعة المصادر المجمدة نشرًا محددًا لـ CIPX، أو قاعدة أجهزة، أو corpus للحركة، أو اختبار توافق، أو حادثة، أو نتيجة مستخدم. إنها تثبت قواعد البروتوكول وسلسلة الوثائق. ولا تثبت كم رأسًا من ثُمانيّة واحدة عبر فعلًا أو أي منتج استعاد السياق بلا خطأ.

كل بايت محذوف أضاف بندًا إلى سلسلة الإثبات

السجل الكافي يبدأ بمالك التفاوض واتجاهه، والخيارات المقبولة، وعدد الفتحات. ثم يحتاج إلى مخصص الفتحة ومعرّف جيلها، والرأس الكامل في Initial، وConfirm حين يكون واجبًا، ومصدر الثقة البديل في مسار NCP.

بعد ذلك تأتي رؤية أخطاء الرابط، وتسلسل الحزم المقبولة، وهل كانت الفتحة صريحة أم ضمنية، ومصدر الطول والـ checksum، وبصمة الرأس المعاد بناؤه، وقرار فاكّ الضغط، واستعادة النقل، ونتيجة التطبيق. لا يمكن لحقل واحد أن ينوب عن هذه السلسلة لأن كل حلقة تخضع لطرف مختلف وتجيب عن سؤال مختلف.

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

المصادر