الخلاصة

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

لم تحمل الرسالة بيانات مضغوطة فحسب

عرّفت RFC 3320، المنشورة في يناير 2003، آلية Signaling Compression أو SigComp لبروتوكولات تطبيقية مثل SIP وRTSP. ولم تفترض أن الطرفين ثبّتا مسبقاً خوارزمية الضغط نفسها. يستطيع المرسل اختيار خوارزمية وإرفاق شيفرة بايت عند الحاجة، ثم تنفذها على جهة الاستقبال الآلة الافتراضية العامة لفك الضغط، Universal Decompressor Virtual Machine (UDVM). بذلك حصل المرسل على مرونة في تمثيل البيانات، لكن الاستقبال احتاج إلى حاجز يمنع تحويل هذه المرونة إلى تحكم بلا حدود في الجهاز.

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

تنفيذ جديد لكل رسالة

تبدأ كل رسالة SigComp مستلمة نسخة منفصلة من UDVM. ولذاكرة فك الضغط حد لكل رسالة، ويجب على كل نقطة نهاية أن توفر 2048 بايت على الأقل لهذا الغرض. كما يخضع عدد التعليمات لطول الرسالة ولمعامل cycles_per_bit: فإذا كان طول الرسالة n بايت، كان الحد الأعلى (8*n + 1000) * cycles_per_bit، ولا يقل المعامل عن 16. هذه حدود تنفيذ واحد؛ فهي ليست معادلة لإجمالي موارد المضيف، ولا ضماناً ضد كل أشكال حجب الخدمة.

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

فك الضغط والتذكر إذنان منفصلان

يميز SigComp بين الذاكرة المؤقتة لفك الضغط وذاكرة الحالة المخصصة لحيّز (compartment). ويعرّف التطبيق هذه الحيّزات وفق سياق الاتصال، ويمكنه إغلاق الحيّز عند انتهاء ذلك السياق. وإذا لم يرغب الطرف في الاحتفاظ بالحالة، جاز له إعلان سعة تساوي صفراً. ومن ثم فالتخزين الدائم ليس شرطاً لفك الرسالة الحالية.

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

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

الوصول إلى حالة موجودة له بوابة أخرى

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

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

الوثائق اللاحقة عالجت مسائل مجاورة

أضافت RFC 3321 عمليات موسعة وآليات تأكيد؛ ففي النقل غير الموثوق ينبغي مراعاة التأكيد قبل اعتماد المرسل على حالة الطرف الآخر. وحددت RFC 4077 آلية إقرار سلبي للإبلاغ عن فشل فك الضغط. أما RFC 5049 فتضع متطلبات خاصة بتطبيق SigComp في SIP، ولا يصح تعميمها على جميع التطبيقات. وتقدم RFC 4464 دليلاً للمستخدم، بينما تجمع RFC 4465 اختبارات قصوى. تكمل هذه الوثائق الشرح والإبلاغ عن الأخطاء والملفات الخاصة بالتطبيقات، لكنها لا تثبت بذاتها الانتشار أو المنافع المقاسة.

كان إسهام RFC 3320 الدائم هو تقسيم الصلاحيات. تستطيع الرسالة طلب تنفيذ محدود؛ ويقرر التطبيق ما إذا كان معناها موثوقاً بما يكفي ليصبح ذاكرة تؤثر في الرسائل التالية. يجعل الفصل بين المرحلتين حدود الموارد والثقة ظاهرة، ويمنع التحول الصامت من «فُك ضغطها» إلى «حُفظت».

المصادر