الخلاصة

  • أتاح Header-Last للمرسل أن يرى الحجم بعد الضغط قبل أن يقرر هل تبدأ حزمة SDTP إطاراً تسلسلياً أم تتابعه أم تنهيه.
  • بتّا التقسيم في RFC 1963 هما B وF؛ أما E فيعلن امتداد ترويسة CS، ولا يحتوي SDTP على حقل تسلسل. تنتمي B/E مع رقم تسلسل إلى PPP Multilink في RFC 1990.
  • يفصل Length حزم SDTP داخل إطار PPP مركّب ويختار Port قناة متفقاً عليها، لكن أياً منهما لا يثبت غياب الفقد أو هوية المنفذ المادي أو تعافي خدمة المستخدم.

تبدأ الترويسة عادةً قبل البيانات لأنها تخبر المحلل كيف يقرأ البايتات التالية. خالف RFC 1963، المنشور بصفة Informational في أغسطس 1996، هذه العادة عن قصد. ففي الصيغة الافتراضية لبروتوكول Serial Data Transport Protocol تأتي البيانات المنقولة أولاً، ثم ترويسة Terminal Adaptation في آخر الحزمة، وتنعكس أيضاً مرتبة ثمانيات الترويسة. وهكذا يقرأ المستقبل البنية من طرفين.

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

لذلك كان Header-Last الصيغة الافتراضية. ويمكن التفاوض على Header-First عندما لا تُقسم الإطارات، أو لا يرتبط الضغط بـSDTP، أو يفضّل مسار العتاد الترتيب المعتاد. يحدد التفاوض طريقة مشتركة لقراءة البايتات، لكنه لا يقيس نسبة الضغط ولا يثبت تزامن الضاغط أو نجاح إعادة البناء.

قبل إرسال البيانات يجب أن يبلغ PPP مرحلة Network-Layer Protocol وأن يصل SDCP إلى حالة Opened. يسجل IANA القيمة 0x0049 لـPPP-SDTP و0x8049 لـPPP-SDCP. تثبت القيم والحالة أن الطرفين اتفقا على نحو معين، لكنها لا تصادق على اكتمال حزمة لاحقة أو فائدتها.

في الوضع الأساسي يحتوي حقل Information واحد في PPP على حزمة SDTP واحدة. لا يظهر Length إلا إذا تم التفاوض على Length-Field-Present وعلى خيار LCP Compound-Frames الوارد في RFC 1570 معاً. حينها يمكن أن تتشارك عدة حزم SDTP حاوية PPP واحدة. يشمل كل Length حقله نفسه وPort الاختياري وترويسة التكييف والبيانات وأي Odd-Pad. تمثل ثمانية واحدة مجموعاً من 2 إلى 255، وتمتد ثمانيتان إلى 65535، وتعني القيمة صفر بقية حقل Information كلها.

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

يضيف Multi-Port فضاء أسماء متفقاً عليه. من دونه تُنسب البيانات كلها إلى Port 0 ضمناً ولا تنتقل ثمانية Port. بعد التفاوض تحمل كل حزمة رقماً: من 0 إلى 254 للبيانات، و255 للتحكم. تطبق بعض الإعدادات على منفذ بعينه، بينما قد يؤثر التحكم في التدفق على Port 255 في جميع المنافذ.

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

تحدد B وF حدود الإطار التسلسلي. في النمط المتزامن الشبيه بـHDLC تشير B إلى البداية وتشير F إلى الجزء النهائي؛ غيابهما يعني جزءاً وسطياً، واجتماعهما يعني إطاراً كاملاً في حزمة واحدة. وفي النمط غير المتزامن يجب ضبطهما معاً. أما E فله وظيفة أخرى: الإعلان عن امتداد ترويسة CS الاختياري. إنه ليس بتّ نهاية.

تصحح هذه النقطة خلطاً بين وثيقتين. يستخدم RFC 1990 الخاص بـPPP Multilink البتين B/E ورقم تسلسل من 12 أو 24 بتاً عبر حزمة من الوصلات. لا يفعل RFC 1963 ذلك. لا يوجد حقل sequence في SDTP، ولذلك لا توجد فيه قاعدة Multilink لاستنتاج جزء مفقود من تقدم عداد.

تتطلب الوثيقة نفسها قراءة النص مع الجدول. يطبع جدول B/F القيمة 1,0 لكل من Begin Frame وFinal Frame، مع أن الجملة السابقة مباشرةً تعرف F بوصفه علامة الجزء النهائي. تدعم التعريفات المحيطة معنى B/F. لكنها لا تخبرنا كيف تعامل تنفيذ معين مع السطر المكرر. يحتاج ذلك إلى شيفرة أو اختبارات أو أثر حزم، وهي أدلة غير متاحة في المصادر هنا.

تظهر حدود الإثبات بوضوح أكبر في FCS الداخلي. ينقل SDTP، في الإطار الشبيه بـHDLC، البايتات الواقعة بين Flags ولا ينقل Flags نفسها. وينتقل FCS الداخلي افتراضياً. قد يسمح خيار FCS-Type بحذفه عند المرسل وإعادة توليده عند المستقبل. لكن RFC 1963 حذّر من ذلك ما لم يوفّر PPP Reliable Transmission أو مستوى آخر إشعاراً موثوقاً بفقد الحزمة. كما منع تسليم إطار ناقص أو سيئ للمستخدم مع FCS جديد صحيح.

تكشف هذه القاعدة ما لا تعرفه B/F وLength وPort. فهي تصف الشكل والامتداد والوجهة المتفق عليها، ولا تبلغ عن الفقد. إذا اختفت حزمة وسطية ولم يخبر المستوى الأدنى بذلك، فقد يرى المستقبل مادة ذات حدود مقنعة. عندئذ يحوّل حساب checksum جديد الغياب إلى مظهر سلامة زائف.

يعالج RFC 1663 مشكلة أخرى بواسطة Numbered-Mode والنوافذ والإقرارات وإعادة الإرسال المتفاوض عليها بصورة مستقلة. ويعالج RFC 1962 التفاوض على خوارزميات الضغط وتبادل Reset. لا ينبغي نقل وظائفهما خفيةً إلى حقول SDTP. نسّق Header-Last توقيت قرار التقسيم مع الضغط، لكنه ليس الضاغط ولا آلية موثوقية.

يُظهر التمييز الذي يضعه Lu Heng بين البنية المعلنة والدليل القابل للتنفيذ قيمة هذا التصميم وحدوده. أعلن RFC 1963 حداً أدنى مشتركاً: مواضع الحقول والامتداد والحدود والطول وتسميات المنافذ. بقي على النظام العامل أن يثبت ترتيب الوصول ومعالجة الفقد وسياسة المخزن وربط المنافذ محلياً ومعالجة FCS والتسليم إلى التطبيق. جعلت المواصفة الأسئلة قابلة للتدقيق، ولم تدّع الإجابة عنها نيابةً عن الآلات.

المصادر