الخلاصة

  • عرّفت RFC 818 خدمة Remote User Telnet اختيارية على المنفذ 107. كان التطبيق الذي يصل إليه المتصل قادراً على بدء اتصال Telnet آخر، بدلاً من أن يضعه في بيئة تنفيذ عامة على المضيف.
  • في TC68K من BBN أنهى Server Telnet الاتصال الوارد، ووصلت طرفية زائفة تدفقه ببرنامج User Telnet صادر. بدت الشاشة واحدة للمشغل، لكن التنفيذ احتوى اتصالين عبر TCP ونقطتي Telnet وحدود سلطة محلية متعددة.
  • دل نجاح الاختبار على عمل السلسلة التي لوحظت في تلك اللحظة. حدد رقم المنفذ موضع القدرة، لكنه لم يثبت هوية المشغل أو يجيز الوجهة الصادرة أو يؤكد أن التطبيق النهائي أنجز مهمته.

كان المنفذ 23 يقود عادة إلى بيئة عامة

قدم Telnet المبكر مدخلاً مألوفاً إلى المضيف. يفتح User Telnet الاتصال، ويستمع Server Telnet على المنفذ 23، ثم يربط الطرف البعيد عادة ببرنامج تنفيذي عام: EXEC في بعض الأنظمة، أو shell في أنظمة أخرى. يحصل المستخدم عندئذ على بيئة يستطيع أن يختار منها البرنامج التالي.

لكن RFC 764 لم تجعل تلك الصورة تعريفاً أبدياً للأدوار. وصفت Telnet بوصفه مرفق اتصال ثنائي الاتجاه بين طرفيات وعمليات موجهة للطرفية. وكان القاسم المشترك هو Network Virtual Terminal، أي لوحة مفاتيح وطابعة متخيلتان تسمحان لمضيفين مختلفين بالتفاهم من دون معرفة كل نوع طرفية.

كما سمحت آلية الخيارات بالتفاوض على قدرات أغنى مع بقاء الحالة الدنيا صالحة عند الرفض. لم يكن User وServer طبقتين اجتماعيتين بين جهاز قوي وآخر تابع. في الاتصال بين طرفيتين أو عمليتين، كان User هو الطرف الذي يبدأ الاتصال. الدور صفة لعلاقة محددة، لا رتبة دائمة للمضيف.

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

المضيف الصغير لم يحتج إلى ادعاء أنه نظام تسجيل دخول

بدأت RFC 818، المنشورة في نوفمبر 1982، من هذا الاستثناء العملي. قد تكون للمضيف الصغير وظيفة محدودة ولا يكون له executive. لا يحتاج عندئذ إلى Telnet عام، لكن تطبيقاً بعينه قد يستحق نقطة لقاء معروفة.

كان التطبيق المقترح هو User Telnet نفسه. يستطيع مضيف يختار تقديم Remote User Telnet أن يستمع على المنفذ 107. يدخل المتصل عبر جلسة Telnet، إلا أن القدرة وراء الباب ليست بالضرورة مفسر أوامر محلياً؛ إنها برنامج يستطيع أن ينشئ جلسة Telnet نحو وجهة أخرى.

لا يعني ذلك أن الخادم أعيدت تسميته عميلاً. عند الحد الخارجي خدمة تستمع وتنهي الاتصال الوارد، وداخل المضيف برنامج User Telnet يبدأ اتصالاً جديداً. ما فعلته RFC 818 هو جعل هذا التركيب قابلاً للعنونة مع الحفاظ على الوظيفتين.

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

ستة عشر خطاً تسلسلياً ورسمة عمليات صغيرة

جاء المثال من آلة عاملة لدى Bolt Beranek and Newman. كان TC68K مركز طرفيات مبنياً على Motorola MC68000، يملك وصلة شبكة واحدة وست عشرة وصلة RS-232 للطرفيات ومؤقتاً قابلاً للبرمجة. شغل Micro-Operating System الذي وفر IP وICMP وTCP وTelnet.

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

احتاجت BBN إلى اختبار TC68K موضوع في مبنى آخر. بدلاً من تصميم بروتوكول إدارة كامل، وضعت Server Telnet وUser Telnet ظهراً إلى ظهر. يتصل المشغل بالمركز البعيد، فيبدو لبرنامج User TC-Telnet كأنه جالس إلى طرفية محلية، ثم يختار وجهة ويقرأ الإحصاءات التي كان التطبيق يحتفظ بها أصلاً.

ذكرت المذكرة أن البرنامج الإضافي الوحيد كان مشغل pseudo-teletype. ظهرت PTY لكل تطبيق كطرفية، بينما حملت محلياً تدفق محارف بين عمليتين.

هذه أولوية الشفرة العاملة في صورة مصغرة. لم توسع BBN الاتفاق الشبكي المشترك كي تحل حاجة تشغيلية خاصة بموقعها. أعادت استخدام مكونات تتبادل Telnet بالفعل، وأضافت محولاً محلياً صغيراً عند الحد الذي تملكه.

الشاشة الواحدة أخفت محادثتين

قد يرى المشغل موجه أوامر متصلاً فيتوهم مساراً واحداً. أما رسم التنفيذ فكان أدق:

  1. فتح User Telnet المحلي لدى المشغل اتصال TCP وارداً؛
  2. أنهى Server Telnet في TC68K ذلك الاتصال؛
  3. نقلت PTY تدفقاً محلياً إلى User Telnet في TC68K؛
  4. بدأ ذلك البرنامج اتصال TCP ثانياً بالوجهة المختارة.

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

لم تحدد RFC 818 مترجماً عاماً لكل خيارات Telnet، ولا رابطة أمنية تمتد من المشغل إلى الهدف، ولا قانوناً ينشر كل عطل عبر PTY. عبارة «ظهراً إلى ظهر» وصف لتركيب محلي، لا وعد بأن الجسر أنبوب شفاف. فـTelnet يمزج البيانات بأوامر تحكم، وتبقى معالجة NVT وسلوك العمليات حاضرين عند الطرفين.

أكدت RFC 854 لاحقاً التناظر المبدئي نفسه. يمكن لمضيف واحد أن يكون Server في اتصال وارد وUser في اتصال صادر. لا تناقض في ذلك لأن الاسمين يصفان علاقتين مختلفتين.

نجاح الاختبار كان دليلاً محدد المدى

قالت RFC 818 إن الآلية استُخدمت للتحقق من أن مسار الشبكة بين وحدتي TC68K يعمل. لهذه النتيجة قيمة، لكن يجب ألا تكبر عن الملاحظة التي أنشأتها.

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

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

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

بقيت NVT أرضية لا تفرض التبني

بحلول 1989 قدمت RFC 1123 Telnet أساساً كبروتوكول دخول بعيد يصل لوحة مفاتيح وشاشة بمفسر أوامر. ومع ذلك احتفظت المتطلبات بواجبات منفصلة لـUser Telnet وServer Telnet، وألزمت الطرفين بفهم وظائف التحكم الأساسية والتعامل مع الأوامر غير المدعومة. بقي تفاوض الخيارات وبقي الرجوع إلى NVT.

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

لا يزال سجل IANA لأسماء الخدمات وأرقام المنافذ يدرج rtelnet على المنفذ 107 بوصفه Remote Telnet Service. تحفظ الخانة مرجعاً للتنسيق؛ لا تثبت أن الخدمة منتشرة اليوم أو آمنة أو مدعومة في منتج معين. كما أن وجود خانة UDP في السجل لا يعيد كتابة RFC 818 كبروتوكول datagram؛ فقد وصفت المذكرة Telnet القائم على اتصال.

احتاج المنفذ التسلسلي لاحقاً إلى ما هو أكثر من المحارف

بعد خمسة عشر عاماً تناولت RFC 2217 حداً آخر لخادم وصول يصل عميلاً بمنفذ تسلسلي موصول بمودم أو طابعة أو راسم أو جهاز مراقبة. أظهرت الخبرة أن التدفق وحده لا يحمل كل القرارات المحلية التي تهم العمل.

سرعة البث، وعرض البيانات، والتكافؤ، وبتات التوقف، وإشارات المودم، والتحكم في التدفق على مستويين تحتاج أسماء وحالات صريحة. لذلك عرفت RFC 2217 خيار COM-PORT-OPTION داخل تفاوض Telnet المعتاد. وبعد قبوله أمكن إرسال أوامر لتغيير حالة المنفذ وإشعارات لعرض حالة الخط.

والأهم أن الخادم كان يقر بأمر الضبط بعد معالجته ويرسل القيمة التي طبقها فعلاً. كان TCP قد أقر بوصول البايتات، لكن الرد التطبيقي أثبت واقعة أخرى: أن خادم الوصول طبق قيمة، وربما لم تكن مطابقة لما طُلب.

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

لا تقدم هذه المقالة RFC 2217 على أنها وريث موثق أو بديل مباشر لـRFC 818. إنها مقارنة لاحقة عند الحد المعماري نفسه. إعادة استخدام تدفق رخيصة، لكن عندما تتغير حالة عتاد محلي فلا بد من أوامر وتقارير ومالك مسؤول عن الإعادة.

سجل الرقم الباب ولم يملك السلسلة

تكشف RFC 818 حقيقة أبقى من خدمتها المسماة. سمح عقد مشترك مستقر لموقع واحد أن يعيد ترتيب أدوار التنفيذ المحلية. حدد Telnet كيف يتفاهم النظراء. اختار TC68K أي عمليات يصلها وهل يعرض ذلك التركيب. اختار المشغل الوجهة ضمن ضوابط محلية، وقرر الهدف في النهاية ما العمل الذي ينفذه.

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

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