الخلاصة

  • تضيف مسودة ECRIT استطلاعاً مرتباً للتغييرات المخطط لها، وعنصر asOf للتحقق في وقت مستقبلي، ونصيحة revalidateAfter لإعادة التحقق. وبذلك يستطيع العميل تحديد السجلات التي قد تتأثر وإعداد البدائل.
  • تنص المسودة على أن استعلامين بالقيمة المستقبلية نفسها قد يعيدان نتيجتين مختلفتين إذا أُرسلا في وقتين مختلفين. النتيجة هي تصور الخادم الحالي، وليست ضماناً للحالة المقبلة أو لتنفيذ العميل.
  • يقترح المقال إيصالاً من مرحلتين يفصل بين الإعداد وملاحظة التحول الفعلي. هذا اقتراح تحريري من Daniel Kade، وليس مطلباً من IETF ولا دليلاً على النشر التشغيلي.

المكان ثابت والوصف يعبر خطاً زمنياً

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

الإصدار 18 هو Internet-Draft نشط لدى مجموعة ECRIT. إنه عمل جارٍ، لا RFC نهائي، ولا يثبت تبنياً أو تطبيقاً أو حادثة حقيقية في خدمات الطوارئ.

يعرّف RFC 5222 بروتوكول LoST. يرسل العميل الموقع ومعرّف الخدمة، ويعيد الخادم عناوين الخدمة ومعلوماتها. ويمكن للعميل طلب التحقق من عناصر العنوان المدني أيضاً. ويوفر RFC 5139 صيغة الموقع المدني المستخدمة في المثال.

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

الفائدة هي الاستعداد. أما حد الدليل فهو أن تحقق اليوم من تاريخ الأسبوع المقبل لا يصبح ملاحظة من الأسبوع المقبل. إنه توقع مرتبط بوقت السؤال.

ثلاث ساعات لا تصنع حكماً واحداً

الساعة الأولى هي تسلسل الإشعارات. تقدم واجهة REST/JSON مستقلة معرفة الإصدار والاستطلاع وجلب ChangeSet. ويحمل كل ChangeSet معرّفاً مرتباً ووقت نفاذ ومواقع جزئية. يحتفظ العميل بآخر معرّف ويطلب ما يليه.

الساعة الثانية هي asOf. يحدد العميل تاريخاً ووقتاً في findService، فيجيب الخادم وفق ما يعرفه الآن عما يتوقع نفاذه بحلول ذلك الوقت. إذا لم يكن الوقت هو وقت الاستعلام، يجب أن يعيد الرد asOf وأن تحمل المطابقات حالة NO-CACHE.

الساعة الثالثة هي موعد المراجعة. يقترح revalidateAfter وقتاً قد يرغب العميل بعده في إعادة الفحص. وتعني NO-EXPIRATION أن الخادم لا يعرف حالياً تغييراً مخططاً يؤثر في النتيجة ولا يقترح موعداً، لا أن السجل صالح إلى الأبد.

يجيب الاستطلاع عن الجديد بعد موضع محفوظ. ويجيب asOf عن تصور اليوم للمستقبل. ويجيب revalidateAfter عن وقت السؤال التالي. لا يثبت أي منها أن القرار المدني نُفّذ، أو أن قاعدة العميل تحولت، أو أن خريطة الخدمة بقيت، أو أن اتصالاً وصل إلى جهة الاستجابة.

اختزال الساعات الثلاث في ضوء أخضر باسم «تم التحقق» يمنح الخادم سلطة لم يمارسها. فهو لم ير قاعدة العميل ولا لحظة تفعيلها.

الموقع الجزئي يختار مرشحين

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

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

يجب أن يحفظ العميل نسخة القاعدة وقاعدة المطابقة والمرشحين والاستبعادات والاستثناءات. العدد المجمل وحده لا يفسر لاحقاً هل اتسعت الحدود فعلاً، أم صُححت البيانات، أم تغير تفسير المخطط، أم أخطأ مرشح محلي.

تنسجم هذه القسمة مع مبدأ Lu Heng بشأن الحد الأدنى للمواصفة الأولية والقرار المستقبلي المحلي. توفر الطبقة المشتركة حقولاً صارمة للتشغيل المتبادل، وتبقى قرارات التفعيل مع من يشغّل النظام.

قابلية التصحيح جزء من صدق المستقبل

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

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

تجسد NO-CACHE هذا الحد تقنياً. كما تبقي المسودة استخدام LoST المعاصر عند الحاجة الفعلية إلى الاتصال بخدمة. التحقق المسبق يجهز سجل الموقع؛ ولا يحل محل اكتشاف الخدمة الجارية.

تغطي ولاية ECRIT آليات تستخدم الموقع والتوجيه لتمكين الاتصال بمركز الاستجابة المناسب، وتطلب حلاً يصلح عبر مناطق واختصاصات من دون سلطة مركزية واحدة. لذلك لا يجوز أن تصبح صحة العنوان دليلاً على نجاح الاتصال، ولا أن يصبح تصور خادم واحد دليلاً على عمل جميع العملاء.

انضباط Lu Heng في تقديم الواقع لا المناصرة يفرض إبقاء القيود في الجملة: أجاب هذا الخادم، في هذا الوقت، عن هذا التاريخ المستقبلي. أما «دخل حيز النفاذ» فتحتاج إلى إيصال لاحق.

التسلسل المرتب قد يبدأ بعد فجوة

تتوقع المسودة استطلاعاً كل بضع دقائق. يقدم العميل آخر ChangeSet ID، فيستلم اللاحق. والرد الخالي يعني فقط أن ذلك المعرّف هو الأحدث الذي يعرفه الخادم الآن.

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

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

ولا يثبت الرد الخالي أن العميل طبّق ما سبق أو أن تغييراً غير مخطط لم يحدث. إنه يثبت علاقة بين المعرّف المرسل وقائمة الخادم الحالية فقط.

يفصل The Policy Mirror لدى Lu Heng بين السجل والعرش. نحترم سجل الخادم في نطاقه، ولا نجعله شاهداً على تنفيذ محلي لم يره.

إيصال للإعداد وإيصال للنفاذ

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

أما إيصال النفاذ فيبدأ عند التنفيذ: الوقت الذي اعتمده المشغل، تعطيل السجلات القديمة، تفعيل الجديدة، تحقق معاصر، الفروق عن التوقع، الحالات المؤجلة أو الفاشلة، الرجوع، والجهة التي أغلقت العملية.

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

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

مدة إعادة التحقق توزع التكلفة

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

يعرف الخادم قدرته ومصادره، ويعرف العميل أثر البيانات القديمة. ينقل revalidateAfter نصيحة ولا يستولي على قرار المخاطر المحلي. يجوز مخالفتها مع حفظ صاحب القرار وسببه ونطاقه وموعد مراجعته.

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

ما يصل إليه الدليل

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

حتى معاً لا يثبتان صحة الفعل القانوني المدني، ولا تطابق كل خوادم LoST، ولا دوام خريطة الخدمة، ولا نجاح الاتصال من طرف إلى طرف. لكل طبقة شاهدها.

تغيّر السلطة المدنية الحدود. ويمثل الخادم البيانات. ويغيّر العميل قاعدته. ويعيد الاستعلام الحالي خدمة. ويحاول نظام الاتصال الوصول. الحوكمة الدقيقة لا تضغط هذه الأفعال في نتيجة واحدة؛ بل تحفظ لكل فعل دليله وصاحبه.

المصادر