الخلاصة

  • سمحت RFC 3080 لعدة تبادلات مستقلة بمشاركة جلسة BEEP واحدة. أدارت القناة صفر الجلسة، بينما حدد الملف التعريفي المقبول صياغة كل قناة تطبيقية ودلالتها.
  • لا يثبت اتصال النقل أو التحية أو إعلان القدرة أو فتح القناة أو وصول الرد أن التطبيق أحدث النتيجة المطلوبة.

فُتح الطريق ولم تبدأ المحادثة

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

هذه هي المسافة التي نظمتها RFC 3080 عند نشرها في مارس 2001 ضمن مسار المعايير. كان BEEP core نواة عامة لتفاعلات غير متزامنة قائمة على الاتصال، تسمح بتبادلات متزامنة ومستقلة تحت هوية مستخدم تطبيقية واحدة. لم تمنح الاتصال معنى تطبيقياً واحداً.

حتى ربط الجلسة بالنقل بقي في وثيقة منفصلة. وضعت RFC 3081 جلسة BEEP واحدة فوق اتصال TCP واحد. ومن ثم كان نجاح TCP دليلاً على الحامل، لا على اختيار ملف أو منح صلاحية أو اكتمال عمل.

القناة صفر تفتح المسارات ولا تنجز العمل

عند البداية لم توجد إلا القناة صفر. حملت التحية، وقائمة الملفات المدعومة، وطلبات بدء القنوات وإغلاقها، ثم تحرير الجلسة.

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

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

الملف التعريفي يملك المعنى

قدمت النواة أشكال التبادل. يبدأ MSG الطلب، وينهي RPY أو ERR تبادلاً واحداً لواحد، ويحمل ANS أجوبة متعددة قبل أن يغلقها NUL. تميز أرقام الرسائل التبادلات، بينما تتقدم أرقام تسلسل الحمولة عبر كل frame في القناة.

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

أظهرت الملفات اللاحقة حدود المسؤولية. عرفت RFC 3195 تسليم syslog الموثوق في ملفات BEEP. وأعطت RFC 4227 لـSOAP حالة boot ثم ready. وفصلت RFC 4744 بين manager/agent في NETCONF وبين initiator/listener في BEEP. الطرف الذي فتح النقل لم يحصل تلقائياً على سلطة التطبيق.

الحماية الجديدة تُسقط الذاكرة القديمة

ميزت RFC 3080 قنوات الضبط الأولي عن قنوات البيانات المستمرة. يستطيع TLS أو SASL تغيير هوية الجلسة وخصوصيتها قبل التبادل الدائم، ولا تنشط إلا قناة ضبط واحدة في الوقت نفسه.

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

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

الاتصال المشترك يحتاج حساباً لكل قناة

تعامل TCP مع flow control على مستوى الاتصال. لذلك أضافت RFC 3081 نافذة منزلقة لكل قناة لتجنب الجوع والتعطل المتبادل. تبدأ القناة بنافذة 4096 أوكتات، وتعلن SEQ رقم التسلسل التالي والمساحة المقبولة.

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

تغير سجل المنافذ أيضاً

حصل syslog وSOAP وNETCONF على ملفات BEEP. ثم حررت RFC 9900 أرقام منافذ NETCONF over BEEP وNETCONF over SOAP مع إبقاء أسماء الخدمات.

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

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

المصادر

  1. https://www.rfc-editor.org/info/rfc3080
  2. https://www.rfc-editor.org/rfc/rfc3080.html
  3. https://datatracker.ietf.org/doc/rfc3080/
  4. https://www.rfc-editor.org/rfc/rfc3081.html
  5. https://www.rfc-editor.org/rfc/rfc3117.html
  6. https://www.rfc-editor.org/rfc/rfc3195.html
  7. https://www.rfc-editor.org/rfc/rfc4227.html
  8. https://www.rfc-editor.org/rfc/rfc4744.html
  9. https://www.rfc-editor.org/rfc/rfc9900.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/