لماذا توقفت سلسلة التأكيد عند الخطوة الثانية؟

الخلاصة

• يحتاج CCID 2 في DCCP إلى إيصال معلومات الاستقبال بصورة موثوقة، لكنه لا يتعهد بإعادة إرسال بيانات التطبيق الضائعة. موثوقية المعلومات الراجعة ليست موثوقية المحتوى نفسه.
• يتيح تأكيد تقرير الاستقبال للمستقبل تحرير سجلات قديمة. وإذا ضاع هذا التأكيد الثاني، يستمر الاحتفاظ بالمعلومات وتكرارها، فلا تنشأ ضرورة لتأكيد ثالث موثوق.
• انتقال البيانات من تبادل ثنائي الاتجاه إلى تدفق أحادي الاتجاه يغير طريقة أداء هذه المهمة. كما أن CCID 3 يحتفظ بحالة تأكيد محدودة عموما، فلا يحتاج إلى الآلية نفسها.

خسارتان لا تستلزمان العلاج نفسه

يشرح القسم 11.1 من RFC 4340 سبب الحاجة إلى تأكيد التأكيدات. عندما يستخدم المستقبل CCID 2، يرسل متجهات Ack Vector تتضمن معلومات عن الحزم التي وصلته. وما لم يعرف أن المرسل تلقى تلك المعلومات، فقد يواصل إعادة تاريخ يمتد إلى بداية الاتصال.

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

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

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

لماذا يحتفظ بروتوكول غير موثوق بكل هذه المعلومات؟

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

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

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

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

التقرير نفسه له رقم

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

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

أما Ack Vector فيبدأ من رقم التأكيد ويتجه إلى الحزم الأقدم. يخصص كل بايت بتين للحالة وستة لطول سلسلة من الحالة نفسها. تميز الحالات بين مستلم، ومستلم مع علامة ECN للازدحام، وقيمة محجوزة، ولم يُستلم بعد. قيمة الطول صفر تمثل حزمة واحدة، و63 تمثل 64 حزمة.

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

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

حين يصمت التطبيق في اتجاه واحد

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

لكن إذا توقف تطبيق B عن الإرسال واستمر في تلقي بيانات A، يظل B يرسل تقارير الاستقبال. وقد يواصل A إرسال DCCP-Data فقط، من دون إخبار B أي تقرير وصل. استمرار إرسال البيانات ليس دليلا على استلام تقرير بعينه.

لهذا يفرض RFC 4341 على المرسل النشط أن يؤكد أحيانا تأكيدات المستقبل، مثلا بإرسال DCCP-DataAck بدلا من DCCP-Data. ويوصي بأداء ذلك مرة على الأقل لكل نافذة ازدحام. ليس المطلوب حزمة مستقلة جديدة بعد كل تقرير.

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

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

الوقت وحده لا يثبت السكون

يستخدم CCID 2 مدة تساوي الأكبر بين 0.2 ثانية وضعف زمن الذهاب والإياب لتحديد السكون. لكن مرور هذه المدة بلا بيانات جديدة لا يكفي وحده.

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

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

لا تمحُ خبرا جديدا لأن خبرا قديما تأكد

يظهر في الملحق A.3 من RFC 4340 مثال تنفيذي غير ملزم يربط كل تقرير مرسل بتاريخ الاستقبال الذي يمثله. عندما يصل تأكيد التقرير، يمكن تحرير الجزء المناسب من السجل.

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

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

وتراعي قواعد دمج حالات Ack Vector وصول التقارير بترتيب مختلف عن ترتيب إرسالها. لا يصح أن تلغي رسالة قديمة تقول «لم يصل بعد» واقعة وصول أصبحت معروفة. حداثة وصول التقرير ليست ضمانا لحداثة كل ما يحمله.

حالة «مستلم» نفسها محدودة الدلالة: عالج DCCP الخيارات وأصبح بإمكانه تأكيد الحزمة، لكن التطبيق ربما لم يتلق البيانات أو أسقطها في مخزنه. يقدم Data Dropped معلومة إضافية، بدلا من وصف إسقاط محلي بأنه فقد على الشبكة. هذه الحدود ضرورية كي تبقى المعلومات صالحة للقرار الذي جُمعت من أجله.

ليس كل تاريخ بحاجة إلى المخرج نفسه

يعتمد CCID 3 في RFC 4342 على TFRC، سعيا إلى تغيرات أهدأ في معدل الإرسال مقابل استجابة أبطأ لتغير السعة المتاحة. ويشير RFC الأساسي إلى أن حالة تأكيداته محدودة عموما، لذلك لا يتطلب تأكيد التأكيدات بالطريقة نفسها. لا يعني ذلك غياب الحالة أو انعدام المعلومات الراجعة.

توضح التصحيحات المتحقق منها لـRFC 4342 أن معدل الاستقبال يتعلق بزمن الذهاب والإياب الأخير، لا بالفترة كلها منذ التقرير السابق. وفي الحالة المحددة التي لا توجد فيها بيانات ضمن الفترة المعنية، يمكن تجاهل خيار Receive Rate ثان، لكن لا يجوز عندئذ إعادة ضبط مؤقت غياب المعلومات الراجعة. مجرد وصول حزمة تحكم لا يجدد صلاحية كل الاستنتاجات.

وتصحح قائمة أخطاء RFC 4340 مثالا أخطأ في اعتبار الصفر قيمة غير صالحة لـAck Ratio، إلى جانب تفاصيل تحريرية في الملحق. وفي 2018 أزال RFC 8311 من ثلاثة ملفات DCCP النقاش المتعلق بـECN Nonce. ينبغي قراءة النص التاريخي مع هذه الحدود، لا تحويل كل جملة من 2006 إلى تعليمة تشغيل حالية.

أضاف RFC 6773 في 2012 تغليف UDP لمعالجة بعض قيود الأجهزة الوسيطة التي لا تدعم DCCP بصورته الأصلية. لم يضف ذلك ضمان تسليم بيانات التطبيق. كما أن سجل IANA يبين تخصيص المعرفات، ولا يقيس الانتشار الفعلي.

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