فهم بروتوكول zmodem

Question

أحتاج إلى تضمين إجراءات إرسال واستقبال الملفات الأساسية في البرنامج، ويجب أن يكون من خلال بروتوكول ZMODEM. المشكلة هي أنني أواجه مشكلة في فهم المواصفات.

للرجوع اليها، هنا هو المواصفات .

المواصفات لا تحدد الثوابت المختلفة، لذلك هنا ملف رأس من Google .

يبدو لي مثل هناك الكثير من الأشياء المهمة التي تركت غير محددة في تلك الوثيقة:

• يشير باستمرار إلى ترميز zdle، ولكن ما هو؟ عندما استخدمه بالضبط، وعندما لا أستخدمها؟
• بعد إطار بيانات zfile، يتم نقل بيانات التعريف الخاصة بالملف (اسم الملف، تعديل التاريخ والحجم وما إلى ذلك). يتبع ذلك كتلة ZCRCW ثم كتلة من نوعها غير محدد وفقا للمواصفات. يزعم كتلة ZCRCW التي تحتوي على اتفاقية حقوق الطفل 16 بت، ولكن المواصفات لا تحدد البيانات التي يتم حسابها في CRC.
• لا يعرف استخدام اتفاقية حقوق الطفل CRC. اكتشفت بالصدفة أن بولي CRC32 هو CRC32 القياسي، لكنني لم يكن لدي حظ من هذا القبيل مع بولي CRC16. nevermind، وجدت ذلك من خلال التجربة والخطأ. بولي CRC16 هو 0x1021.

  لقد بحثت حولها للحصول على التعليمات البرمجية المرجعية، ولكن كل ما يمكنني العثور عليه غير قابل للقراءة، وملفات ج غير موثوق بها من أوائل التسعينيات. لقد وجدت أيضا مجموعة المستندات هذه من MSDN، لكنها غامضة مؤلمة ومتناقضة لاختبارات التي قمت بتشغيلها: http://msdn.microsoft.com/en-us/library/ms817878.aspx (قد تحتاج إلى عرض ذلك من خلال ذاكرة التخزين المؤقت ل Google )

  لتوضيح صعوباتي، إليك مثال بسيط. لقد قمت بإنشاء ملف Plantext على الخادم الذي يحتوي على "؛ مرحبا العالم! "، ويطلق عليه Helloworld.txt.

  يمكنني بدء التحويل من الخادم مع الأمر التالي: giveacodicetagpre.

  يطالب هذا الخادم بإرسال إطار ZRQINIT التالي التالي: giveacodicetagpre.

  ثلاثة مشاكل مع هذا:

  • هي البايت الحشو (0x2a) التعسفي؟ لماذا هناك اثنين هنا، ولكن في حالات أخرى هناك واحد فقط، وأحيانا لا شيء؟
  • لا تذكر المواصفات [CR] [LF] [Xon] في النهاية، ولكن مقالة MSDN لا. لماذا هناك؟
  • لماذا يحتوي [LF] على مجموعة 0x80؟

    بعد ذلك، يحتاج العميل إلى إرسال إطار Zrinit. حصلت على هذا من مقالة MSDN: giveacodicetagpre.

    بالإضافة إلى مشكلة العلم [LF] 0x80، لدي مشكلتان آخران:

    • لماذا لا [شون] تضمنت هذه المرة؟
    • هل تحسب CRC على البيانات الثنائية أو بيانات Hex ASCII؟ إذا كانت موجودة في البيانات الثنائية، أحصل على 0x197c، وإذا كانت موجودة في بيانات HEX ASCII، أحصل على 0xf775؛ لا أحد من هؤلاء هو ما هو في الواقع في الإطار (0xbe50). (حل؛ يتبع أي الوضع الذي تستخدمه. إذا كنت في وضع BIN أو BIN32، فهذا هو CRC من البيانات الثنائية. اذا أنت إعادة في وضع ASCII HEX، إنها CRC من ما يمثله أحرف أسكي عرافة.)

      يبحث الخادم بإطار zfile: giveacodicetagpre.

      حسنا. هذا واحد المنطقي. إذا قمت بحساب CRC32 من [04 00 00 00 00 00]، فأنا في الواقع تحصل على 0x33A251DD. ولكن الآن ليس لدينا أي [CR] [LF] [شون] في النهاية. لماذا هذا؟

      مباشرة بعد هذا الإطار، يرسل الخادم أيضا بيانات التعريف: giveacodicetagpre.

      هذا لا يحتوي على رأس، فإنه يقفز فقط مباشرة إلى البيانات. حسنا، يمكنني العيش مع ذلك. ومع ذلك:

      • لدينا أول إطار ZCRCW الغامض: [18 6B]. كم من الوقت هذا الإطار؟ أين هي بيانات CRC، وهي هي CRC16 أو CRC32؟ إنه غير محدد في أي مكان في المواصفات.
      • تحدد مقالة MSDN أن [00 6B] يجب أن يتبعها [00]، لكنها ليست كذلك.
      • ثم لدينا إطار مع نوع غير محدد: [18 50 D3 0F F1 11]. هل هذا إطار منفصل أم هو جزء من ZCRCW؟

        يحتاج العميل إلى الاستجابة مع إطار ZRPOS، مرة أخرى مأخوذة من مقالة MSDN: giveacodicetagpre.

        نفس المشكلات كما هو الحال مع إطار Zrinit: CRC خطأ ، يحتوي [LF] على مجموعة 0x80، وليس هناك [xon].

        يبحث الخادم بإطار ZDATA: giveacodicetagpre.

        نفس المشكلات مثل zfile: CRC كل شيء على ما يرام، ولكن أين هو [CR] [LF] [XON]؟

        بعد هذا، يرسل الخادم حمولة الملف. نظرا لأن هذا مثال قصير، فإنه يناسب في كتلة واحدة (أقصى حجم 1024): giveacodicetagpre.

        من ما يبدو أن المقالة مذكورة، يتم هرب الحمولات مع [zdle]. إذن كيف أحيل بايت الحمولة التي تحدث لتتناسب مع قيمة [zdle]؟ هل هناك أي قيم أخرى مثل هذا؟

        ينتهي الخادم بهذه الإطارات: giveacodicetagpre.

        أنا ضائع تماما في أول واحد. secon.

D يجعل من المعنى بقدر إطارات Zrinit و ZDATA.

Answer 1

عجائب صديقي إذا كنت تنفذ وقتا آلة.

لا أعرف أنني أستطيع الإجابة على جميع أسئلتك - أنا أبدا في الواقع اضطرت لتنفيذ zmodem نفسي - ولكن هنا عدد قليل من الإجابات:

من ما يبدو أن المقالة مذكورة، يتم الضغط على الحمولات [zdle]. إذن كيف أحيل بايت الحمولة التي تحدث لمطابقة قيمة [zdle]؟ هل هناك أي قيم أخرى مثل هذا؟

يتم تناول هذا بشكل صريح في المستند الذي ترتبط به عند بداية أسئلتك، والتي تقول: giveacodicetagpre.

يشير باستمرار إلى ترميز zdle، ولكن ما هذا؟ متى بالضبط هل يمكنني استخدامها، وعندما لا أستخدمها؟

في الأيام الخوالي، تم استخدام بعض "أحرف التحكم" للسيطرة على قناة الاتصالات (وبالتالي الاسم). على سبيل المثال، إرسال xon / xoff الأحرف قد تؤخر الإرسال. يستخدم zdle للهروب الأحرف التي قد تكون مشكلة. وفقا للمواصفات، هذه هي الأحرف التي يتم هربها افتراضيا: giveacodicetagpre.

نظرت حولها للحصول على التعليمات البرمجية المرجعية، ولكن كل ما يمكنني العثور عليه ملفات ج غير موثوقة غير موثوقة من أوائل التسعينيات.

هل يشتمل ذلك على رمز LRZSZ الحزمة؟ هذا لا يزال متاح على نطاق واسع في معظم توزيعات Linux (ومفيد بشكل مدهش لنقل الملفات عبر اتصال SSH المنشأة).

هناك عدد من التطبيقات الأخرى هناك، بما في ذلك العديد من البرامج المدرجة على freecode ، بما في ذلك QODEM ، syncterm ، MBSE و اخرين. أعتقد أن syncterm التنفيذ مكتوبة كمكتبة قد تكون سهلة معقولة لاستخدامها من التعليمات البرمجية الخاصة بك (ولكنني لست متأكدا).

قد تجد رمز إضافي إذا كنت تدفق حول مجموعات أقدم من برنامج MS-DOS.

Answer 2

لا أستطيع إلقاء اللوم عليك. لم يتم تنظيم دليل المستخدم بطريقة سهلة الاستخدام

هل البايتات الحشو (0x2a) التعسفي؟

لا، من صفحة 14،15:

يبدأ رأس ثنائي مع تسلسل ZPAD، ZDLE، ZBIN.

يبدأ رأس عرافة بتسلسل ZPAD، ZPAD، ZDLE، ZHEX.

.

لا تذكر المواصفات [CR] [LF] [Xon] في النهاية، ولكن مقالة MSDN لا. لماذا هناك؟

الصفحة 15

* * zdle b type f3 / p0 f2 / p1 f1 / p2 f0 / p3 crc-1 crc-2 cr lf xon وبعد لماذا تحتوي [LF] بتاريخ 0x80؟

غير متأكد. من مصطلح TERA حصلت على كل من شخصيات التحكم xored مع 0x80 (8D 8A 11)

لدينا أول إطار zcrcw الغامض: [18 6B]. كم من الوقت هذا الإطار؟ أين هي بيانات CRC، وهي هي CRC16 أو CRC32؟ لم يتم تعريفه في أي مكان في المواصفات.

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

• zdle c type f3 / p0 f2 / p1 f1 / p2 f0 / p3 crc-1 crc-2 crc-3 crc-4

  .

  ثم لدينا إطار مع نوع غير محدد: [18 50 D3 0F F1 11]. هل هذا إطار منفصل أم هو جزء من ZCRCW؟

  هذا هو CRC للتأكد من التأكد من بيانات ZCRCW. انها 5 بايت لأن أول واحد هو 0x10، حرف تحكم يحتاج إلى أن يكون هرب zdle. لست متأكدا من 0x11 هو.

  وليس هناك [xon].

  xon هو فقط لرؤوس عرافة. أنت لا تستخدمه لرأس ثنائي.

  • zdle type f3 / p0 f2 / p1 f1 / p2 f0 / p3 crc-1 crc-2 وبعد إذن كيف أحيل بايت الحمولة التي تحدث لتتناسب مع قيمة [zdle]؟

    18 58 (المعروف أيضا باسم Zlete)

    18 68 05 de 02 18 d0

    هذا هو تذييل الصفحة الفرعية للبيانات. البايتات الخمس القادمة هي CRC (البايت الأخير هو ZDLE WORDED)