الخلاصة
- وضع RFC 1473 إعداد IP فوق PPP وحالته التشغيلية في جدولين منفصلين. كتابة open تُرسل حدثًا إداريًا إلى آلة حالات IPCP؛ ولا تثبت أن الآلة بلغت Opened.
- لا يصبح تفضيل الضغط الجديد نافذًا إلا عند إعادة تشغيل الوصلة التالية. وقبل اكتمال التفاوض تكون طريقة الضغط وأرقام الخانات المعادة غير معرّفة، وبعده تصف معلمات متفاوضًا عليها لا وصول حزمة IP.
نُشر RFC 1473 في يونيو/حزيران 1993 ليعرّف مجموعة IP في قاعدة إدارة PPP. لم يحاول واضعوه إحصاء كل ما يمكن رصده. اختاروا متغيرات لازمة لإدارة الأعطال أو الإعداد، وفضّلوا ما له منفعة آنية، واستبعدوا ما يمكن اشتقاقه من موضع آخر.
بهذا الاقتصاد رسم المستند ثلاث لحظات لا يجوز دمجها: ما طلبه المدير، وما أنجزه التفاوض، وما حدث لاحقًا لحزمة فعلية.
أمر الفتح دخل آلة حالات
احتوى جدول الإعداد القابل للكتابة على pppIpConfigAdminStatus. تمثل قيمته الحالة الإدارية المطلوبة فورًا لبروتوكول IP الشبكي. ضبطه على open يولّد حدث Open إداريًا لآلة حالات IPCP، وضبطه على close يولّد Close.
الحدث مدخل، لا نتيجة. قبول الوكيل للكتابة يثبت أن طلبًا صالحًا وصل إلى سطح الإدارة. لكنه لا يثبت توافر الطبقة السفلى، ولا رد النظير، ولا قبول الخيارات، ولا الانتقال اللاحق. قد تنجح معاملة الإدارة بينما يظل IPCP بعيدًا عن Opened.
حافظ RFC 1661 لاحقًا على هذا الفصل: لكل بروتوكول من طبقة الشبكة NCP خاص به، ويمكن فتح كل واحد أو إغلاقه بصورة مستقلة. تعثر IP فوق الوصلة لا يعني أن كل بروتوكول آخر فوق PPP اتخذ الحالة نفسها.
القيمة الجديدة كانت موعدًا للمستقبل
الكائن القابل للكتابة الآخر، pppIpConfigCompression، يختار ما سيحاول الطرف المحلي التفاوض عليه: بلا ضغط، أو ضغط رؤوس TCP/IP بطريقة Van Jacobson. وضع RFC 1473 حدًا زمنيًا واضحًا لهذه الكتابة: يسري التغيير عندما تُعاد الوصلة إلى العمل في المرة التالية.
إذًا لا تصف القيمة الجديدة الجلسة الجارية، ولا تأمرها بتغيير نفسها في مكانها. إنها تفضيل محفوظ لفرصة لاحقة. إثبات نفاذها يحتاج إلى إيصال الكتابة، وهوية إعادة التشغيل، ورسائل IPCP التي تلتها، والنتيجة التي انتهت إليها آلة الحالات.
يشرح RFC 1332 التفاوض الفعلي. الخيار IP-Compression-Protocol يبدأ افتراضيًا بلا ضغط، ويعلن قدرة الطرف على استقبال الحزم المضغوطة. ولكي يجري الضغط في الاتجاهين، يطلب كل طرف القدرة التي يريد استقبالها على حدة.
لذلك لا يساوي مربع اختيار واحد اتفاقًا ثنائي الاتجاه. قبول التفضيل محليًا لا يثبت حدوث إعادة التشغيل؛ وحدوثها لا يثبت أن النظير وافق؛ وموافقة اتجاه لا تحسم الاتجاه المقابل.
ما قبل Opened منطقة بلا معنى متفق عليه
أظهر جدول التشغيل pppIpOperStatus، وطريقة الضغط، وأقصى معرّف خانة لكل اتجاه. لكنه علّق سلطة تلك الأرقام على شرط: لا تتاح قيم الخيارات المتفاوض عليها إلا بعد اكتمال تفاوض PPP، وهو ما تشير إليه حالة IPCP المسماة Opened.
إذا لم تكن الحالة Opened، فالمحتوى غير معرّف ويترك RFC القيمة التي تعاد للتنفيذ.
«غير معرّف» أشد من «قديم على الأرجح». للقيمة القديمة حدث سابق كانت تصفه. أما الصفر أو الباقي أو القيمة الافتراضية قبل Opened فلا يحمل وعدًا دلاليًا بشأن هذه الجولة من التفاوض. قد ينجح طلب القراءة ويعيد عددًا صحيح النوع، من دون أن يصبح ذلك العدد حقيقة تشغيلية.
وبعد Opened لا يختفي الاتجاه. حقل local-to-remote يصف ما يستخدمه الكيان المحلي عند الإرسال، وحقل remote-to-local يصف المسار المعاكس. ولا يكون Max-Slot-Id ذا معنى إلا مع ضغط Van Jacobson؛ وإلا وجب أن يكون صفرًا. لا تُفسر الخانة إذًا من دون الحالة والبروتوكول والاتجاه معًا.
Opened شرط عبور لا إيصال استلام
اشترط RFC 1332 بلوغ PPP طور بروتوكول طبقة الشبكة وبلوغ IPCP حالة Opened قبل إمكان تبادل حزم IP. ونص RFC 1661 على إسقاط حزم بروتوكول الشبكة إذا وصلت قبل فتح NCP الموافق.
تغيّر Opened إذًا ما يسمح للوصلة بحمله. لكنه يظل واقعة تخص آلة الحالات: لا يحدد حزمة، ولا يثبت زيادة عدّاد، ولا يبرهن على نجاح فك الضغط أو وجود مسار أو وصول رد من التطبيق.
بيّن RFC 1144 لماذا يفيد ضغط رؤوس TCP/IP على الوصلات البطيئة، إذ يستبدل التكرار في الرؤوس بتمثيل موجز يعتمد على حالة الاتصال. غير أن القدرة المتفاوض عليها ليست حزمة مضغوطة؛ والحزمة ليست إعادة بناء صحيحة؛ وإعادة البناء ليست نتيجة مفيدة لدى التطبيق.
حدود الإدارة جزء من التصميم
فصل RFC 1473 الإعداد القابل للكتابة في جدول مستقل، بما يتيح وضعه في منظور إدارة محمي أو حجبه. وحذر قسم الأمن من مخاطر التحكم في إعداد PPP. في الأسرة نفسها تناول RFC 1471 LCP، وعزل RFC 1472 إعداد المصادقة. لم يوجد كائن واحد يدّعي أنه يلخص الوصلة كلها.
تحتاج الأتمتة الحديثة إلى سلسلة أدلة، لا لون أخضر: من طلب تغيير الضغط؛ وما الجيل الذي حفظه الوكيل؛ وأي إعادة تشغيل طبّقته؛ وما الذي اقترحه وقبله كل اتجاه؛ ومتى دخل IPCP إلى Opened وخرج منها؛ ثم أي حزم وأخطاء وإيصالات تطبيق ظهرت.
إذا حُفظ الرقم الأخير وحده، بدا التفضيل المنتظر كأنه نشط، وبدت القراءة غير المعرّفة كأنها قياس، وبدت Opened كأنها تسليم ناجح. إرث RFC 1473 هو أن الإدارة الصادقة تسجل متى لم تتكوّن الحقيقة بعد.
المصادر
- السجل الرسمي لـ RFC 1473 لدى RFC Editor
- RFC 1473 — كائنات إدارة بروتوكول IP الشبكي في PPP
- RFC 1332 — بروتوكول التحكم في IP ضمن PPP
- RFC 1144 — ضغط رؤوس TCP/IP للوصلات التسلسلية البطيئة
- RFC 1331 — بروتوكول Point-to-Point
- RFC 1661 — بروتوكول Point-to-Point
- RFC 1471 — كائنات إدارة بروتوكول التحكم في وصلة PPP
- RFC 1472 — كائنات إدارة بروتوكولات أمن PPP
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
