Yモデム

YMODEM は、モデムを使用して相互に接続されたマイクロコンピュータ間で使用されるファイル転送プロトコルです。主に、掲示板システムとの間でファイルを転送するために使用されました。YMODEM は、 XMODEMの拡張としてChuck Forsbergによって開発され、最初にCP/M YAMプログラムに実装されました。当初は YAM としても知られていましたが、1985 年にオリジナルの XMODEM の作者であるWard Christensenによって正式に「YMODEM」という名前が付けられました。

YMODEM は、他の拡張 XMODEM のさまざまな機能を組み合わせて、XMODEM を 3 つの方法で拡張しました。XMODEM-CRC と同様に、YMODEM は 8 ビットのチェックサムを 16 ビットの巡回冗長検査(CRC) に置き換えましたが、オプションではなくデフォルトの訂正形式にしました。TeLink からは、ファイル名とサイズを送信する「ブロック 0」ヘッダーが追加され、バッチ転送 (1 回のセッションで複数のファイル) が可能になり、ファイルの末尾にパディングを追加する必要がなくなりました。最後に、YMODEM では、ブロック サイズを元の 128 バイトのデータから 1024 バイトに増やすことができました ( XMODEM-1kと同様) 。これにより、高速モデムでのスループットが大幅に向上しました。

Forsberg は、これらすべての機能をランタイム オプションとして標準を構築し、単一のプロトコル ドライバーが、YAM 以外のシステムに接続するときに XMODEM-CRC または XMODEM にフォールバックできるようにしました。彼は、プログラマーがこれらの機能を任意のプラットフォームで可能な限り多く実装したいと考えていました。彼は、実装の大部分が実際には CRC-16 で 1k ブロック サイズしか提供しておらず、YMODEM の名前を使い続けながら「ブロック 0」を実装していないことに落胆しました。その結果、相互に互換性のない YMODEM 実装が多数リリースされ、完全な標準をサポートするバージョンを明確に示すために YMODEM Batchという名前が使用されました。

オリジナルのXMODEM は非常に単純なプロトコルであり、それが成功の理由でした。当時のほぼすべてのマシンに実装でき、プロセッサとストレージが非常に限られているマシンにも実装できました。送信データを 128 バイトのパケットに分割し、3 バイトのヘッダーと 1 バイトのチェックサムフッターを追加して、結果として得られる 132 バイトのパケットを順番に送信することで動作しました。受信側のコンピューターは 128 バイトのデータからチェックサムを再計算し、フッターで送信されたチェックサムと一致した場合はACK を返し、一致しなかった場合はNAK を返します。送信側はACK を受信すると次のパケットを送信し、NAKを受信すると最後のパケットを再送信します。

このプロトコルには多くの問題がありました。単純なチェックサムを使用しているため、一般的なエラーが気付かれない可能性があります。パケット サイズが小さく、ACKまたはNAKを待つ必要があるため、高速リンクや遅延の大きいリンクではパフォーマンスが低下します。最後に、転送にはファイルの詳細が含まれていないため、すべてのファイルを手動で開始する必要があり、多数の小さなファイルを転送する場合は面倒な作業になる可能性があります。

これらの問題の解決策は、1980 年代初期に開発されました。XMODEM-CRC は、チェックサムを 16 ビットの巡回冗長検査(CRC) に置き換えました。これは、一般的なエラーに対する耐性がはるかに高くなっています。XMODEM-1k は、パケット サイズを 128 バイトから 1024 バイトに拡張し、高速接続でのパフォーマンスを改善しました。一方、WXMODEM や SEAlink などの他のモデムは、パフォーマンスと遅延の両方に対処するために、代わりにスライディング ウィンドウシステムを導入しましたが、その代償として、複雑さが増しました。さらに、TeLink や MODEM7 などのモデムは、ファイル情報を追加して、1 回の転送に複数のファイルを含められるようにし、1 つのコマンドで複数のファイルをまとめて送信できるようにしました。

CP/M 「Yet Another Modem プログラム」、または YAMの作者Chuck Forsberg は、XMODEM に比べて多くの機能をサポートする単一のプロトコル ドライバーを作成することを決定し、それを YMODEM と名付けました。ユーザーは転送を開始するときに、コマンド ラインで必要なオプション (たとえば、CRC を使用する) を指定できます。プロトコルは、このスタイルを試みるように記述されていますが、リモート ソフトウェアが実装している機能に合わせて適切にフォールバックします。

オリジナルの XMODEM の問題の 1 つは、転送を開始すると中止する方法が定義されていなかったことです。通常の解決策は、ユーザーが要求した場合、後続のすべてのパケットに NAK を送信することでした。XMODEM プロトコルでは送信を中止するNAKの制限が 10 個と定義されており、各パケットの送信に 1 秒かかる可能性があるため、送信側がデータを継続的に送信しても無視される 10 秒の遅延が発生していました。

一部の実装では、受信パケットの最後にACKまたはNAK の代わりにCAN を送信して中止を示す機能が追加されました。残念ながら、回線ノイズによってCAN が生成され、中止がトリガーされる可能性がありました。そのため、YAM はこれをわずかに変更して、2 つのCANを連続して 要求し、送信側ですぐに「正常な中止」を実行するようにしました。

CRC サポートは XMODEM-CRC で導入されました。これは元のプロトコルに対する非常に単純な変更でした。要求された場合、受信側はNAKの代わりに最初のC を送信して転送を開始しようとします。リモート送信側が CRC オプションをサポートしている場合は、通常どおりパケットの送信を開始しますが、フッターには 1 バイトのチェックサムではなく 16 ビットの CRC が含まれます。YAM は変更なしでこのオプションをサポートしました。

1024バイトのパケットはXMODEM-1kで導入されました。^[1]このバージョンでは、受信側からのトリガー文字が変更されなかったため、送信側は受信側がより大きなパケットをサポートしているかどうかを知る方法がありませんでした。代わりに、XMODEM-1kは接続の両端で別のプロトコルとして提示されました。このような接続が開始されると、送信側はパケットで1024バイトを送信するか、128バイトを送信するかを選択でき、ヘッダーに通常のSOHではなくSTX文字を使用して大きい方を示します。通常は、大量のパディングを送信するのを避けるために、最後の数パケットのみが小さいパケットを使用します。1kはすべての接続でCRCを想定していました。YAMは変更なしで1kをサポートしました。

FidoNetメールの自動転送をサポートするために、MODEM7 では、最初のデータ ブロックを送信する前にファイル名をプレーン テキストとして送信する機能が導入されました。これは信頼性が低く、TeLink はファイル名と、オプションで作成日やファイルの長さなどのその他のデータを完全な 128 バイト パケットに配置することでこれを改善しました。XMODEM はパケット番号 1 で転送を開始したため、TeLink はこのパケットを番号 0 として送信しました。この「ゼロ パケット」または「ブロック 0」は、SEAlink などの他の FidoNet システムでも一般的になりました。

YAM はゼロ パケット形式をサポートしていましたが、YMODEM の多くのサードパーティ実装では無視されていました。ある実装がゼロ パケットを非対応バージョンに送信しようとすると、パケット ゼロは不正であるため、受信側は当然パケットをNAK します。送信側はNAK を伝送エラーと見なし、パケットを再度送信しようとします。これを 10 回試みた後、失敗します。

理由は完全には明らかではありませんが、多くの YMODEM 実装ではこの機能が実装されていませんでした。この機能を認識していなかったため、NAK が送信され、失敗するまで一連の再送信が試行されました。つまり、ユーザーが準拠している YMODEM を非準拠バージョンで使用することを選択した場合、転送は失敗します。しかし、そのような非準拠バージョンは一般的でした。

その結果、YMODEM と YMODEM Batch の両方が 2 つの別々のプロトコルとしてリストされるのが一般的になりました。さらに、XMODEM-1k とこれらの非準拠の YMODEM の類似性によって混乱が生じ、誤って同じものとしてリストされることがよくありました。

YMODEM-Gは、エラーのない接続に使用されるストリーミング バリアントです。次のパケットを送信する前にACK を受信するのを待たず、フロー制御にはXON/XOFFが使用されます。このプロトコルは、パケット間に遅延が発生しないため YMODEM よりも高速ですが、エラーを修正する機能はありません。このプロトコルは、基盤となる接続がエラーフリーであることに依存しており、^[1]たとえば MNP をサポートするモデムの場合に当てはまります。

通常、YMODEM 転送は、受信側がC を送信してCRC 付きの 128 バイト形式を使用することを示すか、元のチェックサム システムを使用する場合はNAK を送信することで開始されます。g プロトコルが必要な場合は、代わりにG を送信して転送を開始します。送信側が g プロトコルをサポートしていない場合、これはエラーと見なされ無視されますが、g をサポートしている場合は、パケットの連続ストリームの送信を開始します。データにEOT文字が存在することで示される最終パケットの受信後に、 1 つのACKのみを期待します。YMODEM-g は、1k パケットが使用可能であると想定しています。

しかし、このプロトコルはZMODEMよりも高速である可能性があるにもかかわらず、ほとんど使用されていませんでした。これは、他の機能が不足していることも一因ですが、より深刻な問題もありました。16550 UARTが登場する前は、シリアル ポートでバッファ オーバーランが発生する大きなリスクがありました。これは YMODEM-g によって検出されますが、ブロック再送信が不可能なため修正できません。受信側は、送信全体をキャンセルして最初からやり直す必要があります。一方、 ZMODEMには転送再開機能があり、より魅力的でした。

• XMODEM / YMODEM プロトコル リファレンス、Chuck Forsberg 著、1985 年 10 月 10 日
• XMODEM / YMODEM プロトコル リファレンス、Chuck Forsberg、1988 年 6 月 18 日 (1988 年 10 月 14 日に文書が再フォーマットされました) (テキストの問題を含む HTML バージョン)