الخلاصة

  • كان متحكم MTP يعلن الرسالة مقبولة بعد رؤية data[eom] وكل الحزم الواقعة قبلها، ويترك الناقصة معلقة أو يرفضها بحسب تقديره لحالة المنتج.
  • انتقلت حالات المقبول والمعلق والمرفوض داخل متجه دوّار لآخر اثنتي عشرة رسالة، ولم يُسمح بدفع حالة معلقة خارج النافذة قبل حسمها.
  • نجاح المستهلك كان صامتاً عادة، والفقد وحده يولد NAK؛ لذلك كان القبول اتفاق نقل، لا إيصالاً إيجابياً من كل تطبيق ولا إثبات هوية أو تفويض أو نتيجة.

سلطة واحدة كتبت الحكم

نظّم RFC 1301 مجموعة العمليات المتعاونة في web. لا بد من متحكم واحد، وإلى جانبه منتجون/مستهلكون أو مستهلكون فقط. كان المتحكم يضبط العضوية ومعلمات الأداء ويمنح رموز الإرسال. لا يرسل المنتج بيانات العميل العادية حتى يحصل على رمز يحمل رقم الرسالة التالية.

بهذا المعنى كان ترتيب الكلام مركزياً. لكن الحكم لم يكن تصويتاً مركزياً جمع آراء الأعضاء؛ كان قرار المتحكم نفسه. سجل القبول في الحزم اللاحقة نشر ذلك القرار كي تتفق العمليات على ترتيب الرسائل وحالتها.

السلطة كانت حقيقية داخل البروتوكول ومحدودة بموضوعها. امتلك المتحكم حق تقرير حالة MTP، لا حق القول إن التطبيق أجاز المحتوى أو غيّر العالم الخارجي.

طبقة IP لم تعد بوصول الجميع

عرّف RFC 1112 multicast إلى مجموعة مضيفين ديناميكية، مع موثوقية أفضل جهد مثل IP العادي. لم يضمن وصول datagram سليمة إلى كل عضو، ولا ترتيبها بالنسبة إلى datagrams أخرى.

جاء MTP ليضيف ترتيباً وتعافياً فوق هذه الأرضية. عنوان المجموعة يوزع الحزمة؛ رمز الإرسال يحدد من يملك دور الإنتاج؛ متجه القبول يوزع قراراً عن الماضي. أما بيانات العميل فكانت octets غير مفسرة للبروتوكول.

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

الصمت وفّر الحركة ولم يصنع إيصالاً

اعتمد MTP الاعتراف السلبي. إذا وجد المستهلك فجوة أرسل NAK. وإذا لم يجد فجوة لم يرسل إقرار نجاح إلى المنتج. كان ذلك يقلل حركة العودة التي قد تنفجر مع كبر المجموعة.

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

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

القبول بدأ من اكتمال مرئي

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

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

ولا يعرف المتحكم معنى octets. رؤية النهاية وكل الوسط تثبت اكتمالاً على مستوى MTP فقط. صحة الأمر وملاءمته ونتيجته تبقى للتطبيق.

اثنتا عشرة خانة منعت نسيان المعلق

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

وضع RFC 1301 حاجزاً قبل سقوط المجهول. لم يجز للمتحكم أن يدفع حالة pending خارج آخر خانة. كان عليه أن يوقف تأكيد رموز إرسال جديدة حتى يحسم أقدم رسالة قبولاً أو رفضاً. صار الدين المعرفي ضغطاً يبطئ العمل ولا يسمح بإخفائه بالتقدم.

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

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

تكرار رمز الإرسال لم يثبت سبب الضياع

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

عالج البروتوكول الغموض بالفعل. إذا بقي الرمز معلقاً في رؤية المتحكم أمكن إسناده من جديد. وإذا تلقى المنتج تأكيداً مكرراً عامله مثل NAK وأعاد البيانات التي أرسلها تحت رقم الرسالة نفسه. وإذا لم يعد يحتاج إليه أعاده بواسطة empty[cancel].

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

retention رسم نهاية الإصلاح

حدد heartbeat إيقاع web، وحدد window عدد الحزم الجديدة والمعادة في كل نبضة، وحدد retention عدد النبضات التي يحتفظ المنتج خلالها بالبيانات وحالة التعافي.

عندما لا تتوافر بيانات تكفي لحزمة كاملة، مع بقاء الرسالة مفتوحة، أرسل المنتج empty[dally] للمحافظة على التزامن. وأضيفت حزم فارغة إلى الرسائل القصيرة حتى تبلغ على الأقل عدد retention، لزيادة احتمال أن يرى المستهلك حزمة ويحدد المنتج. الاحتمال الأعلى ليس ضماناً لكل مستهلك.

يكتشف المستهلك الفقد من قفزة في الأرقام أو جزء بلا نهاية يتبعه صمت يتجاوز heartbeat. يرسل NAK أحادي الوجهة يعدد المقاطع المفقودة. يعيد المنتج الحزم إلى web كله عبر multicast؛ تستهلك الإعادة window وتتقدم على البيانات الجديدة، وعلى الآخرين تجاهل النسخ المكررة.

إذا انتهت مدة الاحتفاظ، يرسل المنتج nak[deny]. يبلغ المستقبل عميله بالفشل وقد ينسحب. يستطيع البروتوكول إعلان انتهاء القدرة على الإصلاح، لكنه لا يستطيع خلق نتيجة تطبيق لم تُسجل.

عنوان النقل لم يكن اعتماد هوية

احتاج MTP فوق IP إلى Level 2 من RFC 1112 واستخدم المجموعة الدائمة 224.0.1.9. أضاف رأس bridge منافذ وطولاً وchecksum اختيارياً تحت رقم بروتوكول IP 92. ميزت TSAP ومعرفات الاتصال نسخ النقل.

لم تصادق هذه القيم العضو. قال RFC 1301 إن مسائل الأمن غير مناقشة. العضوية ورمز الإرسال ودور المتحكم أدلة تشغيل بروتوكولي، لا إثبات شخص أو مؤسسة أو حق إداري.

كشف RFC 1458 تكلفة المركز

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

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

المصادر

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