Zモデム

ZMODEM は、1986 年にChuck Forsbergによって開発されたインラインファイル転送プロトコルです。このプロジェクトはTelenetの資金提供を受け、X.25ネットワークでのファイル転送を改善するために実施されました。ZMODEM は、従来のプロトコルに比べて大幅に改善されたパフォーマンスに加え、再開可能な転送、送信側による自動開始、拡張された 32 ビットCRC、および8 ビットのクリーン転送をサポートする制御文字引用を提供し、制御文字を渡さないネットワークでも使用できるようになりました。

掲示板システム(BBS)用に開発されたほとんどの転送プロトコルとは対照的に、 ZMODEM は、独創的なXMODEM を直接ベースにしておらず、互換性もありませんでした。 XMODEM の 1 つ以上の欠点に対処するために、多くの XMODEM の派生版が開発され、そのほとんどは下位互換性が維持され、「従来の」 XMODEM 実装で正常に転送を完了できました。 このリストには、Forsberg 独自のYMODEMが含まれています。

ZMODEM は、下位互換性を捨てて、大幅に改善されたプロトコルを生み出しました。このプロトコルは、XMODEM の高性能バージョンと同等以上のパフォーマンスを発揮し、X.25 のように以前はまったく機能しなかったリンクや、Telebitモデムのようにパフォーマンスが低かったリンクでも機能し、他のプロトコルにはほとんど見られない便利な機能も備えていました。ZMODEM は、1990 年代初頭に電子掲示板システム(BBS)で非常に人気を博し、それ以前の XMODEM と同じくらい広く普及した標準となりました。

一般的に、ファイル転送プロトコルは、ファイルを一連のパケットに分割し、それらを 1 つずつ受信側に送信します。パケットの主要部分であるペイロードは、送信されるファイルからの特定のバイト数です。ペイロードの後に​​は、ペイロードが正しく受信されたかどうかを判断するために使用できるチェックサムまたは巡回冗長検査(CRC) が続きます。パケットが正しく受信された場合、受信側はACKメッセージ を送信し、送信側は次のパケットの送信を開始します。

電話システムでは、このプロセスを妨げるレイテンシと呼ばれる小さな遅延が発生します。受信側がACK をすぐに送信したとしても、電話回線の遅延により、送信側が ACK を受信して​​次のパケットを送信するまでに必ず時間がかかります。モデムの速度が上がると、この遅延により、遅延中に送信できたはずのパケットの数がますます大きくなり、チャネル効率が低下します。

XMODEM は 128 バイトのペイロード、3 バイトのヘッダー、1 バイトのチェックサムを使用して、パケットあたり合計 132 バイトを使用しました。300 ビット/秒のモデムの時代では、パケットの送信に約 4 秒かかり、典型的な遅延は1 ⁄ 10秒程度であったため、パフォーマンスのオーバーヘッドはそれほど大きくありませんでした。速度が上がると、問題はより深刻になります。2400 ビット/秒では、パケットの送信に約 0.55 秒かかるため、使用可能な帯域幅の約1 ⁄ 5がACKを待つために無駄になります。9600 ビット/秒では、パケットの送信に 0.13 秒しかかからないため、帯域幅の約1 ⁄ 2 が無駄になります。

この問題の解決策の 1 つは、スライディング ウィンドウを使用することです。これらのプロトコルは、送信者がACKを待たずにパケットの送信を継続できるようにすることで、遅延に対処します。継続できるパケットの数が「ウィンドウ」であり、ほとんどの実装では通常 2 ～ 16 パケットです。スライディング ウィンドウをサポートする XMODEM の新しいバージョンがいくつか 1980 年代初頭に登場しました。

スライディング ウィンドウは、従来の電話回線の XMODEM の場合のように、数パケット長程度の遅延には有効です。ただし、遅延が 1 秒以上になる、海外通話、衛星接続、またはPC Pursuitなどの X.25 サービスで見られる、より長い遅延に対処するには十分ではありません。TelebitやUS Roboticsモデムの場合のように、リバース チャネルが送信チャネルよりはるかに遅い場合、少数のACKであっても、返信チャネルを圧倒し、転送が一時停止する可能性があります。

ZMODEM は、 ACKの必要性をまったくなくすことでこれらの問題に対処し、受信側がエラーを検出しない限り、送信側はデータを継続的に送信できるようにしました。問題が発生した場合のみ、 NAKのみを送信する必要があります。ZMODEM は、X.25 などのエラー訂正機能が組み込まれたリンクで使用されることが多かったため、受信側は送信側に 1 つのメッセージも返さないことがよくありました。その結果、システムはファイル全体を継続的なストリームで送信することになり、ZMODEM は「ストリーミング プロトコル」と呼ばれていました。

ZMODEM のパフォーマンスは、以前の一般的なプロトコルに比べて大幅に改善されたため、エラー訂正がまったくなく、モデムによって維持されるエラーのないリンクに依存するYMODEM-gなどの特殊なプロトコルも置き換えられました。YMODEM-g は高速であったため「パワー ユーザー」の間で人気がありましたが、再開可能な転送などの他の機能がないため、あまり魅力的ではありませんでした。

XMODEM およびそれに基づくほとんどのプロトコルは、データに 1 ～ 255 のパケット番号をプレフィックスとして付加することでパケットの順序を管理していました。ウィンドウ バージョンでは、このパケット番号を使用して、正常に受信されたパケット、または正常に受信されなかったパケットを示していました。パケットの長さは 128 バイトであったため、パケット番号がロールオーバーする前に転送できるデータの最大量は 32 KB でした。

ZMODEM は、パケット番号を、32 ビットの数値で示されるファイル内の実際の場所に置き換えました。これにより、ファイルの長さに関係なく、転送を失敗したポイントまで巻き戻すNAKメッセージを送信できるようになりました。この同じ機能は、転送が失敗した場合や意図的に中断された場合に転送を再開するためにも使用されました。この場合、受信側は以前に受信したデータの量を確認し、その場所をNAKで送信して、送信側がそのポイントから開始するように自動的にトリガーします。

自動開始により、送信マシンが転送を開始できるようになり、管理が簡素化されました。以前は、ユーザーはまず送信者にファイルを要求し、ファイルを「待機」状態にしてから、ローカル プログラムに戻って転送を開始するコマンドを呼び出す必要がありました。自動転送では、ファイルを要求するだけで、送信者がユーザーのプログラムで自動的に転送を開始します。

ZMODEM の修正版が数多く登場しました。ZedZap は、高速モデムでのパフォーマンス向上を目的とした 8 KB ブロックの ZMODEM の亜種です。LeechZmodem は、BBS のダウンロード クォータを不正に操作する悪質な ZMODEM の亜種 (類似の XMODEM および YMODEM 派生版の 1 つ) です。ADONTEC は、2002 年と 2007 年に、 ISDNやTCP/IPネットワークなどの高速でエラーのない接続でのパフォーマンス向上を目的とした、32 KB および 64 KB ブロック長の ZMODEM の下位互換性のある拡張機能を作成しました。

最も有名な ZMODEM 実装は、Chuck Forsberg の Omen Technology, Inc. によるものでした。これには、DSZ (DOS Send ZMODEM)、GSZ (Graphical Send ZMODEM)、およびUnixバリアントで広く使用されている (l)rzsz が含まれていました。

最近では、Synchronetの開発者がSEXYZ という最新の X/Y/ZMODEM 実装を作成しました。これは zmtx/zmrx パッケージを大まかにベースにしたものですが、Windowsおよび Unix の各種でネイティブに実行され、長いファイル名とより高速で信頼性の高いデータ転送をサポートします。SEXYZ の ZMODEM 実装も SyncTERM プロジェクトに組み込まれています。Synchronet、SEXYZ、SyncTERM はすべてオープン ソース、クロス プラットフォーム、BBS 中心のプロジェクトです。

Forsberg 自身が ZMODEM-90 にいくつかの改良を加えました。その最初の改良は MobyTurbo です。これは制御引用符を削除してパフォーマンスをさらに 15% ほど向上させました。制御文字を「消費」するネットワークでも、ZMODEM-90 はネットワークが実際に消費する文字のみを引用符で囲むように調整できます。すべての文字を引用符で囲む必要はありません。同様の改良により、ZMODEM-90 は 7 ビット ネットワークで動作できます。一方、以前のプロトコル ( Kermitを除く) はすべて、多かれ少なかれ 8 ビットを必要としていました。最後に、ZMODEM-90 には基本的なランレングス エンコーディング圧縮システムが含まれており、圧縮されていないファイルのパフォーマンスをさらに向上させます。

• 一部の ZMODEM パケット (ZACK、ZRPOS など) は、転送されたファイル内に 32 ビットの符号なし整数としてバイト オフセットを埋め込みます。この設計により、ZMODEM の実現可能性は 4 GB 未満のファイルのみを確実に転送するように制限されます。
• プロトコルが許可しているにもかかわらず、リファレンス (l)rzsz 実装では、telnetやsshなどの TCP/IP 接続プログラムでクライアント側の「端末エスケープ」文字としてよく使用される任意の非制御文字 (例: '~') をエンコードできません。ユーザーは、このようなリンクで信頼性の高い転送を行うために、端末エスケープ機能を無効にする必要があります (例: ssh -e none user@hostname)。

• ZMODEM アプリケーション間ファイル転送プロトコル
• Synchronet 外部 X/Y/Zmodem (SEXYZ) ファイル転送プロトコル ドライバー

• ファイル転送プロトコルの進化と選択