الخلاصة

  • جعل RFC 854 سلوك الطرفية موضوعًا للتفاوض: يستطيع كل طرف طلب خيار، ويستطيع الآخر قبوله أو رفضه.
  • ظلت الطرفية الافتراضية للشبكة وضعًا مشتركًا للعودة إليه، فاختلاف القدرات لم يلغِ أساس الاتصال.

التحليل

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

ظهر الشكل الذي استقر عليه هذا التصميم في مايو 1983. نشر جون بوستل وجويس رينولدز RFC 854 ليحل محل RFC 764. ووصف TELNET بأنه وسيلة اتصال ثنائية الاتجاه، قائمة على بايتات من ثمانية بتات، تصل طرفية المستخدم بالخادم البعيد. وكان مفهوم الطرفية الافتراضية للشبكة (NVT) هو مركز التصميم: مجموعة أعراف مشتركة تتيح بدء جلسة أساسية قبل الاتفاق على سلوك أكثر تخصيصًا.

كانت NVT حدًا أدنى، لا ادعاءً بأن الطرفيات متشابهة. أتاح RFC 854 لأي من الطرفين بدء طلب خيار. وفصلت أربعة أوامر اتجاه المسؤولية: DO يطلب من الطرف المقابل تنفيذ خيار؛ وWILL يعلن أن الطرف المرسل سينفذه. أما DONT وWONT فيسحبان هذين الموقفين. وإذا رُفض الطلب، ظل الجزء المعني من الجلسة على أعراف NVT. أمكن للمضيف أن يقول لا من دون إنهاء الاتصال.

وهذا مهم لأن الخيار لم يكن مفتاحًا عامًا للجلسة. فلكل اتجاه حالة خاصة به. قد يقبل طرف صدى الأحرف ويرفضه الآخر؛ وقد يطلب أحدهما الإرسال الثنائي بينما يبقى الطرف المقابل على الوضع الافتراضي. تُظهر RFCs 856 للإرسال الثنائي و857 للصدى و858 لتعطيل إشارة Go Ahead تغييرات صغيرة تُفاوض حول تدفق مشترك. وطلب RFC 855 توثيق الأوامر والافتراضات الافتراضية والدوافع، مع ترك المجال للمضيفين كي يقترحوا الخيارات ويختبروها أو يتخلوا عنها. ثم صنف RFC 880 خيارات TELNET بأنها اختيارية.

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

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

وتحد السجلات اللاحقة من قصة النجاح. ففي عام 1989، ألزم RFC 1123 التطبيقات بتضمين آلية التفاوض، ورفض الخيارات غير المدعومة، ومواصلة معالجة التفاوض طوال الاتصال، ودعم NVT عند فشل جميع الطلبات. كما وثق التباسات مستمرة، منها اصطلاح نهاية السطر. وفي عام 1990 قدم RFC 1143 طريقة أكثر انتظامًا لإدارة حالة التفاوض. ساعد الوضع المشترك وقواعد منع الحلقات، لكنهما لم يمحوا اختلافات التنفيذ ولم يجعلا كل زوج من الطرفيات يعمل بلا احتكاك.

كان إنجاز RFC 854 التاريخي أدق من القول إن بروتوكولًا واحدًا جعل جميع الطرفيات متوافقة. فقد منح الأنظمة المختلفة إجراءً منضبطًا لاكتشاف ما يمكنها فعله معًا. جعل الأساسُ الرفضَ قابلًا للتعايش؛ وأتاح التفاوضُ التوسعة؛ وظل الحد بينهما ظاهرًا في تدفق البيانات.

المصادر