ZMODEM

بشكل عام، تقوم بروتوكولات نقل الملفات القديمة بتقسيم الملف إلى سلسلة من الحزم ، ثم ترسلها واحدة تلو الأخرى إلى المُستقبِل. الجزء الرئيسي من الحزمة، وهو الحمولة ، يُمثل عددًا مُحددًا من البايتات من الملف المُرسَل. بعد الحمولة، يأتي فحص المجموع الاختباري أو فحص التكرار الدوري (CRC) الذي يُستخدم لتحديد ما إذا كانت الحمولة قد استُلمت بشكل صحيح. إذا استُلمت الحزمة بشكل صحيح، يُرسل المُستقبِل رسالة تأكيد (ACK) ، ثم يبدأ المُرسِل بإرسال الحزمة التالية.

يُدخل نظام الهاتف تأخيرًا بسيطًا يُعرف بزمن الاستجابة ، وهو ما يُعيق هذه العملية. فحتى لو أرسل المُستقبِل إشعار الاستلام (ACK) فورًا، فإن التأخير في خطوط الهاتف يعني وجود فترة زمنية قبل أن يستلمه المُرسِل ويرسل الحزمة التالية. ومع ازدياد سرعات المودم ، يُمثل هذا التأخير عددًا متزايدًا من الحزم التي كان من الممكن إرسالها خلال فترة التأخير، مما يُقلل من كفاءة القناة .

استخدم XMODEM حمولات بيانات بحجم 128 بايت، مع رأسية من ثلاثة بايتات ومجموع اختباري من بايت واحد، ليصبح المجموع الكلي 132 بايت لكل حزمة. في عصر  مودمات 300 بت/ثانية، كانت الحزمة تستغرق حوالي أربع ثوانٍ للإرسال، وكانت زمن الاستجابة النموذجي في حدود عُشر الثانية ، لذا لم يكن تأثير ذلك على الأداء كبيرًا. مع ازدياد السرعات ، تتفاقم المشكلة؛ فعند سرعة 2400 بت/ثانية ،  تستغرق الحزمة حوالي 0.55  ثانية للإرسال، أي ما يُهدر حوالي خُمس النطاق الترددي المتاح في انتظار إشعارات الاستلام . أما عند سرعة 9600 بت/ثانية ، فتستغرق الحزمة 0.13 ثانية فقط للإرسال، أي ما يُهدر حوالي نصف النطاق الترددي.  

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

تُعدّ النوافذ المنزلقة مفيدةً للتعامل مع زمن استجابة يصل إلى عدة أطوال حزم بيانات، كما هو الحال مع مودم XMODEM على خطوط الهاتف التقليدية. مع ذلك، لا تكفي هذه الطريقة لمعالجة زمن الاستجابة الأطول في المكالمات الهاتفية الدولية، أو الاتصالات عبر الأقمار الصناعية، أو خدمات X.25 مثل PC Pursuit ، حيث قد يصل زمن الاستجابة إلى ثانية أو أكثر. في حالات أخرى، عندما تكون قناة الإرسال العكسي أبطأ بكثير من قناة الإرسال، كما هو الحال مع مودمات Telebit أو USRobotics ، قد يؤدي حتى العدد القليل من إشعارات التأكيد (ACK ) إلى إغراق قناة الإرسال العكسي وتوقف عملية النقل مؤقتًا.

عالج بروتوكول ZMODEM هذه المشاكل بإلغاء الحاجة إلى رسائل التأكيد (ACK ) تمامًا، مما سمح للمرسل بإرسال البيانات باستمرار طالما لم يكتشف المُستقبِل أي أخطاء. وكان لا بد من إرسال رسائل الرفض (NAK ) فقط في حال وجود مشكلة. ونظرًا لاستخدام ZMODEM غالبًا على روابط مزودة بخاصية تصحيح الأخطاء المدمجة ، مثل X.25، فإن المُستقبِل غالبًا ما كان يمتنع عن إرسال أي رسالة رد إلى المرسل. ونتيجة لذلك، كان النظام يرسل الملف بأكمله في تدفق مستمر، ولذلك كان ZMODEM يُطلق على نفسه اسم "بروتوكول البث المباشر".

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

كان بروتوكول XMODEM، ومعظم البروتوكولات المبنية عليه، يُدير ترتيب الحزم عن طريق إضافة رقم حزمة من 1 إلى 255 قبل كل حزمة. وكانت الإصدارات المُجزأة تستخدم هذا الرقم لتحديد الحزم التي تم استلامها بنجاح، أو لتحديد الحزم التي لم يتم استلامها. وبما أن  طول الحزم كان 128 بايت، فإن هذا يعني أن الحد الأقصى لحجم البيانات التي يمكن نقلها قبل إعادة ترتيب أرقام الحزم هو 32  كيلوبايت.

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

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