الخلاصة

  • حدّدت RFC 1234 في 1991 تغليف IPX داخل UDP. وتسمح بأن يُنظر إلى IP internet باعتباره شبكة IPX واحدة؛ فعند معرفة المضيف، تمثل آخر أربعة octets من رقم مضيف IPX عنوان IP الخاص بالعقدة، فيصبح unicast مباشراً.
  • لا ينتشر broadcast بهذه البساطة. على كل server وrouter حفظ peer list يدوية، ثم إرسال حزمة unicast منفصلة إلى كل peer. تقول RFC إن المورد قد يكون مرئياً لنظام طرفي ومع ذلك يتعذر بلوغه إذا لم تكن broadcasts تصل عادةً إلى server peer group كاملاً.

«شبكة واحدة» كانت منظوراً محدداً لا حكماً شاملاً

كان سؤال RFC 1234 ضيقاً وواضحاً: كيف يمر IPX في شبكة لا تحمل إلا IP؟ يوفّر تغليف UDP هذا المرور. كما أن اصطلاح رقم المضيف يجعل حالة الوجهة المعروفة قابلة للقراءة: أول octets اثنين صفريان، والـoctets الأربعة الأخيرة هي عنوان IP للعقدة. عندما تكون الوجهة معروفة، لا يحتاج المرسل إلى آلية اكتشاف أخرى كي يحدد عنوان unicast.

لكن ذلك لا يحول الـIP internet إلى LAN مادي واحد، ولا إلى إدارة واحدة أو مجال ثقة واحد أو فضاء اكتشاف مكتمل تلقائياً. النص يقول إن التنفيذ يستطيع أن يراه شبكة IPX واحدة. ولا يقول إن هذا الوصف يحدد وحده من يجب أن يستقبل سؤالاً عن router أو service أو أن التسليم قد اكتمل إليهم.

احتاج IPX إلى broadcast لكي تعثر NetWare servers وIPX routers التي تتشارك شبكة على بعضها. إرسال حزمة إلى عنوان معلوم يختلف عن توجيه سؤال إلى كل المشاركين ذوي الصلة. العملية الثانية تتطلب تعريف مجموعة المستلمين ثم إنجاز إيصال فعلي إلى كل فرد فيها.

أصبح broadcast قائمة توزيع لها من يديرها

تقول RFC 1234 إن IP broadcast يغطي الـinternet كله ليس مناسباً ولا متاحاً. البديل ليس افتراضاً خفياً: يحتفظ كل server وrouter بقائمة IP peers مركبة يدوياً. وحين يطلب IPX broadcast، يرسل تنفيذ التغليف unicast منفصلاً إلى كل peer في القائمة.

وهكذا لا يعود نطاق السؤال صفة مفترضة لوسط مشترك. إنه يعتمد على القائمة، وعلى من يصونها، وعلى وصول كل نسخة. وتذكر RFC أن عدة peer groups يمكن أن تتشارك IP internet نفسه من دون أن تعرف إحداها الأخرى لأن القوائم تُنشأ باليد. وفي المجموعة الواحدة ينبغي أن تحتوي كل قائمة على جميع peers فيها.

لذلك لا يكفي وجود IP path بين موقعين لإثبات أنهما يشاركان الاكتشاف ذاته. ولا يكفي أن يسمح النفق بوصفهما ضمن شبكة IPX منطقية واحدة لإثبات أن السؤال بلغ كل server أو router لازم. اشتراك طبقة النقل واكتمال مدى الاكتشاف حقيقتان مختلفتان.

وكان على العميل أن يسأل المجموعة الصحيحة كلها

لا تقع هذه المسؤولية على servers وrouters وحدها. يحتاج client في شبكة IPX إلى broadcast لاكتشاف router يستطيع بلوغ وجهة مطلوبة. لذلك يضع RFC للعميل قائمة مهيأة بعناوين IP لكل servers وrouters في peer group، ويرسل العميل نسخة من الحزمة إلى كل عنوان فيها.

يعتمد النجاح على اكتمال في موضعين: قوائم servers وrouters، وتوجيه العميل بحثه إلى كل server peer groups ذات الصلة. نفق ينقل unicast معروفاً على نحو صحيح لا يضيف peer نُسي، ولا يصحح عنواناً قديماً، ولا يعيد تلقائياً نسخة ظلت لا تصل إلى جزء من المجموعة.

صياغة RFC شرطية، وليست تقريراً عن حادث بعينه. فإذا لم تكن الحزم تميل إلى بلوغ server peer group كله، فقد تظهر موارد IPX internet لنظام طرفي بينما تبقى غير قابلة للوصول منه. لا تسمي الوثيقة مورداً أو عيباً أو مشغلاً أو طوبولوجيا فعلية. لكنها تحدد الشرط الذي قد يفصل بين رؤية مورد والحصول على route صالح لاستعماله.

عنوان المضيف لا يجيب عن سؤال العضوية الجماعية

يكشف التصميم عن عدم تماثل. موضع host معروف يمكن اشتقاقه من تمثيل IPX نفسه. أما broadcast فيسأل: من يجب أن يسمع؟ الإجابة ليست في datagram، بل في قائمة قابلة للتغيير وفي قرار تشغيلي يحافظ عليها. لا تجعل RFC 1234 طوبولوجيا IP جواباً تلقائياً عن العضوية.

تذكر RFC أن IP multicast يمكن استخدامه لاحقاً، لكنها تسجل أن مرافق multicast لم تكن واسعة التوفر، ولا عنوان معروفاً لها ولا implementations تستعملها آنذاك. وهذه ليست زينة تاريخية فقط: استبدال القائمة بـmulticast أو سجل أو آلية جماعية أخرى لا يلغي واجب تعريف الأعضاء وإظهار فقدان التسليم وتمييز groups التي تتشارك النقل.

وتسجل الوثيقة شروطاً مادية أيضاً: default IPX MTU هو 576 bytes، ويصبح إجمالي IP بعد التغليف 604 bytes؛ وUDP checksum اختياري لكنه موصى به بقوة لأن IPX لا يستخدم checksum خاصاً به عادة. هذه شروط لعمل النفق، لا دليل على كمال peer list.

المصدر وحدود الدليل

مصدر هذا المقال المغلق هو RFC 1234، Tunneling IPX Traffic through IP Networks. وهو يدعم التاريخ، تغليف UDP، اصطلاح رقم المضيف، قوائم peers، اكتشاف العميل، النتيجة الشرطية الخاصة بالمرئي وغير القابل للوصول، MTU، checksum واعتبارات الأمان. ولا يثبت انتشار deployment محدد، أو عطلاً واقعياً، أو طوبولوجيا مؤسسة، أو استخداماً حالياً، أو حالة UDP port 213 اليوم.