عرف الفهرس أن الكلمة موجودة، لكنه لم يعرف الإجابة

الخلاصة

• أتاح RFC 1913 لخوادم Whois++ تمرير «معرفة أمامية» مضغوطة: كلمات بلا تكرار تشير إلى خوادم أدنى قد تحمل تطابقاً. كانت هذه أداة لتوجيه الاستعلام، لا دليلاً على السجل.
• خففت مسارات الفهرسة المتعددة الاعتماد على هرم واحد، لكنها أنشأت رسماً شبكياً على العميل اجتيازه؛ وبقيت الحداثة والحلقات واستعادة العنوان والتوسع والكلفة مسؤوليات منفصلة.
• عُمّمت الفكرة عام 1999 في Common Indexing Protocol، بينما نُقل Whois++ إلى حالة Historic عام 2006 بعد مراجعة IETF وصفته بأنه بروتوكول عُرّف ولم يُستخدم.

اختصار مفيد لأنه لا يحتفظ بكل شيء

يعرض RFC 1913 مثالاً من ثلاثة سجلات: مستخدمان ونطاق. تحت كل قالب وسمة، يسجل centroid نسخة واحدة من كل كلمة ظهرت مرة واحدة على الأقل. تظهر «Smith» مرة واحدة سواء جاءت من سجل واحد أو ألف. الكلمات التي كانت ضمن قيمة واحدة تنفصل. ولا يبقى رقم السجل أو عدد التطابقات أو الترتيب أو السياق أو مصدر التحديث أو إثبات استمرار القيمة.

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

شبكة فوق السجلات

في أغسطس/آب 1995، أدخل RFC 1835، Architecture of the WHOIS++ service قوالب ذات أنواع وأزواج سمات وقيم منظمة بدلاً من السجلات النصية الفضفاضة. وفرّق بين خادم أساسي يحتفظ بالسجلات الكاملة وخادم فهرسة يحتفظ بالمعرفة الأمامية والمؤشرات. قد تؤدي آلة واحدة الدورين، لكن نوعي الدليل بقيا مختلفين.

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

في فبراير/شباط 1996، وضع RFC 1913، Architecture of the Whois++ Index Service شبكة فهرسة فوق البيانات. يستطيع خادم فهرسة جمع centroids من خوادم أساسية أو من فهارس أخرى، ثم إنشاء ملخصه. ويمكن للخادم أن يظهر تحت أكثر من أب وفي تسلسلات جغرافية وإدارية وطوبولوجية مختلفة. انفصل المعرّف الفريد للسجل عن الطريق الوحيد لاكتشافه.

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

للتغيير أكثر من ساعة

حدد RFC 1913 استعلامات POLL موثقة لطلب centroid كامل أو تغييرات قوالب وحقول معينة. وكان الخادم الأدنى يستطيع إرسال DATA-CHANGED ليعلن التغيير، ثم يقرر المتلقي هل يستطلع الحالة الجديدة ومتى.

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

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

ورث العميل تعقيد الرسم الشبكي

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

فصّل RFC 1914، How to Interact with a Whois++ Mesh، المنشور أيضاً في فبراير/شباط 1996، هذه العملية. يتصل العميل، يرسل السؤال، يتلقى سجلات وإحالات، يغلق الاتصال، ثم يختار الوجهة التالية. يحتفظ بمجموعة الخوادم المستعلَمة، ويمكنه توسيع البحث خارج نقطة البداية.

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

هوية مستقرة لا تعني موقعاً حياً

قد يكون اسم المضيف وعنوان IP والمنفذ داخل الإحالة مخزناً منذ استطلاع جرى قبل أسابيع. إذا فشل الاتصال، يستطيع العميل أخذ server handle المستقر إلى Directory of Servers وطلب أحدث وجهة معروفة.

فصل الهوية عن الموقع يسمح بنقل الخدمة من دون تحديث جميع النسخ فوراً. لكن «الأحدث المعروف» ليس «المتاح الآن». قد يفشل الاتصال الثاني أيضاً. فرّق RFC 1913 بين خادم لا يمكن الوصول إليه ومضيف يمكن الوصول إليه لكن خدمته لا تستجيب. يصلح المعرّف مؤشراً قديماً؛ ولا ينشئ عملية عاملة.

حدود الأمن ظاهرة كذلك. قال RFC 1913 إنه لا يناقش قضايا الأمن. واقترح RFC 1914 قوائم حظر لأن خوادم Whois++ مزيفة قد تظهر. لا يثبت ذلك وقوع هجوم. لكنه يبين أن اتباع كل إحالة عبور إلى نطاق إداري آخر وادعاء جديد بشأن البيانات.

خرجت الفكرة من منتجها الأول

في أغسطس/آب 1999، وصف RFC 2651، The Architecture of the Common Indexing Protocol بروتوكول CIP بأنه تطوير وصقل لأفكار الفهرسة الموزعة في Whois++. فصل تمرير الفهرس عن بروتوكول الوصول إلى الدليل، وعمم أنواع كائنات الفهرسة، ووصف محتواها بأنه تلميحات لتوجيه الاستعلام. ظل العميل يحتاج إلى بروتوكول وصول أصلي للحصول على النتيجة الفعلية.

قد تعيش الفكرة المعمارية بعد الخدمة التي قدمتها. ربط Whois++ الـcentroid بدليل قائم على القوالب؛ وحاول CIP الاحتفاظ بالآلية القابلة لإعادة الاستخدام: تبادل معرفة صغيرة بين الخوادم لتقريب الاستعلام من حامل البيانات المرجح.

في مارس/آذار 2006، وثّق RFC 4450، Getting Rid of the Cruft مراجعة محافظة لمعايير Proposed Standard قديمة. وُضعت RFCs 1835 و1913 و1914 ضمن ما سينتقل إلى Historic، وذُكر Whois++ بين البروتوكولات التي عُرّفت ولم تُستخدم. لا يمحو ذلك التجارب أو البرمجيات — يذكر RFC 2651 برنامج Digger — بل يسجل حكم IETF بأن النصوص لم تعد تمثل ممارسة راهنة تستحق بقاءها Proposed Standard.

ليست القصة انتصار المركزية على اللامركزية. عالجت الشبكة مشكلة اكتشاف حقيقية واستمر تجريدها. ما بقي هو كلفة كل انتقال من التلميح إلى الحقيقة.

المصادر

• رُبطت RFC 1835 وRFC 1913 وRFC 1914 وRFC 2651 وRFC 4450 مرة واحدة لكل منها في التحليل.