الخلاصة

  • اقترح RFC 1545 التجريبي في نوفمبر 1993 الأمرين LPRT وLPSV لبيان عائلة عنوان اتصال البيانات وطول عنوان المضيف وطول عنوان المنفذ. كان PORT يلتزم بست قيم عشرية ثابتة: أربع للمضيف واثنتان للمنفذ.
  • أضاف الاقتراح رد 228 للنمط السلبي ذي العنوان الطويل، ورد 521 عندما يفهم الخادم الأمر لكنه لا يدعم العائلة المطلوبة. حلّ RFC 1639 محل النسخة الأولى في يونيو 1994 ووسّع وصف العائلات وواجهات النقل.

الملف ينتظر عند شباك العنوان

يعمل FTP بخطين منفصلين. اتصال التحكم ينقل الأوامر والردود، واتصال البيانات يحمل الملف أو فهرس الملفات. في RFC 959، يحدد PORT العنوان الذي سيُفتح عنده الخط الثاني. صيغته بسيطة: h1,h2,h3,h4,p1,p2. تصنع القيم الأربع الأولى عنوان مضيف إنترنت من 32 بتًا، وتصنع القيمتان الأخيرتان منفذ TCP من 16 بتًا. كل قيمة ثمانية تُكتب بالنظام العشري، والفواصل تفصل بينها. في عالم IPv4 وTCP، كانت الاستمارة كافية.

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

في نوفمبر 1993 نشر David Piscitello RFC 1545 بعنوان FTP Operation Over Big Address Records، واختصاره FOOBAR. الاسم قريب من المزاح الذي يبقى على السبورة بعد انتهاء الاجتماع؛ أما البناء فدقيق. يبدأ LPRT بقيمة لعائلة العنوان، ثم طول عنوان المضيف، ثم بايتات المضيف، ثم طول عنوان المنفذ وبايتاته. تنتقل الحقول كقيم عشرية غير سالبة مفصولة بفواصل. لم يعد القارئ مطالبًا بأن يخمّن عدد بايتات كل جزء من شكل قديم؛ الأمر يعلن عائلته ومقاسه بنفسه.

احتاج المسار السلبي إلى جواب مماثل. يطلب LPSV من الخادم أن ينتظر اتصال البيانات على منفذ، فيرسل الخادم رد 228 Entering Long Passive Mode وفيه العائلة والطول والعنوان والمنفذ. توسيع أمر العميل وحده كان سيترك عنوان الخادم محبوسًا في القالب القديم. لذلك تناول FOOBAR جانبي المحادثة التي تجهز الخط الثاني، لا اتجاهًا واحدًا منها.

هناك رد آخر يحمل وظيفة مهمة: 521. قد يعرف الخادم صيغة الأمر الطويل ولا يمتلك دعمًا لعائلة العنوان المحددة. عندئذ يسرد العائلات التي يدعمها. تبقى 500 و501 لأخطاء بناء الأمر. بهذه التفرقة يعرف الطرف الطالب ما إذا أخطأ في كتابة الجملة أم طلب نوع اتصال غير موجود لدى الخادم. يستطيع بعدها أن يختار عائلة مشتركة إن كانت متاحة.

تُظهر قائمة RFC 1545 ما كان مطروحًا عام 1993: IP وST Datagram Mode وSIP وTP/IX وPIP وTUBA. هذه أسماء خيارات النقاش التقني في ذلك الوقت. وكتب الاقتراح طول المنفذ صراحة لسبب إضافي؛ فقد تصوّر TP/IX محددات نقل أطول من منفذ TCP ذي الستة عشر بتًا. تكبير موضع المضيف وترك المنفذ في خانتين كان سينقل الاختناق إلى الجانب الآخر من الفاصلة. وسمح النص أيضًا بأن تختلف عائلة اتصال التحكم عن عائلة اتصال البيانات، لأن الانتقال بين الشبكات قد يجري بتركيبات مختلطة.

في يونيو 1994 جاء RFC 1639 من المؤلف نفسه وأبطل RFC 1545. أبقى فكرة السجل الطويل، وخصص القيم من 0 إلى 15 لأرقام الإصدارات المرتبطة بعائلة IP، وفتح المجال من 16 إلى 255 لبروتوكولات طبقة الشبكة الأخرى التي تسندها IANA. ظهر Novell IPX عند القيمة 16. كما شرح الإصدار المعدل تشغيل FTP فوق واجهات نقل غير TCP. اتسع دفتر العناوين من إصلاح ضيق إلى طريقة لتسمية عائلات ووسائط مختلفة.

تبدو جملة PORT h1,h2,h3,h4,p1,p2 متواضعة أمام الرسوم الكبيرة التي تناولت مستقبل الإنترنت. لكنها خبأت في تطبيق نقل الملفات افتراضين محددين عن حجم المضيف والمنفذ. لن ينتقل الملف قبل أن يتفق الطرفان على عنوان خط البيانات. جعل FOOBAR ذلك الاتفاق صريحًا: أي عائلة، كم بايتًا للمضيف، كم للمنفذ، وما الذي يستطيع الطرف الآخر فهمه. في تاريخ الشبكات، قد يسكن قرار معماري كامل بين ست خانات وفواصلها.