الخلاصة

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

سعة معلنة لا جرداً عن بعد

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

لكن معرفة الذاكرة البعيدة لم تكن استعلاماً مباشراً. يعلن الطرف عن مقدار ذاكرة الحالة، ويستعمل الضاغط state_memory_size مع ترتيب إنشاء الحالات وأولويات الاحتفاظ بها كي يستدل على ما ربما بقي. القيمة لا تقول: «هذه المعرّفات موجودة الآن». إنها حدّ للسعة، ومنه تُبنى فرضية قابلة للتقادم.

نشرت RFC 3321 في يناير/كانون الثاني 2003 بوصفها وثيقة Informational، لا معياراً للإنترنت. وهي لا تثبت انتشار SigComp أو مقدار التوفير الفعلي أو نجاح تطبيق بعينه. قيمتها هنا أنها تكشف الفرق بين واقعة موثقة في الماضي وحالة تشغيلية يجب إعادة تقييمها في الحاضر.

ماذا يثبت الإقرار؟

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

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

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

نقطة تحقق قابلة للحذف

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

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

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

إقرار ضمني سبق عملية الإخلاء

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

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

كما أن المعرّف الجزئي قد يشير إلى حالة مؤكدة أو مشتركة أو عالمية. على التنفيذ أن يستنتج النوع ويحافظ على الربط المحلي، ويمكن لتنفيذ SigComp أساسي أن يتجاهل المعرّفات الموسعة. لا تحمل البايتات معناها الكامل منفردة؛ يتحدد المعنى بالآلية والسياق والقدرات.

التصحيح الذي بيّن الغموض المشروع

أوضحت RFC 4896 ترتيب أولوية الاحتفاظ غير البديهي: القيمة 65535 هي الأدنى، ثم تأتي 0 وبعدها 1 حتى 65534. وترتبط الأولوية بمرجع الحالة داخل compartment، لا بنسخة عالمية بسيطة من البايتات.

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

كما توضح RFC 4896 أن إعلان الحالة يفيد إنشاءها بنجاح وإتاحتها على الأقل طوال العمر الذي تحدده قواعد العمر وأولوية الاحتفاظ. كلمة «العمر» هنا جزء من الضمان. حذفها يحوّل وعداً مشروطاً بقواعد الحذف إلى ادعاء دوام غير موجود في البروتوكول.

أضافت RFC 4077 لاحقاً NACK باسم STATE_NOT_FOUND. يعيد المستقبل معرّف الحالة التي لم يجدها، ويكف الضاغط عادة عن استعمالها مستقبلاً. لا يثبت هذا الرد أن الإقرار القديم كان زائفاً؛ إنه دليل أحدث على أن النموذج المحلي لم يعد يصف الذاكرة البعيدة.

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

Sources