15

プログラムに基本的なファイル送信ルーチンとファイル受信ルーチンを含める必要があり、ZMODEM プロトコルを使用する必要があります。問題は、仕様を理解するのに苦労していることです。

参考までに、こちらが仕様です。

仕様ではさまざまな定数が定義されていないため、Google のヘッダー ファイルを次に示します。

そのドキュメントには未定義の重要なことがたくさんあるように私には思えます:

  • 常に ZDLE エンコーディングについて言及していますが、それは何ですか? 正確にいつ使用し、いつ使用しないのですか?
  • ZFILE データ フレームの後、ファイルのメタデータ (ファイル名、変更日、サイズなど) が転送されます。これに ZCRCW ブロックが続き、次に仕様に従って型が定義されていないブロックが続きます。ZCRCW ブロックには 16 ビットの CRC が含まれていると言われていますが、仕様では CRC が計算されるデータについて定義されていません。
  • 使用する CRC 多項式を定義しません。CRC32 ポリが標準の CRC32 であることを偶然知りましたが、CRC16 ポリではそのような運がありませんでした。気にしないで、試行錯誤して見つけました。CRC16 ポリは 0x1021 です。

参照コードを探してみましたが、90 年代初頭の判読不能で文書化されていない C ファイルしか見つかりませんでした。MSDN からこの一連のドキュメントも見つけましたが、非常に曖昧で、実行したテストと矛盾しています: http://msdn.microsoft.com/en-us/library/ms817878.aspx (必要な場合があります) Google のキャッシュを介してそれを表示するには)

私の困難を説明するために、ここに簡単な例を示します。「Hello world!」を含むプレーンテキスト ファイルをサーバー上に作成しました。これは helloworld.txt という名前です。

次のコマンドを使用して、サーバーからの転送を開始します。

sx --zmodem helloworld.txt

これにより、サーバーは次の ZRQINIT フレームを送信するように求められます。

2A 2A 18 42 30 30 30 30 30 30 30 30 30 30 30 30   **.B000000000000
30 30 0D 8A 11                                    00.Š.

これに関する3つの問題：

  • パディング バイト (0x2A) は任意ですか? なぜここには 2 つあるのに、1 つしかない場合もあれば、まったくない場合もあるのですか?
  • 仕様では最後に [CR] [LF] [XON] について言及されていませんが、MSDN の記事では言及されています。なぜそこにあるのですか？
  • [LF] にビット 0x80 が設定されているのはなぜですか?

この後、クライアントは ZRINIT フレームを送信する必要があります。MSDNの記事からこれを入手しました：

2A 2A 18 42 30 31 30 30 30 30 30 30 32 33 62 65   **.B0100000023be
35 30 0D 8A                                       50.Š

[LF] 0x80 フラグの問題に加えて、さらに 2 つの問題があります。

  • 今回はなぜ【XON】が入っていないのですか？
  • CRC はバイナリ データまたは ASCII 16 進データで計算されますか? バイナリ データの場合は 0x197C を取得し、ASCII 16 進データの場合は 0xF775 を取得します。これらはどちらも、実際にフレーム (0xBE50) にあるものではありません。(解決済み。使用しているモードに依存します。BIN または BIN32 モードの場合は、バイナリ データの CRC です。ASCII 16 進モードの場合は、ASCII 16 進文字で表されるものの CRC です。 .)

サーバーは ZFILE フレームで応答します。

2A 18 43 04 00 00 00 00 DD 51 A2 33               *.C.....ÝQ¢3

わかった。これは理にかなっています。[04 00 00 00 00] の CRC32 を計算すると、確かに 0x33A251DD が得られます。しかし、今では最後に [CR] [LF] [XON] がありません。どうしてこれなの？

このフレームの直後に、サーバーはファイルのメタデータも送信します。

68 65 6C 6C 6F 77 6F 72 6C 64 2E 74 78 74 00 31   helloworld.txt.1
33 20 32 34 30 20 31 30 30 36 34 34 20 30 20 31   3 240 100644 0 1
20 31 33 00 18 6B 18 50 D3 0F F1 11                13..k.PÓ.ñ.

これにはヘッダーさえありません。データに直接ジャンプするだけです。OK、私はそれで暮らすことができます。でも：

  • 最初の謎の ZCRCW フレーム [18 6B] があります。このフレームの長さは？CRC データはどこにあり、CRC16 または CRC32 ですか? 仕様のどこにも定義されていません。
  • MSDN の記事では、[18 6B] の後に [00] が続くように指定されていますが、そうではありません。
  • 次に、[18 50 D3 0F F1 11] という未定義のタイプのフレームがあります。これは別のフレームですか、それとも ZCRCW の一部ですか?

クライアントは、再び MSDN の記事から引用した ZRPOS フレームで応答する必要があります。

2A 2A 18 42 30 39 30 30 30 30 30 30 30 30 61 38   **.B0900000000a8
37 63 0D 8A                                       7c.Š

ZRINIT フレームと同じ問題: CRC が間違っている、[LF] にビット 0x80 が設定されている、[XON] がない。

サーバーは ZDATA フレームで応答します。

2A 18 43 0A 00 00 00 00 BC EF 92 8C               *.C.....¼ï’Œ

ZFILE と同じ問題: CRC は問題ありませんが、[CR] [LF] [XON] はどこにありますか?

この後、サーバーはファイルのペイロードを送信します。これは短い例なので、1 つのブロックに収まります (最大サイズは 1024 です)。

48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0A            Hello world!.

記事が言及しているように見えることから、ペイロードは [ZDLE] でエスケープされます。では、たまたま [ZDLE] の値と一致するペイロード バイトを送信するにはどうすればよいでしょうか。このような他の値はありますか？

サーバーは次のフレームで終了します。

18 68 05 DE 02 18 D0                              .h.Þ..Ð
2A 18 43 0B 0D 00 00 00 D1 1E 98 43               *.C.....Ñ.˜C

私は最初のもので完全に迷っています。2 番目は、ZRINIT および ZDATA フレームと同じくらい理にかなっています。

4

2 に答える 2

7

私の相棒は、あなたがタイムマシンを実装しているかどうか疑問に思っています.

あなたのすべての質問に答えられるかどうかはわかりませんが、実際に自分で zmodem を実装する必要はありませんでした。

記事が言及しているように見えることから、ペイロードは [ZDLE] でエスケープされます。では、たまたま [ZDLE] の値に一致するペイロード バイトを送信するにはどうすればよいでしょうか。このような他の値はありますか？

これは、質問の冒頭でリンクしたドキュメントで明示的に対処されています。

The ZDLE character is special.  ZDLE represents a control sequence
of some sort.  If a ZDLE character appears in binary data, it is
prefixed with ZDLE, then sent   as ZDLEE.

常に ZDLE エンコーディングについて言及していますが、それは何ですか? 正確にいつ使用し、いつ使用しないのですか?

昔は、特定の「制御文字」が通信チャネルを制御するために使用されていました (そのため、この名前が付けられました)。たとえば、XON/XOFF 文字を送信すると、送信が一時停止する場合があります。ZDLE は、問題となる可能性のある文字をエスケープするために使用されます。仕様によると、これらはデフォルトでエスケープされる文字です。

ZMODEM software escapes ZDLE, 020, 0220, 021, 0221, 023, and 0223.
If preceded by 0100 or 0300 (@), 015 and 0215 are also escaped to
protect the Telenet command escape CR-@-CR.  The receiver ignores
021, 0221, 023, and 0223 characters in the data stream.

参照コードを探してみましたが、90 年代初頭の判読不能で文書化されていない C ファイルしか見つかりませんでした。

これにはlrzszパッケージのコードが含まれていますか? これは、ほとんどの Linux ディストリビューションでまだ広く利用できます (そして、確立された ssh 接続を介してファイルを送信するのに驚くほど便利です)。

qodem、 syncterm、MBSEなど、 freecodeにリストされているソフトウェアのいくつかを含め、他にも多くの実装があります。syncterm の実装は、独自のコードから簡単に使用できるライブラリとして記述されていると思います (ただし、確かではありません)。

MS-DOS ソフトウェアの古いコレクションを調べてみると、追加のコードが見つかる場合があります。

于 2012-03-14T20:54:16.213 に答える