زمارة

بروتوكول تبادل الكتل القابل للتوسيع ( BEEP ) هو إطار عمل لإنشاء بروتوكولات تطبيقات الشبكة. يتضمن BEEP لبنات بناء مثل التأطير، والتسلسل ، والتعدد، والإبلاغ، والمصادقة لبروتوكولات الاتصال والرسائل الموجهة من نظير إلى نظير (P2P) مع دعم الاتصال غير المتزامن ثنائي الاتجاه الكامل .

يتم تحديد بنية الرسائل ودلالاتها باستخدام ملفات تعريف BEEP المرتبطة بقناة BEEP واحدة أو أكثر، حيث تمثل كل قناة قناة اتصال ثنائية الاتجاه . وتتيح آلية التأطير التواصل المتزامن والمستقل بين الأجهزة المتصلة.

تم تعريف بروتوكول BEEP في RFC 3080 بشكل مستقل عن آلية النقل الأساسية. ويتم تحديد ربط بروتوكول BEEP بخدمة نقل معينة في سلسلة وثائق منفصلة. 

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

يتضمن بروتوكول BEEP أيضًا بروتوكول TLS للتشفير وبروتوكول SASL للمصادقة .

في عام 1998، قام مارشال تي. روز ، الذي عمل أيضًا على بروتوكولات POP3 و SMTP و SNMP ، ^{[ 1 ]} بتصميم بروتوكول BXXP، ثم سلمه إلى فريق عمل فرقة عمل هندسة الإنترنت ( IETF ) في صيف عام 2000. وفي عام 2001، نشرت فرقة عمل هندسة الإنترنت بروتوكول BEEP ( RFC 3080 ) وبروتوكول BEEP على TCP ( RFC 3081 ) مع بعض التحسينات على بروتوكول BXXP. وأبرز ثلاثة منها هي:  

• استخدام application/octet-stream كنوع المحتوى الافتراضي
• دعم الردود المتعددة على الرسائل
• تغيير الاسم من BXXP إلى BEEP

لبدء جلسة BEEP، يتصل أحد النظيرين المُبادرين بالنظير المُستمع. ويرسل كل نظير ردًا يتضمن عنصر تحية. تحتوي التحية على ما يصل إلى ثلاثة عناصر مختلفة:

• الميزات : ميزة إدارة القناة الاختيارية، ورموز الميزات التي يدعمها الطرف الآخر.
• localize : علامات اللغة المفضلة الاختيارية للتقارير والرسائل.
• الملف الشخصي  : الملفات الشخصية المدعومة من قبل النظير.

مثال على التحية والرد:

L: <انتظر اتصالاً وارداً > I : <فتح اتصال > L: RPY 0 0 . 0 110 L: نوع المحتوى: تطبيق/بيب+xml L:  L: <greeting> L: <profile uri= 'http://iana.org/beep/TLS' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: نوع المحتوى: تطبيق/بيب+xml أنا:  أنا: <تحية /> أنا: نهاية 

تُحدد الملفات التعريفية بنية الرسائل ودلالاتها، بالإضافة إلى وظائف البروتوكول المستندة إلى بروتوكول BEEP. ويمكن لجلسة BEEP واحدة الوصول إلى عدة ملفات تعريفية. ولتحديد أي ملف تعريفي، يُخصص له مُعرّف فريد. ويتخذ هذا المُعرّف صيغة مُعرّف الموارد الموحد ( URI ) أو اسم الموارد الموحد ( URN ). في السابق، كانت صيغة URI تُسبب التباسًا نظرًا لتشابهها مع عنوان الويب. ولتجنب سوء الفهم، يُنصح باستخدام صيغة URN في الملفات التعريفية الأحدث .

مثال على مُعرّف الملف الشخصي:

تُبنى رسائل BEEP وفقًا لمعيار MIME . قد يحدث سوء فهم أحيانًا حول استخدام BEEP لـ XML في الرسائل، ولكن القناة 0 لا تستخدم سوى جزء صغير من XML، وهو أمر غير مرئي لمُصمم الملف التعريفي (مستخدم BEEP). يعود الأمر لمُصمم الملف التعريفي في تحديد تنسيق محتوى الرسالة ، والذي يمكن أن يكون أي تنسيق نصي مثل JSON أو XML، بالإضافة إلى البيانات الثنائية. يُستخدم XML في إدارة القناة وفي ملف تعريف TLS القياسي المُعرّف بواسطة BEEP.

مثال على تبادل رسائل إغلاق قناة ناجح من RFC3080.

ج: MSG 0 2 . 235 71 ج: نوع المحتوى: تطبيق/بيب+xml ج:  ج: <إغلاق رقم= '1' رمز= '200' /> ج: نهاية S: RPY 0 2 . 392 46 S: نوع المحتوى: تطبيق/بيب+xml S:  S: <موافق /> S: نهاية 

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

• الموقع الرسمي BEEPcore.org
• RFC 3080 : بروتوكول تبادل الكتل القابل للتوسيع الأساسي 
• RFC 3081 : ربط نواة BEEP ببروتوكول TCP 
• RFC 3117 : حول تصميم بروتوكولات التطبيقات ، اعتبارات تصميم بروتوكول BXXP كما رواها مبتكروه 
• RFC 3195 : التسليم الموثوق لسجل النظام - ملف تعريف BEEP 
• RFC 3529 : ملف تعريف XML-RPC لـ BEEP 
• RFC 4227 : استخدام SOAP في BEEP 
• RFC 3620 : ملف تعريف النفق 
• iana.org/assignments/beep-parameters سجل ملفات تعريف BEEP للمسار القياسي
• مقدمة عن برنامج BEEP على موقع IBM.com