عدد لا تمنحه جهة مركزية: كيف اختبر PPP رجوع رسالته

الخلاصة

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

ما الذي كان السجل يسجله فعلاً؟

تسجل IANA في معلمات PPP الخيار Magic-Number بالرقم 5. يسهل أن يبدو ذلك كأن الرقم المسجل هو هوية ما، لكنه ليس كذلك. الرقم 5 يحدد نوع خيار يفهمه الطرفان، أما العدد الذي يحمله الخيار فيختاره كل طرف بنفسه.

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

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

فالعدد ليس مفيداً لمجرد أنه موجود في حقل صحيح. يجب معرفة من أرسله، وفي أي رسالة، وبالمقارنة مع أي حالة سابقة.

حين تصل البيانات ولا يكون أحد قد أجاب

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

ليس ضرورياً أن تتلف البتات في الطريق. يحدد RFC 1662، الصادر في يوليو 1994، تأطيراً شبيهاً بـ HDLC لـ PPP، مع تسلسل تحقق FCS من بايتين افتراضياً وبديل من أربعة بايتات. يغطي حسابه حقولاً محددة من الإطار.

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

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

حقل سبق اكتمال طريقته

في نوفمبر 1989، عرض RFC 1134 PPP بوصفه تغليفاً للبيانات، وبروتوكول تحكم قابل للتوسعة هو LCP، وعائلة NCP لتهيئة بروتوكولات طبقة الشبكة. كان إعداد الوصلة وفحصها يسبقان تهيئة ما سينقل عبرها من بروتوكولات شبكة.

كانت صيغتا Echo وDiscard تتضمنان بالفعل أربعة بايتات لـ Magic-Number. ما لم يغير خيار إعداد هذا السلوك، تُرسل القيمة صفراً وتُهمل عند الاستقبال. أما استعمالها الأوسع فكان خارج الشرح في ذلك الموضع.

جاء RFC 1172 في يوليو 1990 ليشرح الخيارات الأولية، ومنها المقارنة بين العددين، وإعادة الاختيار عند التصادم، وأهمية مصادر التميز والعشوائية، والالتزام المتبادل بين الطرفين. وأبقى RFC 1331، الصادر في مايو 1992، على الآلية.

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

العدد المتساوي يحتمل تفسيرين

قبل اقتراح الخيار، يختار التنفيذ عدده. وعندما تصل رسالة Configure-Request تحتوي Magic-Number، تقارن قيمتها بقيمة آخر Configure-Request أرسله الجهاز محلياً.

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

لا يحول البروتوكول أول تطابق إلى يقين. يرسل الجهاز Configure-Nak يقترح فيه عدداً آخر. ولا يضيف فوراً Configure-Request جديداً خارج سير المعالجة المعتاد؛ يأتي الطلب التالي عند سببه الطبيعي، مثل استقبال Nak أو انقضاء مؤقت إعادة المحاولة.

ثم تبدأ مقارنة ذات مرجع آخر. قيمة Nak المستقبلة تقارن بقيمة آخر Nak أرسله الجهاز، لا بأي عدد قديم في السجل. استمرار التطابق يزيد احتمال الرجوع ويتطلب اختيار قيمة جديدة. أما الاختلاف فيظهر، ضمن السلوك الموصوف، اختياراً مستقلاً. ويُفترض أن يحمل Configure-Request التالي القيمة الجديدة.

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

الرد الصحيح قد يعيد العدد نفسه

هناك حالة لا يكون فيها رجوع العدد المحلي مثيراً للشك أصلاً. يجب أن يعيد Configure-Ack الصحيح خيارات الطلب كما هي، بلا تعديل في القيم أو الترتيب، ومع Identifier المطابق.

لذلك يكون العدد المحلي داخل Ack صحيح أمراً متوقعاً. لكنه، داخل Configure-Request جديد من الطرف المفترض، يقدم على أنه اختيار ذلك الطرف. نوع الرسالة يغير معنى البايتات نفسها.

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

ويظهر فصل مشابه في Echo. تنسخ Echo-Reply قيمة Identifier من الطلب لربط الرد به، لكنها تستخدم Magic-Number الخاص بمرسل الرد بعد تفاوض ناجح. ربط الطلب بالرد ليس هو نفسه تمييز الحالة المحلية للمرسل. كلمة «صدى» لا تعني أن جميع الحقول نسخة مطابقة.

الاستقلال ليس صفة يمنحها اسم «عشوائي»

تعرض النصوص التاريخية نموذجاً مثالياً للاختيار المنتظم على 32 بت، باحتمال يقارب 2.3 × 10^-10 لتصادم واحد. هذا تفسير لفكرة التصميم، وليس قياساً لمعدل الإنذارات الخاطئة في أجهزة حقيقية.

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

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

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

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

رفض يكشف سلوكاً آخر

من يعرض Magic-Number لا يجوز له رفض الخيار نفسه إذا عرضه الطرف الآخر. الالتزام متبادل، وله أثر يتجاوز عدالة التفاوض.

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

يوجه RFC 1661 إلى المتابعة كما لو أن التفاوض نجح، مع إدراك أن الطرف المقابل لن يستخدم Magic-Numbers. لا تعني هذه المعاملة أن الجهتين تفاوضتا على قدرة متطابقة. إنها تحافظ على فائدة محدودة للرفض من دون اختراع قبول لم يحدث.

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

للصفر موضع مشروع وآخر غير مشروع

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

أما اقتراح الصفر داخل خيار Magic-Number فهو غير قانوني، ويجب الرد عليه بـ Nak ما لم يُرفض الخيار. لا يوجد تناقض: أحد الصفرين يصف غياب حالة متفاوض عليها، والآخر يحاول أن يصبح قيمة تلك الحالة.

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

تظل حالة LCP قيداً مهماً. لا تُرسل Echo-Request وEcho-Reply إلا في Opened، ويلزم الرد على الطلب الذي يصل في تلك الحالة. وما يصل خارجها ينبغي إسقاطه بصمت. أما Discard-Request فوظيفته التخلص من البيانات ولا يستدعي رداً.

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

التوثيق يحتاج إلى شيء غير عدد مرئي

يفصل سجل IANA بين Magic-Number والخيار Authentication-Protocol ذي النوع 3. ليست هذه مجرد تسمية تنظيمية؛ إنها تفصل مهمتين مختلفتين.

يصف RFC 1994، الصادر في أغسطس 1996، CHAP باستخدام تحدٍّ ورد محسوب يعتمد على سر مشترك. المقارنة هنا تاريخية لتوضيح اختلاف الدليل، وليست توصية باستعمال خوارزمية قديمة اليوم.

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

بعد التعرف على الخلل يبقى القرار

لا يفرض RFC 1661 مسار استعادة وحيداً. يذكر، مثلاً، التعامل مع الوصلة كأنها Down ثم إعادة فتحها، أو مراقبة انتهاء الرجوع برسائل Echo في الحالة المناسبة. تظل الإجراءات التفصيلية من شأن التنفيذ.

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

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