إكس مودم

📅 آخر تحديث: ٢٣ يوليو ٢٠٢٦
✍️ نُشر في: ٢٣ يوليو ٢٠٢٦
الموسوعة الحرة

XMODEM هو بروتوكول بسيط لنقل الملفات ، طُوِّرَ كحلٍّ سريع من قِبَل وارد كريستنسن لاستخدامه في برنامجه الطرفي MODEM.ASM عام 1977. وقد سمح للمستخدمين بنقل الملفات بين أجهزة الكمبيوتر الخاصة بهم عندما يستخدم كلا الطرفين مودم. أجرى كيث بيترسن تحديثًا بسيطًا لتفعيل "الوضع الصامت" دائمًا، وأطلق على النتيجة اسم XMODEM. [ 3 ] [ 4 ]

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

حظي برنامج XMODEM بشعبية واسعة في سوق أنظمة لوحات الإعلانات الإلكترونية (BBS) في بداياتها ، ويعود ذلك في الغالب إلى سهولة تنفيذه. إلا أنه كان يعاني من انخفاض الكفاءة، ومع ازدياد سرعات المودم، أدت هذه المشكلة إلى تطوير عدد من النسخ المعدلة من XMODEM لتحسين الأداء أو معالجة مشاكل أخرى في البروتوكول. [ 4 ] وقد اعتبر كريستنسن برنامجه الأصلي XMODEM "البرنامج الأكثر تعديلاً في تاريخ الحوسبة". [ 5 ]

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

بنية الحزمة

استخدم نظام XMODEM الأصلي حزمة بيانات بحجم 128 بايت، وهو حجم الكتلة المستخدم في أقراص CP/M المرنة . كانت الحزمة مسبوقة برأسية بسيطة من 3 بايت تحتوي على حرف، و"رقم كتلة" من 1 إلى 255، و"معكوس" رقم الكتلة - 255 ناقص رقم الكتلة. يبدأ ترقيم الكتل من 1 للكتلة الأولى المرسلة، وليس من 0. تلت الرأسية 128 بايت من البيانات، ثم مجموع اختباري من بايت واحد . كان المجموع الاختباري هو مجموع جميع بايتات البيانات الـ 128 في الحزمة بتردد 256. وبذلك، بلغ طول الحزمة الكاملة 132 بايت، تحتوي على 128 بايت من بيانات الحمولة ، مما يحقق كفاءة قناة إجمالية تبلغ حوالي 97%.<SOH>

تم وضع علامة "مكتمل" على الملف بحرف يُرسل بعد الكتلة الأخيرة. لم يكن هذا الحرف ضمن حزمة، بل أُرسل منفردًا كبايت واحد. ولأن طول الملف لم يُرسل كجزء من البروتوكول، فقد أُضيفت إلى الحزمة الأخيرة "حرف معروف" يمكن حذفه. في المواصفات الأصلية، كان هذا الحرف افتراضيًا هو 26 بالنظام العشري، وهو ما استخدمه نظام CP/M كعلامة لنهاية الملف ضمن تنسيق القرص الخاص به. اقترح المعيار إمكانية استخدام أي حرف للحشو، ولكن لم تكن هناك طريقة لتغييره ضمن البروتوكول نفسه - فإذا غيّر أحد التطبيقات حرف الحشو، فلن يتمكن من تفسير حرف الحشو الجديد بشكل صحيح إلا العملاء الذين يستخدمون نفس التطبيق.<EOT><SUB>

تفاصيل التحويل

كانت الملفات تُنقل حزمةً تلو الأخرى. عند استلام الحزمة، كان المُستقبِل يحسب مجموع التحقق الخاص بها ويقارنه بالمجموع المُستلم من المُرسِل في نهاية الحزمة. إذا تطابق المجموعان، كان المُستقبِل يُرسل رسالةً إلى المُرسِل، الذي بدوره كان يُرسل الحزمة التالية بالتسلسل. أما إذا كانت هناك مشكلة في مجموع التحقق، فكان المُستقبِل يُرسل رسالة خطأ . إذا تم استلام رسالة خطأ، كان المُرسِل يُعيد إرسال الحزمة، [ 4 ] ويستمر في المحاولة عدة مرات، عادةً عشر مرات، قبل إيقاف عملية النقل.<ACK><NAK><NAK>

كما تم إرسال رمز A <NAK>إذا لم يستلم المُستقبِل حزمة بيانات صالحة خلال عشر ثوانٍ بينما لا يزال ينتظر البيانات بسبب نقص <EOT>حرف معين. وتم استخدام مهلة زمنية مدتها سبع ثوانٍ داخل الحزمة، وذلك للحماية من انقطاع الاتصالات أثناء نقل الحزمة.

تم فحص أرقام الكتل بطريقة بسيطة للتحقق من وجود أخطاء. بعد استلام حزمة بنجاح، يجب أن تحمل الحزمة التالية رقمًا أعلى بواحد. إذا استلمت الحزمة نفس رقم الكتلة، فلا يُعتبر ذلك خطأً جسيمًا، إذ يُفهم ضمنيًا أن <ACK>المرسل لم يستلم الحزمة، وبالتالي أعاد إرسالها. أي رقم حزمة آخر يشير إلى فقدان الحزم.

كانت عمليات النقل تتم بناءً على طلب المُستقبِل؛ إذ لا يُرسل المُرسِل أي بيانات حتى <NAK>يُرسل المُستقبِل إشارةً أولية. كان هذا نتيجةً منطقيةً لطريقة تفاعل المستخدم مع جهاز الإرسال، الذي يكون موجودًا في مكانٍ بعيد. ينتقل المستخدم إلى الملف المطلوب على جهاز الإرسال، ثم يطلب منه نقله. بمجرد إصدار هذا الأمر، يُنفّذ المستخدم أمرًا في برنامجه المحلي لبدء الاستقبال. ولأن التأخير بين طلب الملف من النظام البعيد وإصدار أمر الاستقبال المحلي غير معروف، فقد سمح بروتوكول XMODEM بما يصل إلى 90 ثانية للمُستقبِل لبدء إرسال طلبات حزم البيانات.

مشاكل

على الرغم من أن XMODEM كان قويًا بما يكفي لكي يتمكن صحفي في عام 1982 من نقل القصص من باكستان إلى الولايات المتحدة باستخدام Osborne 1 ومقرن صوتي عبر خطوط الهاتف ذات الجودة الرديئة، [ 6 ] إلا أن البروتوكول كان به العديد من العيوب.

مشاكل بسيطة

كُتب برنامج XMODEM لأجهزة CP/M ، ويحمل العديد من سمات هذا النظام . فعلى سبيل المثال، كانت الملفات في CP/M دائمًا من مضاعفات 128 بايت، وكانت نهايتها تُحدد داخل كتلة باستخدام <EOT>الحرف . نُقلت هذه الخصائص مباشرةً إلى XMODEM. مع ذلك، لم تكن أنظمة التشغيل الأخرى تتضمن أيًا من هاتين الخاصيتين، وأدى الانتشار الواسع لنظام MS-DOS في أوائل الثمانينيات إلى ضرورة تحديث XMODEM ليتعرف على الحرف <EOT>أو<EOF> كعلامة لنهاية الملف.

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

مشاكل رئيسية

صُمم بروتوكول XMODEM ليكون بسيطًا، دون معرفة كبيرة ببروتوكولات نقل الملفات الأخرى - التي كانت نادرة نسبيًا آنذاك. وبسبب هذه البساطة، وُجدت عدة أخطاء أساسية قد تؤدي إلى فشل عملية النقل، أو ما هو أسوأ، إلى ملف غير صحيح لا يكتشفه البروتوكول. ويعود معظم ذلك إلى استخدام مجموع اختباري بسيط لتصحيح الأخطاء، [ 4 ] وهو عرضة لفقدان البيانات إذا انعكست قيمتان ، وهو ما قد يحدث مع نبضة قصيرة من التشويش. إضافةً إلى ذلك، قد يؤدي تلف مماثل في رأس الملف أو المجموع الاختباري إلى فشل عملية النقل حتى لو كانت البيانات نفسها سليمة.

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

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

عمليات نقل الدفعات

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

لأغراض النقل الآلي بين موقعين، تم تطبيق عدد من الإضافات على بروتوكول XMODEM بمرور الوقت. كانت هذه الإضافات تفترض عمومًا أن المرسل سيستمر في إرسال الملفات تباعًا، بينما يحاول المُستقبِل بدء إرسال الملف التالي بإرسال إشارة NAKكالمعتاد في بداية عملية النقل. وعند NAKانتهاء مهلة الإشارة، كان يُفترض إما عدم وجود ملفات أخرى، أو انقطاع الاتصال.

مودم 7

كان بروتوكول MODEM7 ، المعروف أيضًا باسم MODEM7 batch أو Batch XMODEM ، أول امتداد معروف لبروتوكول XMODEM. تبدأ عملية نقل الملفات العادية عبر XMODEM بإرسال المُستقبِل NAKحرفًا واحدًا إلى المُرسِل، الذي يبدأ بدوره بإرسال حرف واحد SOHللإشارة إلى بداية نقل البيانات، ثم حزم البيانات.

لم يُغيّر مودم 7 هذا السلوك إلا قليلاً، حيث كان يُرسل اسم الملف، بتنسيق اسم الملف 8.3 ، قبل الفاصلة <SOH>. كان كل حرف يُرسل على حدة، وكان على المُستقبِل إعادة إرساله كنوع من تصحيح الأخطاء. بالنسبة لتطبيق XMODEM غير المُدرك لهذه البيانات، كان يتم تجاهل هذه البيانات ببساطة أثناء انتظار SOHوصول الفاصلة، وبالتالي لم تكن الأحرف تُعاد إرسالها، وكان بإمكان التطبيق العودة إلى XMODEM التقليدي. أما مع البرامج المُدركة لهذه البيانات، فكان يُمكن استخدام اسم الملف لحفظ الملف محليًا. يُمكن أن تستمر عمليات النقل بفاصلة أخرى <NAK>، حيث يتم حفظ كل ملف بالاسم المُرسل إلى المُستقبِل.

وصف جيري بورنيل في عام 1983 برنامج MODEM7 بأنه "ربما يكون برنامج الاتصالات الأكثر شيوعًا على أجهزة الكمبيوتر الصغيرة ". [ 7 ]

كان مودم 7 يرسل اسم الملف كنص عادي، مما يعني أنه كان عرضة للتلف بسبب نفس المشاكل التي كان XMODEM يحاول تجنبها. وقد أدى ذلك إلى ظهور TeLink من قِبل توم جينينغز ، مؤلف برامج البريد الإلكتروني الأصلية لشبكة FidoNet .

تجنّبت TeLink مشاكل MODEM7 من خلال توحيد "حزمة الصفر" الجديدة التي تحتوي على معلومات حول الملف الأصلي. تضمنت هذه الحزمة اسم الملف وحجمه وطابعه الزمني ، والتي وُضعت في كتلة XMODEM عادية بحجم 128 بايت. بينما تبدأ عملية نقل XMODEM العادية بإرسال المُرسِل "الكتلة 1" مع <SOH>ترويسة، كانت حزمة ترويسة TeLink تحمل اسم "الكتلة 0" وتبدأ بـ <SYN>. احتوت الحزمة على تاريخ ووقت إنشاء الملف، واسم الملف حتى 16 حرفًا، وحجم الملف كقيمة من 4 بايت، واسم البرنامج المُرسِل للملف. [ 8 ]

في تطبيق XMODEM العادي، يتم تجاهل الحزمة ببساطة، بافتراض أن رقم الحزمة قد تلف. لكن هذا قد يؤدي إلى تأخير زمني في حال تجاهل الحزمة، إذ لا يستطيع المرسل تحديد ما إذا كان المُستقبِل قد ردّ برسالة خطأ <NAK>بسبب عدم فهمه للحزمة الصفرية أو بسبب خطأ في الإرسال. ولأن TeLink كان يُستخدم عادةً فقط من قِبل برامج FidoNet ، التي تشترطه كجزء من معايير FidoNet، فإن هذا لا يُشكّل مشكلة في الواقع العملي، حيث يدعم كلا الطرفين هذا المعيار دائمًا. [ 8 ]

أصبح نظام "الكتلة 0" الأساسي معيارًا في مجتمع FidoNet، وأعيد استخدامه بواسطة عدد من البروتوكولات المستقبلية مثل SEAlink و YMODEM .

XMODEM-CRC

كانت قيمة التحقق المستخدمة في البروتوكول الأصلي بسيطة للغاية، ما أدى إلى عدم اكتشاف بعض أنواع الأخطاء في الحزمة. وقد دفع هذا جون بيرنز إلى ابتكار XMODEM-CRC ، [ 9 ] [ 10 ] الذي استخدم رمز التحقق الدوري (CRC) ذو 16 بت بدلاً من قيمة التحقق ذات 8 بت. [ 4 ] لا يقتصر دور رموز التحقق الدوري على ترميز البيانات في الحزمة فحسب، بل يشمل ترميز موقعها أيضًا، ما يسمح لها باكتشاف أخطاء استبدال البتات التي قد لا تكتشفها قيمة التحقق العادية. إحصائيًا، رفع هذا من احتمالية اكتشاف خطأ يقل طوله عن 16 بت إلى 99.9969%، بل وزادت هذه النسبة مع سلاسل بتات الخطأ الأطول. [ 11 ]

صُمم بروتوكول XMODEM-CRC ليكون متوافقًا مع الإصدارات السابقة من XMODEM. ولتحقيق ذلك، كان المُستقبِل يُرسل Cحرفًا كبيرًا (C) بدلًا من <NAK>لبدء عملية النقل. إذا استجاب المُرسِل بإرسال حزمة بيانات، يُفترض أن المُرسِل "يعرف" بروتوكول XMODEM-CRC، ويستمر المُستقبِل في إرسال Cحزم البيانات. أما إذا لم تصل أي حزمة بيانات، فيفترض المُستقبِل أن المُرسِل لا يعرف البروتوكول، ويرسل <NAK>لبدء عملية نقل بيانات XMODEM "تقليدية". [ 11 ]

لسوء الحظ، كان لهذه المحاولة لتحقيق التوافق مع الإصدارات السابقة جانب سلبي. فبما أنه كان من المحتمل Cفقدان الحرف الأول أو تلفه، لم يكن بالإمكان افتراض أن جهاز الاستقبال لا يدعم XMODEM-CRC إذا فشلت المحاولة الأولى لبدء النقل. ولذلك، حاول جهاز الاستقبال بدء النقل ثلاث مرات C، مع الانتظار ثلاث ثوانٍ بين كل محاولة. هذا يعني أنه إذا اختار المستخدم XMODEM-CRC أثناء محاولته التواصل مع أي جهاز XMODEM، كما هو مُصمم، فقد يكون هناك تأخير محتمل لمدة 10 ثوانٍ قبل بدء النقل. [ 11 ]

لتجنب التأخير، كان المرسل والمستقبل يُدرجان عادةً XMODEM-CRC بشكل منفصل عن XMODEM، مما يسمح للمستخدم باختيار XMODEM "الأساسي" إذا لم يُدرجه المرسل صراحةً. بالنسبة للمستخدم العادي، كان XMODEM-CRC بمثابة "بروتوكول ثانٍ"، ويتم التعامل معه على هذا الأساس. إلا أن هذا لم يكن صحيحًا بالنسبة لبرامج البريد الإلكتروني FidoNet، حيث تم تعريف CRC كمعيار لجميع عمليات نقل TeLink. [ 8 ]

إنتاجية أعلى

نظرًا لأن بروتوكول XMODEM كان يتطلب من المرسل التوقف وانتظار رسالة <ACK>تأكيد <NAK>من المُستقبِل، فقد كان بطيئًا نسبيًا. في عصر  مودمات 300 بت/ثانية، استغرقت حزمة البيانات الكاملة (132 بايت) 4.4  ثانية للإرسال (132 بايت × (8 بتات لكل بايت + بت بدء + بت توقف) / 300 بت/ثانية). بافتراض أن وصول  رسالة المُستقبِل <ACK>إلى المُرسِل يستغرق 0.2 ثانية، وبدء وصول الحزمة التالية إلى المُستقبِل (0.1  ثانية في كلا الاتجاهين)، فإن إجمالي زمن إرسال حزمة واحدة سيكون 4.6  ثانية، أي بكفاءة قناة تزيد قليلًا عن 92%.

كان زمن معالجة طلب <ACK>/ <NAK>دالة ثابتة لشبكة الاتصالات الأساسية، وليس لأداء أجهزة المودم. مع زيادة سرعات المودم، ازداد التأخير الثابت بما يتناسب مع الوقت اللازم لإرسال الحزمة. على سبيل المثال، عند سرعة 2400  بت/ثانية، استغرقت الحزم 0.55  ثانية فقط للإرسال، لذا إذا استغرق طلب <ACK>/ 0.2 ثانية للوصول إلى جهاز المستخدم، فإن الكفاءة انخفضت إلى 71%. عند سرعة 9600 بت/ثانية، تنخفض الكفاءة إلى أقل من 40% بقليل - أي أن الوقت المستغرق في انتظار الرد يفوق الوقت اللازم لإرسال الحزمة.<NAK>  

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

WXModem

WXmodem ، اختصارًا لـ "Windowed Xmodem"، هو نوع مُعدّل من XMODEM طوّره بيتر بوسويل عام 1986 للاستخدام على خطوط ذات زمن استجابة عالٍ، وتحديدًا أنظمة X.25 العامة و PC Pursuit . تتميز هذه الأنظمة بزمن استجابة أعلى بكثير من خدمة الهاتف التقليدية ، مما يؤدي إلى انخفاض كفاءة XMODEM بشكل كبير. إضافةً إلى ذلك، غالبًا ما تستخدم هذه الشبكات رموز تحكم للتحكم في تدفق البيانات ومهام أخرى، ولا سيما XON/XOFF الذي يوقف تدفق البيانات. أخيرًا، في حالة حدوث خطأ يتطلب إعادة الإرسال، كان من الصعب أحيانًا تحديد ما إذا SOHكان الرمز `x` مؤشرًا على وجود حزمة بيانات أم مجرد تشويش. قام WXmodem بتكييف XMODEM-CRC لمعالجة هذه المشاكل. [ 11 ]

كان أحد التغييرات هو إلغاء تسلسل مجموعة صغيرة من أحرف التحكم: DLE، XON، XOFFو SYN. تم إلغاء تسلسل هذه الأحرف بإضافة حرف DLEقبلها، ثم تعديل الحرف بإجراء عملية XOR بينه وبين 64. نظريًا، هذا يعني أن طول الحزمة قد يصل إلى 264 بايت إذا كانت تتكون في الأصل بالكامل من أحرف تتطلب إلغاء التسلسل. لا تُعد هذه الأحرف المُضافة والمُعدلة جزءًا من حساب CRC، بل تُزال وتُحوّل في الطرف المُستقبِل قبل حساب CRC. [ 11 ]

بالإضافة إلى ذلك، كانت جميع الحزم مسبوقة بحرف SYN، مما يعني أن بداية الحزمة كانت SYNSOH، مما يقلل من احتمالية SOHالخلط بين حرف دخيل ورأس حزمة في حالات الخطأ المختلفة. SYNوكان وجود حرف غير مُهَرَّب في متن الحزمة يُعد خطأً. [ 11 ]

يتمثل التغيير الرئيسي في WXMODEM في استخدام نافذة منزلقة لتحسين معدل نقل البيانات على الروابط ذات زمن الاستجابة العالي. ولتحقيق ذلك، ACKتُتبع الرسائل برقم الحزمة التي تُرسلها ACK. NAKلا يُشترط على المُستقبِل إرسال ACKكل حزمة؛ إذ يُسمح له بإرسال ACKأي عدد بين حزمة واحدة وأربع حزم. ACKيُفترض أن الحزمة التي تحمل رقم التسلسل الرابع تُرسل ACKجميع الحزم الأربع. يؤدي حدوث خطأ إلى NAKإرسال حزمة جديدة فورًا، مع جميع الحزم بدءًا من ذلك الرقم، ثم إعادة إرسالها. [ 11 ]

يُتيح طلب إعادة إرسال ACKكل أربع حزم بيانات للنظام العمل كما لو كان حجم الحزمة 512  بايت، ولكن في حالة حدوث خطأ، لا يتطلب الأمر عادةً سوى  إعادة إرسال 128 بايت. علاوة على ذلك، يُقلل هذا من كمية البيانات المتدفقة في الاتجاه المعاكس بمقدار أربعة أضعاف. هذا الأمر غير ذي أهمية كبيرة في تشغيل المودم ثنائي الاتجاه الكامل ، ولكنه مهم في أنظمة نصف الاتجاه مثل طرازات Telebit التي تتميز  بسرعة 19 كيلوبايت في الثانية في اتجاه واحد و75  بت/ثانية في قناة الإرجاع .

كان برنامج SEAdog من أوائل برامج البريد الإلكتروني الخارجية لنظام FidoNet ، وقد كتبه نفس مؤلف تنسيق ضغط البيانات .arc الذي كان شائعًا آنذاك . تضمن SEAdog مجموعة واسعة من التحسينات، بما في ذلك SEAlink ، وهو بروتوكول نقل مُحسَّن يعتمد على مفهوم النافذة المنزلقة نفسه المستخدم في WXmodem. [ 12 ] وقد اختلف عن WXmodem في التفاصيل بشكل أساسي.

يتمثل أحد الاختلافات في أن SEAlink دعمت "الحزمة الصفرية" التي قدمتها TeLink، وهي ضرورية للعمل كبديل مباشر لـ TeLink في أنظمة FidoNet التي تتطلب وجود رأس الحزمة. تم توسيع ACKs و NAKs إلى "حزم" من ثلاثة بايتات، تبدأ بـ ACKأو NAK، ثم رقم الحزمة، ثم مكمل رقم الحزمة، بنفس طريقة رأس حزمة XMODEM الأصلية. عادةً ما يتم ضبط حجم النافذة على ست حزم. [ 12 ]

لم يكن من المتوقع أن يعمل بروتوكول SEAlink عبر روابط X.25 أو روابط مماثلة، ولذلك لم يكن يدعم عملية الهروب من الأحرف. كان هذا ضروريًا أيضًا لضمان عمل حزمة الصفر بشكل صحيح، حيث استخدم هذا المعيار الحرف SYNالذي أعاد WXmodem استخدامه. [ 12 ] إضافةً إلى هذه التغييرات، أضاف البروتوكول وضع "السرعة القصوى" لروابط نصف الازدواج. يعمل هذا الوضع على كبت إشعارات التأكيد (ACKs) للحزم التي تم نقلها بنجاح، مما يجعل حجم النافذة غير محدود. يُشار إلى هذا الوضع بواسطة علامة في كتلة الصفر. [ 12 ]

أضافت SEAlink لاحقًا عددًا من التحسينات الأخرى، وكانت بروتوكولًا مفيدًا للأغراض العامة. ومع ذلك، ظلت نادرة خارج عالم FidoNet، ونادرًا ما شوهدت في البرامج الموجهة للمستخدمين.

XMODEM-1K

هناك طريقة أخرى لحل مشكلة الإنتاجية وهي زيادة حجم الحزمة. ورغم بقاء مشكلة زمن الاستجابة الأساسية قائمة، إلا أن سرعة تحولها إلى مشكلة تتزايد. وكان XMODEM-1K بحزم حجمها 1024 بايت [ 4 ] الحل الأكثر شيوعًا في هذا الصدد. في هذه الحالة، تبلغ الإنتاجية  81% عند 9600 بت/ثانية، بافتراض نفس الافتراضات المذكورة سابقًا.

كان XMODEM-1K نسخة موسعة من XMODEM-CRC، حيث يشير إلى حجم الكتلة الأكبر لدى المرسل عن طريق بدء الحزمة بالحرف <STX>بدلاً من <SOH>. ومثل امتدادات XMODEM الأخرى المتوافقة مع الإصدارات السابقة، كان الهدف هو إمكانية بدء نقل -1K مع أي تطبيق لـ XMODEM على الطرف الآخر، مع تقليل الميزات حسب الحاجة.

كان XMODEM-1K في الأصل أحد التحسينات العديدة التي أدخلها تشاك فورسبيرغ على بروتوكول YMODEM . اقترح فورسبيرغ أن تكون هذه التحسينات اختيارية، متوقعًا من مطوري البرامج تطبيق أكبر عدد ممكن منها. إلا أنهم عادةً ما يطبقون الحد الأدنى فقط، مما أدى إلى وفرة من التطبيقات شبه المتوافقة، وفي النهاية، إلى تقسيم اسم "YMODEM" إلى "XMODEM-1K" ومجموعة متنوعة من بروتوكولات YMODEM. وهكذا، فإن XMODEM-1K صدر بعد YMODEM، ولكنه ظل شائعًا إلى حد ما.

مودم

NMODEM هو بروتوكول لنقل الملفات طوّره إل بي نيل، الذي أصدره عام 1990. يُعدّ NMODEM في جوهره نسخةً من XMODEM-CRC، يستخدم كتلًا أكبر حجمًا تبلغ 2048 بايت، بدلًا من كتل XMODEM التي تبلغ 128 بايت. تمّ تنفيذ NMODEM كبرنامج منفصل، مكتوب بلغة Turbo Pascal 5.0 لأجهزة الكمبيوتر المتوافقة مع عائلة IBM PC . تمّ اختيار حجم الكتلة ليتوافق مع حجم الكتلة الشائع في نظام ملفات MS-DOS FAT على محركات الأقراص الصلبة الحديثة ، مما يُسهّل تخزين البيانات مؤقتًا للكتابة. [ 13 ] [ 14 ]

انتحال البروتوكول

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

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

يجب مقارنة هذا المفهوم بالمفهوم المستخدم في بروتوكول SEAlink، الذي يُغيّر سلوك كلا طرفي الاتصال. ففي SEAlink، يتوقف المُستقبِل عن إرسال البيانات ACKتمامًا، ويُغيّر المُرسِل سلوكه بحيث لا يتوقعها.

انظر أيضاً

مراجع

الاقتباسات

  1. ↑ الاتصالات: إكس مودم: ولادة معيار ، بقلم ألفريد جلوسبرينر، مجلة بي سي، 17 أبريل 1984، الصفحات 451-452، ... ولكن البروتوكول نفسه كان قد أُتيح للعموم منذ زمن طويل من قِبل مُبتكره، وارد كريستنسن من شيكاغو. منذ تقديمه في عام 1978، إكس مودم ...
  2. ↑ في دائرة الضوء: درس في التاريخ: برنامج التبادل الحر المجاني لوارد كريستنسن ، بقلم مايكل سوين، إنفوورلد، 1 نوفمبر 1982، الصفحة 26
  3. ↑ وارد كريستنسن، "ذكريات" ، 25 نوفمبر 1992
  4. 1 2 3 4 5 6 7 ميكس، بروك (فبراير 1989). "مبادئ مودمات X وY وZ" . بايت . الصفحات 163-166 . تاريخ الاسترجاع: 8 أكتوبر 2024 . 
  5. ↑ "المجتمع الافتراضي" .
  6. ↑ كلاين، ديفيد (يوليو 1982). "أوزبورن - خلف خطوط حرب العصابات" . الحوسبة المصغرة . ص 42-50 . تم الاطلاع عليه بتاريخ 15 فبراير 2016 . 
  7. ↑ بورنيل، جيري (يوليو 1983). "محركات بين النجوم، وملحقات أوزبورن، وDEDICATE/32، ووادي الموت" . بايت . ص 334. تم الاطلاع عليه بتاريخ 28 أغسطس 2016 . 
  8. 1 2 3 بوش 1995 ، ص. G.1.
  9. ↑ كريستنسن 1982 .
  10. ↑ فورسبيرج 1986 .
  11. 1 2 3 4 5 6 7 بوسويل 1986 .
  12. 1 2 3 4 SEAlink 1987 .
  13. ↑ "برنامج NMODEM 1.12 وشفرته المصدرية" . مؤرشف من الأصل بتاريخ 7 أغسطس 2011. تم الاطلاع عليه بتاريخ 13 فبراير 2020 .
  14. ↑ "وثائق NMODEM" . مؤرشفة من الأصل بتاريخ 2016-04-09 . تم الاطلاع عليها بتاريخ 2020-02-13 .

فهرس