YMODEM

كانت إحدى مشكلات بروتوكول XMODEM الأصلي عدم وجود طريقة محددة لإيقاف عملية الإرسال بعد بدئها. وكان الحل المعتاد هو إرسال إشعار رفض (NAK ) مع كل حزمة بيانات لاحقة إذا طلب المستخدم ذلك. ولأن بروتوكول XMODEM حدد حدًا أقصى لعشرة إشعارات رفض لإيقاف الإرسال، ولأن كل حزمة بيانات قد تستغرق ثانية واحدة للإرسال، فقد كان هذا يعني وجود تأخير لمدة عشر ثوانٍ حيث كان المرسل يرسل بيانات يتم تجاهلها ببساطة.

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

تم إدخال دعم CRC في XMODEM-CRC. كان هذا تغييرًا بسيطًا جدًا على البروتوكول الأصلي؛ فإذا طُلب ذلك، يحاول المُستقبِل بدء عملية النقل بإرسال رمز C أولي بدلًا من رمز NAK . إذا كان المُرسِل البعيد يدعم خيار CRC، فإنه يبدأ بإرسال الحزم كالمعتاد، ولكن مع رمز CRC ذي 16 بت في التذييل بدلًا من مجموع التحقق ذي البايت الواحد. يدعم YAM هذا الخيار دون أي تغييرات.

تم إدخال حزم بيانات بحجم 1024 بايت في XMODEM-1k. ^{[ 1 ]} لم يُغيّر هذا الإصدار حرف التشغيل من المُستقبِل، لذا لم يكن بإمكان المُرسِل معرفة ما إذا كان المُستقبِل يدعم حزم بيانات أكبر. بدلاً من ذلك، عُرض XMODEM-1k كبروتوكول منفصل على طرفي الاتصال. عند بدء هذا الاتصال، كان بإمكان المُرسِل اختيار إرسال حزمة بيانات بحجم 1024 بايت أو 128 بايت، مع الإشارة إلى الحجم الأكبر باستخدام حرف STX في رأس الحزمة بدلاً من SOH المعتاد . عادةً ما تستخدم الحزم القليلة الأخيرة فقط الحزم الأصغر حجمًا، لتجنب إرسال كميات كبيرة من البيانات المُضافة. كما افترض XMODEM-1k استخدام CRC لجميع الاتصالات. دعم YAM بروتوكول XMODEM-1k دون أي تغييرات.

لدعم عمليات نقل البريد الإلكتروني عبر شبكة FidoNet آليًا ، أضاف مودم 7 إمكانية إرسال اسم الملف كنص عادي قبل إرسال أول كتلة بيانات. لم تكن هذه الطريقة موثوقة، فقام TeLink بتحسينها عن طريق وضع اسم الملف، وبيانات أخرى اختيارية مثل تاريخ الإنشاء وحجم الملف، في حزمة بيانات كاملة بحجم 128 بايت. بدأ XMODEM عمليات النقل بالحزمة رقم واحد، لذا أرسل TeLink هذه الحزمة كرقم صفر. أصبحت هذه "الحزمة الصفرية" أو "الكتلة الصفرية" شائعة في أنظمة FidoNet الأخرى مثل SEAlink وغيرها.

كان بروتوكول YAM يدعم تنسيق الحزمة الصفرية، لكن العديد من تطبيقات YMODEM الخارجية تجاهلته. عندما حاول أحد هذه التطبيقات إرسال الحزمة الصفرية إلى إصدار لا يدعمها، قام المُستقبِل تلقائيًا برفض الحزمة (NAK )، لأن الحزمة الصفرية غير مسموح بها. عندها، اعتبر المُرسِل رفض الحزمة خطأً في الإرسال وحاول إرسالها مرة أخرى، مُكررًا المحاولة عشر مرات قبل أن يفشل.

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

ونتيجةً لذلك، كان من الشائع رؤية كل من YMODEM وYMODEM Batch مُدرجين كبروتوكولين منفصلين. وقد زاد التشابه بين XMODEM-1k وهذه البروتوكولات غير المتوافقة من YMODEM من الارتباك، لدرجة أنها كانت تُدرج خطأً في كثير من الأحيان على أنها نفس البروتوكول.