الخلاصة

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

السعة التي توقفت داخل الجهاز

في مطلع التسعينيات بدا أن الشبكات العريضة والسريعة ستزيل العقبة الكبرى أمام المؤتمرات عن بعد. غير أن RFC 1453 سأل سؤالاً تالياً: ماذا لو وصلت السرعة إلى طبقة الربط أو النقل ولم تصل إلى البرنامج الذي يعرض الصوت والصورة؟

صدر النص الذي كتبه William J. Chimiak في أبريل 1993 بصفة Informational، ولم يكن معياراً للإنترنت. كما صرّح بأنه وسيلة لتعريف مجتمع الإنترنت ببروتوكول Xpress Transfer Protocol، أو XTP. لذلك يجب نسب المديح إلى صاحبه وسياقه، لا عرضه كحكم محايد حسمه التاريخ.

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

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

لم تكن «الوسائط المتعددة» مطلباً واحداً

جمع سيناريو RFC 1453 صوتاً وصورة تفاعليين، وبثاً متعدد الوجهات، ونقل بيانات، ورسومات، ووسائط مسجلة، واستعلامات قواعد بيانات. لكل واحد اقتصاد مختلف للوقت والكمال.

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

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

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

جودة الخدمة تبدأ من حاجة التطبيق

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

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

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

لذلك لا تجيب وصلة جيجابت عن سؤال صلاحية المؤتمر. لا تخبرنا بكلفة النسخ والجدولة، ولا إن كان المخزن يفرغ بين الدفقات، ولا إن كانت إعادة الإرسال تصل قبل انتهاء فائدة البيانات. السعة مورد للخدمة وليست الخدمة نفسها.

أراد XTP آليات مشتركة وسياسات قابلة للتبديل

انتقد RFC 1453 بناء مكدس جديد لكل فئة تطبيق. وعرض XTP كناقل غني بالآليات يستطيع التطبيق أن يختار فوقه سياسة مناسبة.

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

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

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

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

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

النجاح المحلي يكشف القيد التالي

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

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

تسير سلسلة الدليل هكذا:

سعة متاحة في الوصلة → آلية نقل مضبوطة → مسار مستدام داخل المضيف → وسائط صالحة وصلت إلى التطبيق → شروط الجلسة تحققت → تجربة المستخدم لوحظت

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

لهذا ناقش RFC 1453 تصنيع العتاد وVLSI وآلات الحالة المتوازية وواجهات النظام والمقاطعات. فقد يحسم التنفيذ والكلفة ما إذا كانت ميزة البروتوكول تصل إلى العملية. الهندسة داخل الجهاز ليست تفصيلاً يأتي بعد هندسة الشبكة.

أرقام التجربة لا تنفصل عن ظروفها

أفاد RFC 1453 بأن University of Virginia شغلت أكثر من مئة قناة صوت محاكية على FDDI، ووصف عرض بريد فيديو بمعدل ثلاثين إطاراً في الثانية، وأفاد بزمن يقارب 25 ملي ثانية من الميكروفون إلى السماعة في بث صوتي متعدد بسيط لدى NRaD، وذكر نظاماً تجارياً ينقل فيديو مضغوطاً بمعدل 1.2 Mbps في عشرة تدفقات متزامنة على الأقل.

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

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

يجب أن يبقى الفعل منسوباً: أفاد RFC بهذه التجارب. لم يصف واقع نشر شامل.

حالة محجوزة في الشبكة ومراقبة لا تعد بضمان

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

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

لاحقاً عرّف RFC 3550 بروتوكولي RTP وRTCP لنقل بيانات الزمن الحقيقي ومراقبة التسليم. لكنه نص على أن RTP لا يحجز الموارد، ولا يضمن QoS أو الوصول في موعده، ولا يضمن التسليم، ولا يمنع تبدل الترتيب. أرقام التسلسل والتقارير تزيد الرؤية ولا تصنع الخدمة.

لا يوجد ما يثبت أن RFC 1453 سبّب تصميم RTP. فائدة المقارنة هي قراءة حدود السلطة: قد يحمل البروتوكول معنى مفيداً من دون أن يسيطر على كل ما يلزم لتحقيقه.

المصادر والحدود

يثبت سجل RFC 1453 لدى RFC Editor وضع الوثيقة وتاريخها. ويأتي التشخيص ودفاع XTP والقيود والتجارب المروية من النص الكامل لـRFC 1453. ويعرض RFC 1193 متطلبات الأداء من جانب العميل. ويوثق RFC 1190 تدفق ST-II وحجز الموارد. ويحدد RFC 3550 مجال RTP وما لا يضمنه.

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