الخلاصة

  • جمع ETFTP عدداً كبيراً من packets داخل buffer وفي bursts، بحيث يحمل تشغيل واحد مكلف للقناة كمية كبيرة من البيانات؛ ثم ردّ المستقبل عند حد buffer وذكر أرقام packets المفقودة فقط.
  • كانت CONTROL_OK وCONTROL_RESEND وأعلى رقم CONTROL متصل وNULL-ACK إيصالات محلية دقيقة، لكنها لم تثبت وحدها اكتمال الملف أو هوية الطرف أو الأمان أو سبب الفقد.
  • تعود قياسات 1993 إلى إعداد نقطة إلى نقطة بسرعة 16 كيلوبت/ث. وذكر RFC صراحة غياب التحقق بكلمة مرور وأن أمن النموذج الأولي أُهمل.

كان الرد يعني شراء اتجاه جديد

احتاج المسار التكتيكي الموصوف إلى نحو 1.25 ثانية لمزامنة الراديو والمعدات التشفيرية قبل إرسال البيانات. وأضاف الانتشار عبر القمر الصناعي قرابة 500 مللي ثانية إلى الرحلة ذهاباً وإياباً. وفي نصف الازدواج لا يسير الإقرار إلى جانب البيانات؛ بل يوقف اتجاهها ويبدأ تهيئة الاتجاه المعاكس.

قلّل ETFTP عدد هذه الانقلابات بتغيير وحدة العمل. يُقرأ الملف إلى buffers، ويقسّم كل buffer إلى blocks، ويصبح كل block رسالة DATA، ثم تُجمع packets في burst. تشير LDATA إلى آخر block. إذا اكتمل buffer أرسل المستقبل CONTROL_OK، وإذا بقيت فجوات حملت CONTROL_RESEND رقم buffer وعدد packets الغائبة وأرقامها المحددة.

هذه القائمة تصف صورة المستقبل الحالية عن وحدة واحدة. ولا تعني OK نهاية الملف كله؛ فقد بقيت مرحلتا QUIT من المرسل وDONE من المستقبل لإغلاق النقل.

لكل حجم مخاطرة مختلفة

يقلّل buffer الكبير حدود الإقرار لكنه يستهلك الذاكرة ويحتل القناة مدة أطول. ويحافظ burst الكبير على تشغيل المرسل، لكنه قد يملأ مخازن الأجهزة الوسيطة. أما packet الكبيرة فتخفض نسبة الحمل الزائد، غير أن الخطأ البتّي يفسد معها بيانات أكثر.

عند تفعيل التكيّف، إذا احتاج نصف blocks أو أكثر إلى إعادة، خفّض التنفيذ packet size أولاً إلى النصف، ثم أنقص burstsize، ثم قرّب burstrate من معدل tight timer المقاس. وإذا نجح 99% بلا إعادة أمكن رفع packet size. عرضت CONTROL_OK القيم الجديدة، وأكد المرسل قبول القيم الصالحة عبر NULL-ACK.

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

التسلسل المتصل لا يساوي ملفاً كاملاً

حملت DATA وLDATA أعلى sequence number متصل من رسائل CONTROL المستلمة. أثبت الحقل أن مقدمة من تاريخ التحكم وصلت بلا فجوات. ولم يصف رسائل لاحقة أو بيانات لم يُبلّغ عن فقدها بعد أو محتوى القرص أو نهاية النقل.

كذلك لا يحدد timeout السبب. اعتمد النموذج على baudrate يدخله المستخدم وradiodelay يُعطى أو يُقاس، ثم زاد الانتظار خمس ثوانٍ بعد كل انتهاء متكرر. يدل الانتهاء على فشل توقع زمني، لا على الازدحام حتماً. ويمكن للـBER أو التنافس أو امتلاء الطوابير أو سوء التقدير أو بطء البرنامج أن يصنع المشهد نفسه. وتقول RESEND ما لا يراه المستقبل، لا لماذا غاب.

وفق Running-Code Primacy، يحدد النص المنشور معنى الإيصال، بينما يثبت المرور الجاري ما إذا كان الانتقال قد نُفذ فعلاً.

تنتهي دلالة الأرقام عند منصة الاختبار

استخدمت الجداول ملفاً حجمه 101,306 bytes ومساراً مشفراً بسرعة 16 كيلوبت/ث وradiodelay قدره ثانيتان وتوليفات متعددة. وُصل الراديوان بكابل محوري لصنع وصلة سُمّيت “clean” ذات BER 10e-5. كانت أعلى نتيجة 10,432 bps مع buffer حجمه 131,072 bytes وpackets بحجم 2,048 bytes وست عشرة packet في burst، وشمل الزمن الاتصال والتعافي والإغلاق.

لا تثبت هذه النتيجة انتشار ETFTP أو multicast أو عدالة قناة مشتركة أو تفوقاً على نظم حديثة. وحذّر RFC من استخدام قيمة p-persistence القصوى الخاصة بالنقطة إلى النقطة عند مشاركة مستخدمين آخرين. كما بقي تناقض في السجل: حدد النص نطاق packet بين 16 و1,448 byte من بيانات المستخدم، بينما اختبرت الجداول 2,048. يجب حفظ هذا التناقض لا حله بالتخمين.

كانت حدود الأمان أوضح. لم يدعم ETFTP التحقق من المستخدم وكلمة المرور، وكرر مشاكل TFTP، واحتاج خادمه التجريبي إلى ملكية root وsetuid root. وقال RFC إن مسألة الأمن أُغفلت. تربط checksum وconnection ID والمنافذ والتسلسلات الرسائل بالحالة، لكنها لا تصادق على إنسان ولا تفوض الوصول إلى ملف.

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

المصادر