الخلاصة

  • مجموعة Complete، وهي تصنيف اختياري للحالات، تضم العمليات الناجحة وطلبات processed التي لن تتلقى تحديثات أخرى. الانضمام إليها ليس إثباتًا لنجاح جميع الأعمال.
  • الحالة الفردية complete تتطلب نجاح الأعمال المعنية، بما فيها شبكات CDN التالية المتأثرة في سلسلة التفويض. لا يجوز للوسيط ترقية processed لدى شبكة تالية إلى نجاح مؤكد.
  • وقت الإكمال المتوقع يساعد على التخطيط ولا يشهد على تحقق النتيجة. هذه الواجهة لا تشترط مزامنة الساعات بين شبكات CDN المترابطة.
  • إبطال صلاحية النسخة، وحذفها، وجلبها مقدمًا، وإلغاء الطلب، وحذف تقريره عمليات مختلفة. على القرار اللاحق تحديد النتيجة التي يعتمد عليها فعلًا.
  • سيناريو الاستبدال الآتي تحليل لمعاني المواصفة، لا وصف لحادثة مقاسة أو خلل لدى مزود مسمى أو انتشار شامل للتنفيذ.

تقرير انتهى، وشرط لم يُثبت

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

يقبل الشريك الطلب. ثم يظهر مورد الحالة في مجموعة Complete بدلًا من الأعمال الجاري تتبعها. تبدو لوحة المتابعة مرتبة، وقد يظن المسؤول أن الوقت مناسب لبدء الجلب التالي.

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

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

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

اسم واحد لنوعين من الانتهاء

نُشرت RFC 8007 في ديسمبر 2016 ضمن مسار معايير IETF، ويصفها سجل RFC Editor بأنها معيار مقترح. تحدد جزء المشغلات من واجهة التحكم في ترابط شبكات توزيع المحتوى.

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

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

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

الحالة الفردية complete تعني اكتمال الطلب بنجاح. أما processed فتعني قبوله مع توقف التحديثات المستقبلية، بما في ذلك عندما يتعذر تأكيد الإكمال. لا يختفي هذا الاختلاف عندما يندرج الموردان في المجموعة نفسها.

ليست processed فشلًا دائمًا. وليست نجاحًا دائمًا، أو دليلًا على أن العمل لم يبدأ، أو أنه توقف، أو أنه لن ينتج أثرًا لاحقًا. ما تقوله مباشرة هو حد الإبلاغ المتاح.

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

القبول ينشئ مرجعًا للاستعلام

حين تقبل الشبكة المتلقية طلب تشغيل، تنشئ مورد حالة وتعيد موقعه مع HTTP 201. يحصل الطالب على مرجع يمكن الرجوع إليه. لا تجعل هذه الاستجابة العمل المطلوب حقيقة منجزة.

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

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

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

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

السلسلة لا تصنع تأكيدًا لم يأتِ

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

تحظر RFC 8007 الإبلاغ عن complete قبل أن يكون الطلب complete في كل شبكات CDN التالية المعنية. وإذا أبلغت إحداها عن processed، فعلى الوسطاء أيضًا الإبلاغ عن processed، لا تحسين غياب التأكيد إلى نجاح مثبت.

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

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

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

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

كانت متطلبات CDNI في RFC 7337، وهي وثيقة معلوماتية، قد طلبت إبلاغًا مناسبًا عن الإكمال والنجاح أو الفشل، بما يشمل الشبكات المتسلسلة. وتحدد واجهة المشغلات أيضًا كيفية التعبير عن محدودية المتابعة بدل إخفائها.

نجاح الإبطال ليس نجاح الحذف

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

يحافظ تسجيل IANA الحالي على هذا التفريق. فالشرط المتعلق بإعادة الاستخدام ليس الحدث المادي نفسه الذي يزيل البيانات من التخزين.

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

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

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

ترتيب الإرسال لا يتحكم في ترتيب التنفيذ

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

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

لهذا توصي RFC 8007 بإكمال الحذف أو الإبطال قبل بدء جلب البديل في العناوين نفسها. إذا تداخل العملان، فقد تُجلب المادة الجديدة ثم يؤثر فيها الطلب السابق الذي لم ينتهِ.

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

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

على مسؤول الاستبدال تحديد شرطه: هل يحتاج إلى نجاح مؤكد في نطاق معين؟ هل يقبل تقديرًا وحدوده بموجب اتفاق محلي؟ أم إن عمله التالي مستقل عن الهدف غير المؤكد؟ اسم Complete لا يختار الإجابة.

الوقت المتوقع لا يتحول إلى شهادة

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

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

يمكن للطرفين الاتفاق محليًا على تفسير أسس الوقت وعدم اليقين. لا يغير هذا الاتفاق معنى processed، وحتى لو كانت الساعات متوافقة تمامًا يبقى التقدير توقعًا، لا نتيجة مستلمة.

تخفف طلبات HTTP الشرطية كلفة المراقبة. توصي RFC 8007 باستخدام ETag للموارد والمجموعات. وتوضح دلالات HTTP وقواعد التخزين المؤقت عمل هذه الأدوات.

قد تؤكد استجابة 304 لمورد processed لم يتغير أن تمثيله بقي كما هو. لا تعوض نتيجة لم تعد الجهة تعد بتحديثها. تسريع الاستعلام لا يزيد قدرة الطرف الآخر على تأكيد الإكمال.

الإلغاء لا يعيد الأثر إلى الوراء

الخدمة ملزمة بالرد المناسب على أمر الإلغاء، لكن تنفيذ الإلغاء فعليًا قدرة اختيارية. يمكن للرد أن يميز عملًا غير نشط، أو قبولًا مع استمرار النشاط، أو عدم تنفيذ وظيفة الإلغاء.

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

تحتاج قيم الاتصال نفسها إلى دقة. يصحح التصحيح التقني الذي تم التحقق منه 5053 السلسلتين إلى cancelling وcancelled؛ ويصحح 5054 قيمة ecancelled. ويوضح التصحيح التحريري 5064 مثال إلغاء منفصلًا عن حذف المورد. الشرح العربي الطبيعي لا يجيز تغيير تهجئة القيم البروتوكولية.

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

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

قناة آمنة تحمل أحيانًا جوابًا محدودًا

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

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

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

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

المصادر

تستند الفروق الدلالية إلى الوثائق الأولية. مقترحات القرار تحليل للكاتب، وليست متطلبات معيارية مستحدثة.