الخلاصة

  • تناول RFC 1693 التجريبي الصادر في نوفمبر 1994 خدمة نقل ذات ترتيب وموثوقية جزئيين. في مثال مفترض لأربعة سجلات، سمحت شروط الاستعلام بترتيب واحد أو اثنين أو أربعة أو 4! = 24 ترتيباً.
  • أعلنت ملاحظة IESG في صدر الوثيقة عدم التوصية بتنفيذ تعديلات TCP المقترحة، مع تقدير تحليل البيانات التي تصل مختلة الترتيب أو ناقصة خارج TCP.

موظف يحمل الملف ويرفض تسليمه

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

صاغ T. Connolly وP. Amer وP. Conrad المسألة بأربع بطاقات من قاعدة بيانات افتراضية. الترتيب بأسماء أربعة بائعين مختلفة يسمح بتسلسل واحد. ترتيب المواقع، مع سجلين من المدينة نفسها، يسمح بتسلسلين. ترتيب الأوصاف المشتركة بين زوجين يسمح بأربعة. ومن دون ORDER BY تصح كل تبديلات السجلات الأربعة: 24. هذه أعداد التباديل داخل المثال، وليست قياسات سرعة أو نتائج تشغيل على شبكة عامة. الذي تغير هو شرط الاستعلام على أسبقية كل سجل.

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

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

درس المؤلفون اتصالاً بترتيب جزئي داخل TCP معدّل، وبداية اتصال تميز الطرف العادي. كما حللوا احتمال تسليم عنصر مستقل مبكراً بدلاً من احتجازه وراء جزء مفقود. لا تعني الأرقام 1 و2 و4 و24 أن الأداء تحسن بهذه النسب؛ إنها عدد ترتيبات نتيجة مفترضة. ولم تتحول الفكرة في هذه الوثيقة إلى تعديل معتمد في TCP.

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