エックスモデム

XMODEM は、 1977 年にWard ChristensenがMODEM.ASM端末プログラムで使用するために急ごしらえで開発したシンプルなファイル転送プロトコルです。これにより、ユーザーは両方のコンピュータが MODEM を使用している場合に、コンピュータ間でファイルを転送できるようになりました。Keith Petersen は、常に「静音モード」をオンにするマイナーアップデートを行い、その結果を XMODEM と名付けました。^{[3] [4]}

XMODEM は、ほとんどのファイル転送プロトコルと同様に、元のデータを一連の「パケット」に分割して、そのパケットが正しく受信されたかどうかを受信側が判断できるようにする追加情報とともに受信側に送信します。エラーが検出されると、受信側はパケットの再送信を要求します。不良パケットが連続すると、転送が中止されます。

XMODEM は、実装が簡単だったため、初期の掲示板システム(BBS) 市場で非常に人気を博しました。また、効率が悪く、モデムの速度が上がるにつれて、この問題により、パフォーマンスを改善したり、プロトコルの他の問題を解決したりするために、XMODEM の修正版が数多く開発されました。 ^[4]クリステンセンは、オリジナルの XMODEM を「コンピュータの歴史上最も修正されたプログラム」と信じていました。^[5]

Chuck Forsberg は、YMODEMプロトコルにいくつかの一般的な変更をまとめましたが、実装が不十分だったため、その後のZMODEMプロトコルによって再統合されるまで、さらに分裂が起こりました。ZMODEM は非常に人気がありましたが、BBS 市場で XMODEM を完全に置き換えることはありませんでした。

オリジナルの XMODEM は、 CP/M フロッピー ディスクで使用される基本ブロック サイズである 128 バイトのデータ パケットを使用していました。パケットの先頭には、文字、1 ～ 255 の「ブロック番号」、および「逆」ブロック番号 (255 からブロック番号を引いた値) を含む単純な 3 バイトのヘッダーが付けられていました。ブロック番号は、最初に送信されるブロックの 0 ではなく 1 から始まります。ヘッダーの後には 128 バイトのデータが続き、その後に 1 バイトのチェックサムが続きます。チェックサムは、パケット内のすべての 128 データ バイトの合計を256 で割ったものです。したがって、完全なパケットは 132 バイトの長さで、128 バイトのペイロード データが含まれており、チャネル全体の効率は約 97% でした。 <SOH>

ファイルは、最後のブロックの後に送られた文字で「完了」とマークされました。この文字はパケット内にはなく、1 バイトとして単独で送信されました。ファイルの長さはプロトコルの一部として送信されなかったため、最後のパケットは、削除可能な「既知の文字」で埋められました。元の仕様では、これはデフォルトで10 進数で 26 に設定され、CP/M はこれを独自のディスク フォーマット内でファイル終了マーカーとして使用していました。標準では、任意の文字をパディングに使用できると示唆されていましたが、プロトコル自体内で変更する方法はありませんでした。実装でパディング文字が変更された場合、同じ実装を使用しているクライアントだけが新しいパディング文字を正しく解釈します。 <EOT><SUB>

ファイルは一度に 1 パケットずつ転送されました。受信時に、パケットのチェックサムは受信側によって計算され、パケットの末尾にある送信側から受信したチェックサムと比較されます。2 つが一致した場合、受信側は送信側にメッセージを送り返し、送信側は次のパケットを順番に送信します。チェックサムに問題があった場合、受信側は代わりに を送信します。 を受信した場合、送信側はパケットを再送信し、^[4]転送を中止する前に、通常 10 回試行し続けます。 <ACK><NAK><NAK>

<NAK>受信側が 10 秒以内に有効なパケットを受信しなかった場合にも、文字が不足しているためにまだデータを期待していた場合にも、Aが送信されました。パケット内で<EOT>7 秒のタイムアウトも使用され、パケットの途中で接続が切断されることを防止しました。

ブロック番号も、エラーをチェックするために簡単な方法で調べられました。パケットを正常に受信した後、次のパケットの番号は 1 つ大きくなります。同じブロック番号を受信した場合は、これは深刻な問題とはみなされず、<ACK>送信者がパケットを受信できなかったため、パケットを再送信したことを意味します。その他のパケット番号は、パケットが失われたことを示します。

転送は受信側主導で行われ、受信側から最初のデータが送信されるまで、送信側はデータを送信しません<NAK>。これは、ユーザーがリモートにある送信マシンとやり取りする方法の論理的な結果です。ユーザーは、送信マシンで要求されたファイルに移動し、そのマシンに転送を依頼します。このコマンドが発行されると、ユーザーはローカル ソフトウェアでコマンドを実行して受信を開始します。リモート システムにファイルを要求してから、ローカルで受信コマンドを発行するまでの遅延は不明であったため、XMODEM では、受信側がデータ パケットの要求を発行し始めるまでに最大 90 秒の猶予がありました。

XMODEMは1982年にジャーナリストがオズボーン1と音響カプラを使って低品質の電話回線でパキスタンから米国に記事を送信できるほど堅牢でしたが、 ^[6]プロトコルにはいくつかの欠陥がありました。

XMODEM はCP/Mマシン用に書かれており、そのオペレーティング システムの特徴をいくつか受け継いでいます。特に、CP/M 上のファイルは常に 128 バイトの倍数であり、その終わりはブロック内に 文字でマークされていました<EOT>。これらの特徴は XMODEM に直接移植されました。しかし、他のオペレーティング システムにはこれらの特徴のいずれもなく、 1980 年代初頭にMS-DOSが広く導入されたため、XMODEM を更新して<EOT> または を <EOF>ファイル終了マーカーとして認識する必要が生じました。

受信側から簡単に転送を中止できるように、または<CAN>の代わりに 文字を送信することがサポートされるべきだと以前から提案されていました。同様に、の代わりに が受信された場合、送信者が転送をキャンセルしたいことを示します。ただし、この文字は、またはであるはずの単純なノイズ関連のエラーによって簡単に「作成」される可能性があります。この問題を回避するために double- が提案されましたが、これが広く実装されたかどうかは明らかではありません。 <ACK><NAK><CAN><SOH><ACK><NAK><CAN>

XMODEM は、他のファイル転送プロトコルに関する知識をあまり持たずに、シンプルさを重視して設計されました。他のファイル転送プロトコルは、そもそもあまり使われていませんでした。シンプルさゆえに、転送が失敗したり、さらに悪いことに、プロトコルが気付かない間違ったファイルが生成されたりする原因となる、非常に基本的なエラーがいくつかありました。そのほとんどは、エラー訂正に単純なチェックサムを使用したことによるもので、^[4] 2ビットが逆になるとデータ内のエラーが失われる可能性があり、これは適度に短いノイズのバーストで発生する可能性があります。さらに、ヘッダーやチェックサムに同様の損傷があると、データ自体が損傷していなくても転送が失敗する可能性があります。

多くの著者が、これらの問題やその他の問題に対処するために XMODEM に拡張機能を導入しました。多くの人が、これらの拡張機能を新しい XMODEM 標準の一部として組み込むよう求めました。しかし、Ward Christensen はこれを拒否しました。XMODEM が広く使用されるようになったのは、まさにこれらの機能の欠如と、それをサポートするために必要な関連コーディングの不足によるものだからです。彼は次のように説明しています。

これは、他の人とコミュニケーションを取りたいという個人的なニーズを満たすために、私が急いで作ったもので、まったく計画性のないものでした (私が行うすべてのことと同様)。これが 1977 年 8 月に作成され、すぐにパブリック ドメインにされたという事実だけが、これが現在の標準になった理由です...

...「全二重」、「複数の未処理ブロック」、「複数の宛先」など、プロトコルに大幅な変更を加えることを提案する人々は、プロトコルの信じられないほどのシンプルさが、それが生き残った理由の 1 つであることを理解していません。

XMODEM のもう 1 つの問題は、転送を自動化するのではなく、ユーザー主導で行う必要があることです。^[4]通常、これはユーザーが送信者のシステム上で必要なファイルを選択し、コマンドを使用してそのシステムを「送信準備完了」モードにすることを意味します。次に、端末エミュレーターのコマンドを使用して、自分の側から転送を開始します。ユーザーが別のファイルを転送したい場合は、このプロセスをもう一度繰り返す必要があります。

2 つのサイト間の自動転送のために、XMODEM プロトコルに多くのアドオンが時間の経過とともに実装されました。これらは通常、送信側がファイルを次々に送信し続け、受信側は転送NAKの開始時に通常どおり を送信して次のファイルをトリガーしようとすることを想定していました。 がNAKタイムアウトすると、それ以上ファイルがないか、リンクが壊れていると想定できました。

MODEM7 は、 MODEM7 バッチまたはバッチ XMODEMとも呼ばれ、XMODEM プロトコルの最初の既知の拡張機能です。通常の XMODEM ファイル転送は、受信側が送信側に 1NAK文字を送信することから始まり、次に送信側がデータの開始を示す 1 文字を送信しSOH、その後にデータ パケットを送信します。

MODEM7 では、ファイル名を8.3 ファイル名形式で の前に送信することで、この動作がわずかに変更されました。<SOH>各文字は個別に送信され、エラー訂正の形式で受信側がエコーする必要がありました。非対応の XMODEM 実装では、 のSOH到着を待つ間、このデータは単に無視されるため、文字はエコーされず、実装は従来の XMODEM に戻ることができます。「対応」ソフトウェアでは、ファイル名を使用してファイルをローカルに保存できます。転送は別の で続行でき<NAK>、各ファイルは受信側に送信される名前で保存されます。

1983年にジェリー・パーネルはMODEM7を「おそらく現存する最も人気のあるマイクロコンピュータ通信プログラム」と評した。^[7]

MODEM7 はファイル名を通常のテキストとして送信していたため、XMODEM が回避しようとしていたのと同じ問題によってファイル名が破損する可能性がありました。このため、オリジナルのFidoNetメーラーの作者であるTom JenningsがTeLinkを導入しました。

TeLink は、元のファイルに関する情報を含む新しい「ゼロ パケット」を標準化することで MODEM7 の問題を回避しました。これには、ファイル名、サイズ、タイムスタンプが含まれ、通常の 128 バイトの XMODEM ブロックに配置されます。通常の XMODEM 転送は、送信者がヘッダー付きの「ブロック 1」を送信することから開始されますが<SOH>、TeLink ヘッダー パケットは「ブロック 0」というラベルが付けられ、で始まります<SYN>。パケットには、ファイルの作成日時、最大 16 文字のファイル名、4 バイトの値としてのファイル サイズ、およびファイルを送信するプログラムの名前が含まれていました。^[8]

通常の XMODEM 実装では、パケット番号が破損していると想定して、パケットを破棄するだけです。しかし、パケットが破棄されると、送信側は受信者がゼロ<NAK>パケットを理解できなかったために応答したのか、送信エラーがあったために応答したのかを判断できないため、潜在的な時間遅延が発生します。TeLink は通常、FidoNetソフトウェアによってのみ使用され、FidoNet 標準の一部として要求されるため、両端が常にこの標準をサポートするため、実際の問題は発生しません。^[8]

基本的な「ブロック 0」システムは FidoNet コミュニティの標準となり、SEAlinkやYMODEMなどの将来の多くのプロトコルで再利用されました。

元のプロトコルで使用されていたチェックサムは非常に単純で、パケット内のエラーに気付かれない可能性がありました。このため、ジョン・バーンズがXMODEM-CRCを導入しました。 ^{[9] [10]}これは、8ビットのチェックサムの代わりに16ビットのCRCを使用しました。 ^[4] CRCはパケット内のデータだけでなくその位置もエンコードするため、チェックサムでは見逃されるビット置換エラーに気付くことができます。統計的には、これにより16ビット未満のエラーを検出する確率は99.9969%になり、エラービット文字列が長ければさらに高くなります。^[11]

XMODEM-CRC は、XMODEM との下位互換性を持つように設計されました。これを実現するために、受信側は転送を開始するためCに の代わりに (大文字の C) 文字を送信しました<NAK>。送信側がパケットを送信して応答した場合、送信側は XMODEM-CRC を「知っている」と想定され、受信側はCを送信し続けました。パケットが送信されなかった場合、受信側は送信側がプロトコルを知らないと想定し、 を送信して<NAK>「従来の」XMODEM 転送を開始しました。^[11]

残念ながら、この下位互換性の試みには欠点があった。最初のC文字が失われたり破損したりする可能性があるため、転送を開始する最初の試みが失敗した場合、受信側がXMODEM-CRCをサポートしていないとは想定できなかった。そのため、受信側は で転送を3回試み、各試行の間に3秒待機した。つまり、ユーザーが意図したとおりにXMODEMと通信しよCうとしているときにXMODEM-CRCを選択した場合、転送が開始されるまでに10秒の遅延が発生する可能性がある。^[11]

遅延を回避するために、送信者と受信者は、通常、XMODEM とは別に XMODEM-CRC をリストし、送信者が明示的にリストしなかった場合にユーザーが「基本」XMODEM を選択できるようにします。平均的なユーザーにとって、XMODEM-CRC は本質的に「第 2 のプロトコル」であり、そのように扱われます。ただし、これは FidoNet メーラーには当てはまりません。FidoNet メーラーでは、CRC がすべての TeLink 転送の標準として定義されていました。^[8]

XMODEM プロトコルでは、送信側が停止して受信側からのメッセージ<ACK>または<NAK>メッセージを待つ必要があるため、非常に遅くなる傾向がありました。300 ビット/秒のモデムの時代では、132 バイトのパケット全体の送信に 4.4 秒かかりました (132 バイト * (1 バイトあたり 8 ビット + 1 スタート ビット + 1 ストップ ビット) / 300 ビット/秒)。受信側が<ACK>送信側に戻り、次のパケットが受信側に到達し始めるまでに 0.2 秒かかると仮定すると (両方向で 0.1 秒)、1 つのパケットの全体的な時間は 4.6 秒となり、チャネル効率は 92% をわずかに上回ります。

<ACK>/プロセスの時間は、<NAK>モデムのパフォーマンスではなく、基盤となる通信ネットワークの固定関数でした。モデムの速度が上がるにつれて、固定遅延はパケットの送信に必要な時間に比例して増加しました。たとえば、2400 ビット/秒では、パケットの送信にかかった時間はわずか 0.55 秒でした。したがって、<ACK>/ が<NAK>ユーザーのマシンに戻るまでにまだ 0.2 秒かかった場合、効率は 71% に低下します。9600 ビット/秒では、効率は 40% 弱です。つまり、パケットの送信に必要な時間よりも、応答を待つ時間の方が長くなっています。

これらの問題に対処するために、XMODEM の新しいバージョンがいくつか導入されました。以前の拡張機能と同様に、これらのバージョンは元の XMODEM と下位互換性を持つ傾向があり、それらの拡張機能と同様に、ユーザーの端末エミュレーターにおける XMODEM 環境のさらなる分裂につながりました。最終的に、XMODEM の数十のバージョンが登場しました。

WXmodemは「Windowed Xmodem」の略で、1986年にピーター・ボズウェルが開発したXMODEMの派生版で、特に公衆X.25システムやPC Pursuitなどの高遅延回線での使用を目的としている。これらの遅延は従来の電話サービスよりもはるかに大きいため、XMODEMの効率は非常に悪い。さらに、これらのネットワークではフロー制御やその他のタスクに制御文字がよく使用され、特にXON/XOFFはデータフローを停止する。最後に、再送信を必要とするエラーの場合、パケットインジケータなのかノイズなのかを判断するのが難しいことがあった。WXmodemはこれらの問題に対処するためにXMODEM-CRCを採用した。^[11]SOH

DLE1つの変更点は、、、およびというXON制御文字の小さなセットをエスケープすることだった。これらは、文字の前に a を挿入し、文字を64でXOR演算して変更することでエスケープされた。理論的には、パケットが元々エスケープを必要とする文字だけで構成されていた場合、パケットの長さは264バイトになる可能性がある。これらの挿入および変更された文字はCRC計算の一部ではなく、CRCを計算する前に受信側で削除および変換される。^[11]XOFFSYNDLE

さらに、すべてのパケットの先頭に文字が付けられSYN、パケットの先頭が になることで、さまざまなエラーケースでパケットヘッダーと混同されるSYNSOH可能性が減りました。パケット本体でエスケープされていない文字が見つかった場合はエラーでした。^[11]SOHSYN

WXMODEM の主な変更点は、高遅延リンクのスループットを向上させるためにスライディング ウィンドウを使用することです。これを行うには、メッセージの後に、送信または受信するACKパケット番号が続きます。受信側はすべてのパケットを送信する必要はなく、 1 から 4 までの任意の数のパケットを送信できます。4番目のパケット シーケンス番号を持つ は、4 つのパケットすべてに対して送信されたとみなされます。エラーが発生すると、その番号からのすべてのパケットが再送された後、 が直ちに送信されます。^[11]ACKNAKACKACKACKACKNAK

4 パケットごとにを要求すると、ACKシステムは 512 バイトのパケット サイズを持つように動作しますが、エラーが発生した場合、通常は 128 バイトの再送信のみが必要です。さらに、逆方向に流れるデータ量が 4 分の 1 に削減されます。これは、一般的なモデムの全二重操作ではあまり重要ではありませんが、一方向の速度が 19 kB、戻りチャネルの速度が 75 ビット/秒であるTelebitモデルなどの半二重システムでは重要です。

FidoNetシステム用の最初のサードパーティメーラーの1つは、当時人気のあった.arcデータ圧縮形式と同じ作者によって書かれたSEAdogでした。SEAdogには、WXmodemと同じスライディングウィンドウの概念に基づいた改良された転送プロトコルであるSEAlinkを含むさまざまな改良が含まれていました。 ^[12] WXmodemとの違いは主に細部でした。

1つの違いは、SEAlinkがTeLinkによって導入された「ゼロパケット」をサポートしていたことです。これは、ヘッダーが期待されるFidoNetシステムでTeLinkの代替品として動作するために必要です。ACKsとsは、元のXMODEMパケットヘッダーと同じように、またはNAKで始まり、次にパケット番号、次にパケット番号の補数で終わる3バイトの「パケット」に拡張されました。ウィンドウサイズは通常、6パケットに設定されていました。^[12]ACKNAK

SEAlink は X.25 や類似のリンク上で動作することは想定されていなかったため、エスケープは実行されませんでした。この標準ではSYNWXmodem が再利用した文字が使用されていたため、ゼロ パケットが正しく動作するためにもエスケープは必要でした。 ^[12]これらの変更に加えて、半二重リンク用の「オーバードライブ」モードが追加されました。これにより、正常に転送されたパケットの ACK が抑制され、実質的にウィンドウのサイズが無限大になりました。このモードはゼロ ブロックのフラグによって示されました。^[12]

SEAlink はその後、他の多くの改良点を追加し、汎用性の高いプロトコルとなりました。しかし、FidoNet の世界以外では珍しいままで、ユーザー向けソフトウェアではほとんど見られませんでした。

スループット問題を解決するもう1つの方法は、パケットサイズを増やすことです。遅延の根本的な問題は残りますが、問題になる速度は速くなります。1024バイトのパケットを持つXMODEM-1K ^[4]は、最も人気のあるソリューションでした。この場合、上記と同じ仮定を前提とすると、9600ビット/秒でのスループットは81％です。

XMODEM-1K は XMODEM-CRC の拡張バージョンであり、パケットを の代わりに 文字で開始することで、送信側のブロック サイズが長いことを示します。他の下位互換性のある XMODEM 拡張機能と同様に、-1K 転送は、必要に応じて機能をバックオフすることで、反対側の XMODEM の任意の実装で開始できることが意図されていました。 <STX><SOH>

XMODEM-1K は、もともとChuck ForsbergがYMODEMプロトコルで導入した XMODEM の多くの改良点の 1 つでした。Forsberg は、さまざまな改良点はオプションであると提案し、ソフトウェア作成者が可能な限り多くの改良点を実装することを期待していました。しかし、彼らは通常、最低限の改良点を実装したため、互換性のない実装が大量に出現し、最終的に「YMODEM」という名前が「XMODEM-1K」とさまざまな YMODEM に分割されました。したがって、XMODEM-1K は実際には YMODEM より後のものですが、それでもかなり一般的に使用されていました。

NMODEM は、1990 年にリリースされた LB Neal によって開発されたファイル転送プロトコルです。NMODEMは、XMODEM の 128 バイト ブロックではなく、より大きな 2048 バイト ブロックを使用する XMODEM-CRC のバージョンです。NMODEM は、 IBM PC 互換機ファミリーのコンピューター用に Turbo Pascal 5.0 で記述された別のプログラムとして実装されました。ブロック サイズは、当時のハード ドライブ上のMS-DOS FATファイル システムの一般的なクラスター サイズと一致するように選択され、書き込み用のデータのバッファリングが簡単になりました。^{[13] [14]}

信頼性の高い (エラーのない) 接続では、パケットを「事前確認」することで遅延をなくすことができます。この手法は、一般的に「プロトコル スプーフィング」と呼ばれています。これは通常、リンク ハードウェア、特に Telebit モデムで実行されます。モデムは、オプションがオンになっていると、XMODEM ヘッダーを認識し、すぐに を送信しますACK。これにより、送信側の XMODEM プログラムはすぐに次のパケットを送信し、転送は無限サイズのウィンドウのように連続的になります。モデムは、ACK遠端の XMODEM ソフトウェアによって送信される も抑制し、低速の戻りチャネルを解放します。

このシステムはプロトコル自体に実装することもでき、XMODEM のバリエーションではこの機能が提供されていました。これらの場合、受信側は、ACKTelebit モデムと同じように、パケットが開始されるとすぐに送信します。この機能は受信側の動作を変更するだけなので、送信側でプロトコルを変更する必要はありません。YMODEMはこのシステムを公式化しました。

この概念は、リンクの両側の動作を変更する SEAlink で使用される概念とは対照的です。SEAlink では、受信側は送信をACK完全に停止し、送信側はそれらを期待しないように動作を変更します。

• BLAST (プロトコル)
• カーミット（プロトコル）

• Bush, Randy (1995 年 9 月 30 日). FidoNet 技術標準 FTS-0001 (技術レポート).
• Christensen, Ward (1982 年 1 月 1 日)。「XMODEM プロトコルの概要」。
• Forsberg, Chuck (1986 年 9 月 11 日)。「XMODEM/YMODEM プロトコル リファレンス」。
• Boswell, Peter (1986 年 6 月 20 日)。「XMODEM、CRC XMODEM、WXMODEM ファイル転送プロトコル」。CRC XMODEM。
• SEALINK ファイル転送プロトコル (技術レポート)。1987 年 8 月 24 日。

• MODEM.ASM、オリジナル ソース コード、Ward Christensen、1977 年 10 月 10 日。
• XMODEM / YMODEM プロトコル リファレンス、Chuck Forsberg 著、1985 年 10 月 10 日
• XMODEM / YMODEM プロトコル リファレンス、Chuck Forsberg、1988 年 6 月 18 日 (1988 年 10 月 14 日に文書が再フォーマットされました) (テキストの問題のある HTML バージョン)
• XMODEM / XMODEM-CRC / WXMODEM ファイル転送プロトコル、synchro.net
• Adontec XMODEM/32k および XMODEM/64k 拡張機能、adontec.com