الخلاصة

  • وصف RFC 1207 جهازَي Sun 3/60 مرتبطين عبر منفذَي ttya باستخدام SLIP. نجح ping وrlogin، لكن وصل NFS انتهى برسالة server not responding: RPC Timed Out. ربط الجواب المشكلة بتعطيل المجموع الاختباري لـ UDP في SunOS 3.5 وبغياب مجموع اختباري يوفره SLIP نفسه.
  • في القسم ذاته، أوضح الجواب أن SLIP ضمن SCO TCP/IP لنظام Xenix يعمل مع مشغلات المنافذ التسلسلية من SCO فقط. اللوحة الذكية متعددة المنافذ ذات المشغّل الخاص بها لا تحقق هذا الشرط، مهما بلغ عدد منافذها.

اختباران ناجحان أمام مهمة واحدة فاشلة

بدأت الحالة بما يحب مسؤول الشبكة رؤيته. جهازا Sun 3/60 موصولان من منفذَي ttya، وSLIP ينقل الحزم. ردّ ping، وفتح rlogin جلسة على الجهاز الآخر. عند محاولة وصل نظام ملفات NFS، ظهرت رسالة تفيد بأن الخادم لا يرد وانتهت مهلة RPC. لو توقف الفحص عند الخطوتين الأوليين، لأُغلق بلاغ الشبكة قبل تجربة الخدمة التي أرادها المستخدم.

ظهرت المسألة في RFC 1207، وهو تجميع لأسئلة المستخدمين المتمرسين أعدّه G. Malkin وA. Marine وJ. Reynolds في فبراير 1991. راقب المحررون قوائم بريدية واسعة، وانتقوا الأسئلة المتكررة، وصاغوا مرجعاً لفرق التشغيل، ولا سيما في الشبكات التي كانت تنضم إلى الإنترنت. أرادوا أيضاً إعفاء المشتركين من قراءة الشرح نفسه مراراً. هذه الحالة تصلح تماماً لذلك: كلمة «متصل» تبدو جواباً جيداً حتى يحاول شخص فتح ملف.

حدد الجواب موضعاً تقنياً بعينه. قال إن SunOS 3.5 يعطّل المجموع الاختباري لـ UDP. على إيثرنت قد يعمل هذا الترتيب لأن طبقة الوصلة تقدم فحصاً للبيانات. أما SLIP فلا يقدم مجموعاً اختبارياً خاصاً به. لذلك طلب الجواب تشغيل مجموع UDP عند استخدام NFS على تلك الوصلة. وذكر أمراً تاريخياً بواسطة adb لتغيير متغير النواة udpcksum، مع حفظ النواة القديمة أولاً.

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

لوحة أغلى، منفذ غير قابل للاستخدام

يحمل القسم 8.3 عائقاً آخر في نقطة مختلفة من السلسلة. أراد مستخدم Xenix تشغيل SLIP عبر لوحة تسلسلية متعددة المنافذ. أجاب النص بأن SCO TCP/IP لنظام Xenix يدعم SLIP، لكنه يعمل مع مشغلات SCO التسلسلية وحدها. اللوحات الذكية التي تأتي بمشغلات خاصة بها لا تعمل مع ذلك التنفيذ. من يحتاج إلى منافذ كثيرة فليستخدم منافذ بسيطة متعددة، وربما لوحة متعددة المنافذ من النوع البسيط.

تبدو اللوحة الأكثر قدرة خياراً بديهياً قبل قراءة هذا الشرط. لكن عدد الموصلات لا يقول شيئاً عن قدرة نظام التشغيل على قيادة اللوحة عبر المشغّل الذي يتوقعه. يمكن للمشتري أن يجد عبارة «يدعم SLIP» في وصف البرنامج، و«منافذ عديدة» في وصف العتاد، ثم يكتشف أن العقدة الفاصلة بينهما مفقودة. السؤال العملي هو أي مشغّل حُمّل فعلاً، وأي مشغّل يقبله تنفيذ SCO.

في بداية الفصل صحح الدليل التباساً آخر: ظن سائل أن SLIP مخصص للخطوط التسلسلية المتزامنة، فأجاب النص بأنه صُمم للخطوط غير المتزامنة، بينما يصلح PPP للنوعين. نوع الخط، والمشغّل، وفحص البيانات، والخدمة المطلوبة: كل واحد منها امتحان مستقل. لم يكن عطل لوحة Xenix هو عطل NFS على SunOS؛ جمعهما الفصل لأن التشغيل الحقيقي يحتاج إلى أكثر من اسم بروتوكول على العلبة.

وصفة النواة ليست محضر إصلاح

إن نشر أمر adb بدقة يبيّن مكان مفتاح التحكم الذي رآه أصحاب الجواب. لكنه لا يقدم سجلاً لحزم ما قبل التعديل وما بعده، ولا قيمة الإعداد المقروءة بعد التنفيذ، ولا نتيجة وصل NFS ثانية. ستثبت هذه السجلات إن كان التشخيص قد أصلح تلك الأجهزة تحديداً. ما سجله السؤال هو نجاح الاختبارين الأولين وفشل عملية الملفات، ثم توصية تقنية للمعالجة.

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

المصدر