الخلاصة

  • صمّم مشروع Athena نظام Zephyr لإيصال إشعارات قصيرة وعاجلة عبر شبكة متنامية من محطات العمل، بعدما أخفق البث المحلي والبريد الإلكتروني كلٌ بطريقته.
  • كانت الهوية الموثقة ومكان الدخول وخيار إظهار الموقع واشتراك الموضوع وتسليم الرسالة حالات منفصلة؛ ولم تثبت أي منها التفرغ أو القراءة.

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

لذلك صُمّم Zephyr كطبقة نقل للإشعارات يمكن بناء خدمات اتصال أخرى فوقها. تشرح ورقة USENIX المنشورة عام 1988 طبقة النقل الأساسية، ثم طبقات الاشتراك وموقع المستخدم. وتعرض الخطة التقنية المؤرخة في 5 يونيو 1989 تركيباً عملياً: HostManager باسم zhm لكل محطة، وعميل WindowGram باسم zwgc لكل جلسة دخول، وعدة خوادم Zephyr للتسجيل والتوجيه وإدارة الحالة. فصل الإشعار بين ترويسة التوجيه وبيانات العميل؛ واستخدمت الخوادم الترويسة لتحديد المستلمين من دون تفسير نص الرسالة. أمكن لخادم ملفات أن يرسل إلى مستخدمين يعرفهم، فيما تنشر خدمة بلا جمهور محدد إشعاراً ضمن فئة ويشترك المهتمون فيها.

كان الاشتراك حالة صريحة، لا نداءً موجهاً إلى الحرم كله. احتفظ الخادم بتركيبة من الفئة والمثيل والمستلم. يطلب العميل الاشتراك، ثم تصله الإشعارات المطابقة. وتحدد أداة zwrite مستلماً بعينه. وفر Kerberos هويات رئيسية موثقة استُخدمت بوصفها Zephyr IDs، فاستطاع النظام التمييز بين حساب جرت مصادقته واسم كتبه أحدهم في متن الرسالة. غير أن المصادقة تجيب عن سؤال «أي هوية أرسلت الطلب؟»، ولا تجيب وحدها عن «هل يحق لهذا المرسل تحديد موقع أي مستلم أو مقاطعته؟». لذلك عولجت ضوابط الوصول ومستويات إظهار الموقع وإشعارات الطوارئ المخصصة كلٌ على حدة.

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

سردت خطة 1989 ستة مستويات لإظهار المستخدم: none وopstaff وrealm-visible وrealm-announced وnet-visible وnet-announced. لم يكن السماح بالاستعلام عن الموقع وإعلان الدخول والخروج مفتاحاً واحداً. كما فصل دليل المستخدم الصادر عن MIT عام 1993 بين الأمر hide وإيقاف Zephyr: إخفاء الموقع لم يمنع الآخرين من إرسال إشعارات. كان نطاق هذا التحكم أضيق من زر عام يقول «لا تتصلوا بي».

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

بحلول 1993، وصف دليل MIT رسائل Zephyr الفردية والجماعية بأنها من أدوات Athena المعتادة؛ وفي 1996 درست ورقة بحثية قناة Zephyr Help للمساعدة المتزامنة. وهذا دليل على الاستخدام داخل MIT، لا على أن Zephyr أصبح النموذج العالمي للمراسلة الفورية. وتكمن دلالة تاريخه في الحدود التي أبقاها منفصلة: تساعد الهوية على التوجيه، ويغذي تسجيل الدخول سجل الموقع، ويعبّر الاشتراك عن الاهتمام بفئة إشعارات؛ أما الإذن وإمكانية الوصول وانتباه الإنسان فأسئلة مستقلة.

المصادر