Das ZMODEM-Protokoll verstehen

Question

Ich muss grundlegende Datei-Sending- und Datei-Empfangsroutinen in mein Programm aufnehmen, und es muss über das ZMODEM-Protokoll liegen. Das Problem ist, dass ich Schwierigkeiten habe, die Spezifikation zu verstehen.

als Referenz, Hier ist die Spezifikation .

Die spec definiert nicht die verschiedenen Konstanten, also ist also hier eine Header-Datei von Google .

Es scheint mir, als ob es viele wichtige Dinge gibt, die in diesem Dokument nicht definiert sind:

.
• es bezieht sich ständig auf ZDDE-Codierung, aber was ist es? Wenn genau ich es benutze, benutze ich es, und wann benutze ich es nicht?
• Nach einem ZFILE-Datenrahmen werden die Metadaten der Datei (Dateiname, Datum, Größe usw.) der Datei übertragen. Es folgt ein ZCRCW-Block und dann ein Block, dessen Typ nach der Spezifikation nicht definiert ist. Der ZCRCW-Block enthält angeblich ein 16-Bit-CRC, aber die Spezifikation definiert nicht, welche Daten der CRC berechnet werden.
• Es definiert nicht das CRC-Polynom, das er verwendet. Ich habe zufällig herausgefunden, dass das CRC32-Poly der Standard CRC32 ist, aber ich hatte kein solches Glück mit dem CRC16-Poly. Niemals, ich habe es durch Versuch und Irrtum gefunden. Das CRC16-Poly ist 0x1021.

  Ich habe mich nach Referenzcode umgesehen, aber alles, was ich finden kann, sind nicht lesbare, undokumentierte C-Dateien aus den frühen 90er Jahren. Ich habe diesen Satz von Dokumenten von der MSDN auch gefunden, aber es ist schmerzlich vage und widersprüchlich, um zu testen, dass ich ausgeführt habe: http://msdn.microsoft.com/en-us/library/ms817878.aspx (Möglicherweise müssen Sie möglicherweise über Googles Cache )

  Um meine Schwierigkeiten zu veranschaulichen, ist hier ein einfaches Beispiel. Ich habe auf dem Server eine Klartextdatei erstellt, die " Hallo World! ", Und es heißt hellowerD.txt.

  Ich initiiere den Transfer vom Server mit dem folgenden Befehl: generasacodicetagpre.

  Dadurch wird der Server aufgefordert, den folgenden ZRQinit-Rahmen zu senden: generasacodicetagpre.

  Drei Probleme mit diesem:

  .
  • sind die Polsterbytes (0x2a) willkürlich? Warum gibt es hier zwei, aber in anderen Fällen gibt es nur einen und manchmal keine?
  • Die Spec erwähnt am Ende nicht den [CR] [CR] [LF] [XON], aber der MSDN-Artikel tut. Warum ist es da?
  • Warum hat das [LF] Bit 0x80 eingestellt?

    Danach muss der Client einen Zrinit-Rahmen senden. Ich habe das aus dem MSDN-Artikel erhalten: generasacodicetagpre.

    Zusätzlich zum Thema [LF] 0x80 habe ich zwei weitere Probleme:

    .
    • Warum ist [xon] diesmal nicht inbegriffen?
    • ist der CRC, der auf den Binärdaten oder den ASCII-HEX-Daten berechnet wird? Wenn es auf den binären Daten ist, bekomme ich 0x197c, und wenn es auf den ASCII-Hex-Daten ist, bekomme ich 0xF775; Keiner davon ist eigentlich im Rahmen (0xBE50). RE Im ASCII-HEX-Modus ist es der CRC dessen, was durch die ASCII-Hex-Zeichen dargestellt wird.)

      Der Server antwortet mit einem ZFILE-Rahmen: generasacodicetagpre.

      ok. Dieser macht Sinn. Wenn ich die CRC32 von [04 00 00 00 00] berechne, bekomme ich tatsächlich 0x33a251dd. Aber jetzt haben wir am Ende keine [CR] [LF] [xon]. Warum ist das?

      Unmittelbar nach diesem Frame sendet der Server auch die Metadaten der Datei: generasacodicetagpre.

      Dies hat nicht einmal einen Header, es springt nur direkt an die Daten. Ok, ich kann damit leben. Jedoch:

      .
      • Wir haben unseren ersten mysteriösen ZCRCW-Rahmen: [18 6b]. Wie lang ist dieser Rahmen? Wo sind die CRC-Daten und ist es CRC16 oder CRC32? Es ist nirgendwo in der Spezifikation definiert.
      • Der MSDN-Artikel gibt an, dass [18 6b] [00] folgen sollte, aber es ist nicht.
      • Dann haben wir einen Rahmen mit einem undefinierten Typ: [18 50 D3 0F F1 11]. Ist das ein separater Rahmen oder ist es Teil von ZCRCW?

        Der Client muss mit einem Zrpos-Rahmen reagieren, der erneut vom MSDN-Artikel entnommen wird: generasacodicetagpre.

        Gleiche Probleme wie beim ZrinIT-Frame: Der CRC ist falsch , der [LF] hat Bit 0x80 eingestellt, und es gibt keine [xon].

        Der Server antwortet mit einem Zdata-Frame: generasacodicetagpre.

        Gleiche Probleme wie ZFILE: Der CRC ist alles in Ordnung, aber wo ist der [CR] [LF] [xon]?

        Danach sendet der Server die Nutzlast der Datei. Da dies ein kurzes Beispiel ist, passt es in einen Block (max. Größe beträgt 1024): generasacodicetagpre.

        Von dem, was der Artikel zu erwähnen scheint, werden Nutzlasten mit [ZDLE] entkommt. Wie übertrage ich also ein Payload-Byte, das zufällig mit dem Wert von [ZDLE] entspricht? Gibt es noch andere Werte?

        Der Server endet mit diesen Frames: generasacodicetagpre.

        Ich bin am ersten völlig verloren. Das sekone.

D macht so viel Sinn wie die Zrinit- und Zdata-Frames.

Answer 1

meine Kumpel Wunder, wenn Sie eine Zeit implementieren Maschine.

Ich weiß nicht, dass ich alle Ihre Fragen beantworten kann - ich habe es nie Musste eigentlich ZMODEM selbst implementieren - aber hier sind nur wenige Antworten:

Aus dem, was der Artikel zu erwähnen scheint, werden Nutzlasten mit entkommen [Zdle]. Wie überträgt ich also ein Payload-Byte, das mit der Wert von [zdle]? Gibt es noch andere Werte?

Dies wird explizit in dem von Ihnen verbundenen Dokument angesprochen Beginn Ihrer Fragen, die sagt: generasacodicetagpre.

es bezieht sich ständig auf ZDLE-Codierung, aber was ist das? Wann genau Benutze ich es, und wann benutze ich es nicht?

In den alten Tagen wurden bestimmte "Steuerzeichen" verwendet, um das zu steuern Kommunikationskanal (daher der Name). Zum Beispiel das Senden von XON / XOFF Zeichen können die Übertragung anhalten. ZDE wird verwendet, um zu entkommen Zeichen, die problematisch sein können. Nach der Spezifikation sind dies Die Zeichen, die standardmäßig entkommen sind: generasacodicetagpre.

Ich habe sich nach Referenzcode umgesehen, aber alles, was ich finden kann, sind nicht lesbare, undokumentierte C-Dateien aus den frühen 90er Jahren.

enthält dies den Code für das lrzsz Paket? Das ist still in den meisten Linux-Distributionen (und überraschend handlich) weitgehend verfügbar zum Übertragen von Dateien über eine etablierte SSH-Verbindung).

Es gibt eine Reihe anderer Implementierungen, einschließlich Mehrere in der Software auf Freecode , einschließlich qodem , syncted , mbse , und andere. Ich glaube an das syncterm Die Implementierung ist als Bibliothek geschrieben, die möglicherweise angemessen sein kann von Ihrem eigenen Code verwenden (aber ich bin nicht sicher).

Sie können zusätzlichen Code finden, wenn Sie um ältere Sammlungen von stecken MS-DOS-Software.

Answer 2

Ich kann dich nicht beschuldigen. Das Benutzerhandbuch ist nicht auf benutzerfreundliche Weise organisiert

sind die Polsterbytes (0x2a) willkürlich?

nein, ab Seite 14,15:

Eine binäre Header beginnt mit der Sequenz ZPAD, ZDE, ZBIN.

Ein Hex-Header beginnt mit der Sequenz ZPAD, ZPAD, ZDE, Zhex.

.

Die Spezifikation erwähnt am Ende nicht den [CR] [CR] [LF] [XON], aber der MSDN-Artikel tut. Warum ist es da?

Seite 15

* * ZDDE B Typ F3 / P0 F2 / P1 F1 / P2 F0 / P3 CRC-1 CRC-2 CR LF XON . Warum hat das [LF] Bit 0x80 eingestellt?

Nicht sicher. Ab Tera-Term bekam ich beide Steuerzeichen mit 0x80 (8D 8A 11)

Wir haben unseren ersten mysteriösen ZCRCW-Rahmen: [18 6b]. Wie lang ist dieser Rahmen? Wo sind die CRC-Daten und ist es CRC16 oder CRC32? Es ist nirgendwo in der Spezifikation definiert.

Der ZCRCW ist kein Header oder ein Frame-Typ, es ist eher eine Fußzeile, die dem Empfänger sagt, was als nächstes erwartet wird. In diesem Fall ist es die Fußzeile des Daten-Subpakets mit dem Dateinamen. Es wird eine 32-Bit-Prüfsumme sein, da Sie einen Binärkopf "C" verwenden.

.
• zddel c typ f3 / p0 f2 / p1 f1 / p2 f0 / p3 crc-1 crc-2 crc-3 crc-4

  .

  Dann haben wir einen Rahmen mit einem undefinierten Typ: [18 50 D3 0F F1 11]. Ist dies ein separater Rahmen oder ist es Teil von ZCRCW?

  Das ist der CRC für die ZCRCW-Daten-Subpacket. Es sind 5 Bytes, da der erste 0x10 ist, ein Steuerzeichen, das ZDDE entkommen muss. Ich bin nicht sicher, was 0x11 ist.

  und es gibt nein [xon].

  xon ist nur für Hex-Header. Sie verwenden es nicht für einen binären Kopf.

  .
  • zddel A Typ F3 / P0 F2 / P1 F1 / P2 F0 / P3 CRC-1 CRC-2 . Wie überträgt ich also ein Payload-Byte, das zufällig mit dem Wert von [ZDLE] entspricht?

    18 58 (aka zdnee)

    18 68 05 DE 02 18 D0

    Das ist die Fußzeile des Datenunterrahmens. Die nächsten 5 Bytes sind die CRC (letzter Byte ist ZDE-codiert)