るのて、 , XMODEM のようにデータの最後 が余計な文字て、埋められるようなことはな 2400bPS 以上の速度て、データ転送をする場 合には , 通常は 1024 バイトのデータを 1 バケ ットに格納するのが効率的て、ある。 BPIus のバケットは可変長て、ある。 2400 bps の場合 , 基本的には 1024 バイトのデータ をバケットとするのが効率的て、あるが , 万 ーデータ工ラーの多い回線に遭遇した場合 には , 1024 バイトは長すぎるかもしれない あまりリトライの頻度が多いようて、あれば , ある程度自動的にバケットの長さを減らし てみて , 状況が改善されるかどうかを判断 F バケット すべきて、ある。 変化することになるのて、 , 注意が必要て、あ 換 , 行末の変換を行うと , サイズ , CRC が ンロードした場合には , 受信側て、コード変 C を送信する。テキスト形式のデータをダウ g. 18 ) を用いて既存ファイルのサイズと CR る場合 , レスポンダは , 、、 T ドバケット (Fi を受け取った側が既存ファイルを持ってい をサポートしていて , かっ、、 TD クバケット 双方が DownIoad Resume 機能 (Fig. 17 ) T 「バケット たバケットの内容をすべて無視する。 ケットを送信した側は , その後に受け取っ は ACK が戻ってくることを確認する。 F'€ 信し処理を中断する。バケットを送った側 F バケットを受信した側は必ず ACK を返 画面に表示するために使われる。 を報告するために使われる文字列て、あり , するためのコードて、ある。残りは単に状況 く Body > の最初の 1 バイトが , 状況を識別 無視され , 障害があったことのみを認識す て、ある。このバケットのシーケンス番号は の障害があった場合に送信されるバケット F バケット (TabIe 7 ) は , 処理中に何らか Fig. 23 タイムアウトが発生した場合の処理 Failure packet 送信中てなければ , ACK sequence を送信 OS-Send ACK ( ACK 送信処理 ) 上のいすれにも該当しないなら , ① S Get_DLE へ Ab0 ⅲ ng 状態でなければ , NAK を送信し , ① S-Get—DLE へ 工ラーをカウントする。カウンタが限度を超えたら , failure を戻し終了 ⑩ S_Send_NAK(NAK 送信処理 ) 上のいすれにも該当しないなら , ⑩ S_Send_NAK へ 受け取ったバケットが , すでに処理したノヾケットなら , ⑩ S_Send_ACK へ packet TypetjF なら , si ~ を戻し了 受け取ったバケットが , 目的の Se uence と一致したら , size を戻し終了 ÄS_Verify_Packet 不一致なら , ⑩ S Send_NAK へ Checksumh\ 合致したら , ÄS Verify_Packet へ BS_Veify_CKS (Check sum 照合処理 ) 不一致なら , ⑩ S Send_NAK へ C 日 C が合致したら , ÄS Verify_Packet へ jS Verify-CRC(CRC 照合処理 ) timeout なら , ⑩ S Send NAK へ C 日 C を受け取ることができたら , @S Verify CRC へ BS Get ー C 日 C ( C 日 C 受け取り処理 ) timeout なら , ⑩ S Send_NAK へ Checksum なら , BS_Veify_CKS へ CRC を用いるなら , BS_Get_CRC へ ()S Get-Check(check v 引 ue 受け取り状態 ) timeout なら , ⑩ S Send NAK へ ④ S_Get_Data へ このテータをノヾッフアに保存し , このテータに対する Check va ⅳ e 処理を行い , それ以外のテータなら , 次のテータが ENQ なら , OS Send_ACK へ 次のテータが ETX なら , (5S_Get_Check へ ④ S ー Get ー Data ( テータ受け取り処理 ) timeout なら , ⑩ S Send NAK へ ④ S Get_Data へ Check value をクリアして , これを保存して , それ以外のテータなら , 次のテータが ENQ なら , OS_Send_ACK へ 9S_DLE_B_Seen(DLE B の次の文字く Sequence > 待ち状態 ) timeout なら , ()S Send_ENQ へ それ以外のデータなら , ① S_Get_DLE へ 次のテータが ENQ なら , 0jS Snd_ACK へ 次のテータが : なら , ① S Get DLE へ 次のデータが B なら , BS_DLE_B_Seen へ 該当バケットか存されていれば , 解放し , 処理終了 それ以外の場合は⑩ S Send_ENQ へ く digit > が一致しない場合には , O@S Send_ENQ へ く digit > 力、一した場合は , ⑩ S_Resend_Packets へ 次のテータか DLE <di it > であり , 直前に ENQ を送ったなら , 次のテータがく digit > なら , ACK を受信したことになる DLE_Seen(DLE の次の文字待ち状態 ) timeout なら , OS Send ENQ へ それ以外のテータなら , ① SZGet_DLE へ 次のテータが ETX なら , ⑩ S Send NAK へ 次のテータが ENQ なら , OS Send ACK へ 次のテータが NAK なら , (j@S Send_ENQ へ 次のテータが DLE なら , BS_DLE_Seen へ ① S_Get_DLE(DLE 待ち状態 ) ACK を受け取っていないノヾケットをすべて再送し , ① S_Get_DLE へ ⑩ S_Resend_Packets( ノヾケット再送 ) ENQ を 2 個送り , ① S Get_DLE へ ⑩ S Send_ENQ(ENQ ENQ 送信処理 ) ① S_Get DLE へ 54 C M AGAZI N E 1993 2

ーな方法が , 当時 2 種類あった。ひとつは , テキストファイルにしたものを登録する方 法て、ある。 ish 形式にしてテキストて、登録す ればよい。データを表示する速度は 2400bP s の回線において 150 ~ 200 バイト / 秒程度て、あ る。この速度は , バイナリのデータをテキ スト化したとき増加するサイズを考慮して も , MNP て、 XMODEM を使うよりは十分短 時間といえる速度だ。実際 , 一部のフォー ラムてはこの方法を推奨していたようて、あ もうひとつの方法は , XMODEM を使う ときは MNP を使わないという , コロンプス の卵のような発想て、ある。確かに MNP を使 えば工ラーフリーになる。しかし XMODE M を使うのにエラーフリーて、ある必要はな いのだ。工ラー発生時のリトライは XMOD EM が処理してくれるからて、ある。 MNP を 殺しておけばモデム間のバケット化の処理 Fig. 34 から述べる FIying-XMODEM という方法て、 れ , 時代とともに去っていったのが , これ そこに切り込むべく第 3 の方法として現 ある。 ODEM 以外のプロトコルを , ということて、 ODEM と MNP は相性が悪いのだから , XM た。通常の発想は当然そうなるわけて、 , XM Serve て、も早くサポートを , という声があっ が先にサポートされていたため , NIFTY- また , CompuServe て、は Quick B や B PIus と思うこともあったようだ を間違えた , というのを見るとモデムが故障したか設定 い人なら , 発言を表示するとき速度の半分 いたかというと , そうて、もない。経験の浅 ところて , 当時はそれて、皆さん満足して 待て、きたと思う。 この場合は , 150 バイト / 秒程度の速度が期 が省かれるのて、 , レスポンスは改善される。 ある。 このころ , 私は通信ソフトを自作して使 っていたのて、 , それに XMODEM のプロト コルを組み込むときに , XMODEM が高速 にならないか , と少し考えてみたのて、ある。 普通の発想て、はこういうことは思いつかな いのだが , どこか変だったようて、ある。 のアイデアの背景には , 普段 XMODEM を 使っていて , リトライの経験はなかった。 これが重要てある。 MNP というのはエラー フリーが建前の規格だから , XMODEM が 遅くなる反面 , リトライは発生しないわけ だ。 XMODEM のもっとも基本的なプロトコ ルを説明する。まず送信側は受信側が NAK を送ってくるのを待ち , NAK がきたらハン ドシェイクを開始する (Fig. 29 ) 。 こて、 , ACK を受信側が返すのは , プロ ックを正常に受け取ることがて、きた場合て ある。チェックサムが合わなかったりする Fig. 33 ACK を先に送る 受信側 NAK ACK ぐープロック ACK く一 - プロック ACK く一・ - プロック く一 EOT ACK Fig. 35 XMODEM の八ンドシェイク 受信側 NAK ぐープロック ACK く一 - プロック ACK く一プロック ACK く一 EOT ACK 66 C MAGAZINE 1 3 2 送信側 送信側 ACK を先送りする 受信側 く一 く一 ぐー 送信側 NAK ACK ACK プロック ACK プロック ACK プロック EOT Fig. 36 ACK を待たずに次のプロックを送る 受信側 ぐー ぐー く一 く一 送信側 NAK プロック プロック ACK プロック ACK EOT ACK ACK

通信プロトコル研究 XMODEM は , データをプロックと呼ば れる単位て、送信する。プロックの構造は Fi g. 2 のようになっている。 CSOH] はヘッダ 開始を意味するキャラクタて、 , 0X01 て、あ る。シーケンス番号は , 1 から始めて 255 に なると次は 0 にリセットされ , その後また 1 から順に数えることになる。シーケンス番 号の補数は , シーケンス番号が回線のノイ ズなどて、エラーになったときに検出て、きる ように用意されているものて、 , シーケンス 番号と補数を加えると 0xff になるような値の 1 バイト文字て、ある。 データは 128 ノヾイトの長さて、 , 8 ビットの バイナリの情報をそのまま格納している。 したがって , XMODEM て、送信したデータ は , 必ず長さが 128 の倍数バイトになる。元 データが 128 て、割り切れないときには , 余っ たバイトを Contro ト Z て、埋めなければならな い。 XMODEM のデータ構造にはふたつの 欠点がある。まず , 最後のデータの余りを ControI ー Z て、埋めるため , データの最後が偶 然 control ー Z て、ある場合との区別がて、きな い。また , データの元々のサイズの情報は 失われる。 もうひとつの欠点として , バイナリのデ ータをそのまま転送することになるため , 回線は 8 ビットのデータすべてをそのまま通 過するように設定されていなければならな い。たとえば , XON/XOFF 制御を有効にし たままて、 XMODEM を使ってデータ転送を しようとすると , Control-S, Control-Q が 偶然データ中に含まれていた場合の動作に 間題が出てくる。後発の高機能の通信プロ トコルて、は , この問題はクオートによって 回避している。 チェックサムは , データ部分をすべて加 [SOH] [ シーケンス番号 ] Fig. 2 XMODEM のプロック構成 算して , 256 て、割った余りて、ある。すなわ ち , 1 バイトのレジスタを使って単純に加算 した結果に等しい ODEM の手順 まず , XMODEM によるファイル転送を 行うことが決まれば , 送信側は受信側から NAK が送られてくるのを 1 分間侍つ。待機 中の送信側は , NAK または CAN 以外のキャ ラクタはすべて無視する。 CAN は , , XMOD EM の処理を中断するための指示て、あり , れを受け取れば送信側は即時処理を中断す る。 送信側は NAK を受け取ると , ただちに最 初のプロックを送信し始める。受信側は NA K を送ると , 最初のプロックが到着すること を期待して待っている。しかし何らかのト ラブルにより , 応答がないことがある。 の場合 , 10 秒待っても何のデータもこない ならば , 再度 NAK を送信する。さらに 10 秒 待ってもデータが到着しなければ , もう一 度 NAK を送る。これを 10 回繰り返してもダ メなら , XMODEM による転送を諦めるこ とになる。 送信側は , プロックをひとつ送信し終え たら , それに対する応答が戻ってくるのを 待つ。受信側は , シーケンス番号 , チェッ クサムを確認して , データが正しいと判断 した場合には ACK を送信する。チェックサ ムが合わない場合には , NAK を送信する。 送信側は , ACK を受け取った場合には , 次 のプロックを送信する。 NAK を受け取った 場合には , 今送ったプロックをもう一度送 信する。 送信側は , 最後のプロックに対する ACK を受け取ると , EOT を送信する。 EOT が , ファイル転送終了の合図になる。受信側は , [ シーケンス番号の補数 ] [ テータ ] [ チェックサム ] EOT を受け取った時点て、 ACK を送信して , ファイルをクローズして XMODEM による 転送処理を終える。 処理の中断は CAN を送信することにより 実現される。送信側の都合て、データを送る ことがて、きなくなったら , プロックの代わ りに CAN を送信する。受信側て、エラーが発 生したり , 途中のプロックが消滅して処理 が続行て、きない場合には , ACK て、はなく C AN を送信する。 受信側て、エラーと判断て、きる場合として は , 以下のものが考えられる。 ①シーケンス番号とシーケンス番号の補数 の和が 255 にならなかった場合。この場合 はいすれかが正しくないのて、あるが , ど ちらが正しいともいえないのだから NAK を返送して再度プロックを送ってもらう ことになる。 ②すて、に正常に受信したプロックと同じシ ーケンス番号のプロックが送られてきた 場合。たとえば ACK が途中て、化けて送信 側て、認識されなかった場合にこのように なる。プロックはすて、に受信しているの だから , 二度目に受け取ったプロックは 無視して ACK を送信すれば , 送信側は次 のプロックを送ってくるはずて、ある。 ③次に受信すべきプロックが受け取れず , さらに先のプロックが送られてきた場合。 途中のプロックを受け取り損ねた場合て、 ある。このエラーの場合には , XMODE M は処理を続行することがて、きない。受 信側は処理を中断するために , CAN を続 けて 2 回送信する。 ④データが送られてこない場合。回線の事 情て、 , 途中て、データが消失した場合には , いくら待ってもデータが送られてこない はすて、ある。 10 秒待っても期待したデー タが到着しない場合には , NAK を送り , 再度の送信を促す。さら . にデータが送ら れてこない場合には , 10 回まて、これを繰 り返す。 ⑤何かのデータが化けたために誤った EOT を受け取ってしまった場合。受信側は EO 特集通信プロトコル研究 41

ACK ー・ > ( 転送終了 ) ACK ーー > ( 上記手順を , データがなくなるまで繰り返す ) 42 C MAGAZINE 1 3 2 T を受け取ったらファイルをクローズして 処理を終了してしまうのて、 , データ送信 がまだ終了していないのに , EOT がやっ てきたと誤解すると , そこて、処理を放棄 せざるを得ない結果となる。これを避け るために , EOT を受信したときには , ま ず NAK て、応答する方法が用いられること がある。送信側が NAK を受け取って , 再 度 EOT を送信してくれば , それをもって EOT が確かに送られてきたとみなすのて、 ある。 送信側て、エラーと判断て、きる場合として は , 受信側から ACK も NAK も戻ってこない 場合が考えられる。 10 秒待っても ACK, N AK, CAN のいずれも戻ってこなかった場 合には , 送信側は NAK を受け取ったとみな して , 前回送ったプロックを再度送信する。 10 秒というのは , 実際にネットを使った場 合には , 短すぎることがある。バケット回 線の混雑て、応答が遅くならたり , センター マシンの負荷の都合て、処理が間に合わない 場合に , 余計なタイムアウトが発生すると , 必要以上のデータを送信することになりか ねない。 XMODEM を実装するときに , ウ 工イトを 10 秒て、はなく , もっと長い時間に 設定する場合があるのは , このようなケー Fig. 3 XMODEM テータフロー概路 < ー・ SOH 《ー SOH ぐー - SOH ACK ー > 16 : } <— EOT <— EOT List 3 : 4 : 5 : 7 : 8 : 9 : 10 : 12 : 13 : 14 : 15 : 1 : uns igned short updcrc(), uns igned crc) CRC の計算手順 count ー if (crc & 0X800 の { --count 〉 = for (count return crc; crc 十 = crc くく一 } else { C rc crc 十 = crc くく = 1 : ( ( ( c く← 1 ) & 040 の ー 1 : = 0X1021 : ( ( ( c く← 1 ) & 040 の スを想定しているためて、ある。 双方て、問題になるのは , 間違って CAN を 受信した場合て、ある。とくに , 受信側はプ ロックの先頭部分を受け取り損ねた場合に は , SOH を受け取るまて、データを読み飛ば すことになるのだが , このデータ中に偶然 CAN が含まれている可能性が十分にある。 これをもって転送を中断してしまうと , デ ータ工ラーに対する回復力が極めて低くな ってしまう。 この問題に対する根本的な解決は不可能 だが , 多くの XMODEM の実装については , CAN を 2 回連続て、受け取った場合にキャンセ ルと解釈するようにしてこの問題を多少改 善しようとしている (Fig. 3 ) 。 C MODEM す。 えなくてよい OCRC の計算方法を List 1 に示 的にはエラーを検出し損なうことはまず考 ODEM て、ある。この誤り率て、あれば , 実用 C を用いてエラー検出したのが , CRCXM リアするために , チェックサムて、はなく CR て、あることが問題になった。この問題をク が一致することもあり , 信頼性がいまいち 法て、は , 偶然化けたデータのチェックサム サムによりデータ工ラーをチェックする方 くつかの改良版がある。かって , チェック XMODEM と呼ばれているものにも , い Fig. 4 受信側が CRC を指定し , 送信側にその機能がない場合 受信側 く一 送信側 ( プロック番号 ) ( プロック開始 ) NAK ー ( 送信開始を要求 ) ACK ー > sum ( チェックサム ) ( 実際のテータ 128 ノヾイト ) ( プロック番号を反転させたもの ) 受信側 送信側 C ー > (CRC XMODEM を指定 ) ( 3 秒でタイムアウト ) C ー > (CRC XMODEM を指定 ) ( 3 秒でタイムアウト ) C ー (CRC XMODEM を指定 ) ( 3 秒でタイムアウト ) C ー > (CRC XMODEM を指定 ) ( 3 秒でタイムアウト ) 02 sum ( プロック開始 ) ( プロック番号 ) ( プロック番号を反転させたもの ) ( 実際のテータ 128 ノヾイト ) ( チェックサム ) NAK ー > ( チェックサム XMOMEM を指定 ) ( プロック開始 ) ( プロック番号 ) ( プロック番号を反転させたもの ) ( 実際のテータ 128 バイト ) sum ACK ー > ( チェックサム ) ( 上記手順を , テータがなくなるまて繰り返す ) ( 転送終了 )

通信プロトコル研究 制御キャラクタが現れた場合 , そこまて、 のコードは不正コードとして無視し , そ こからまた改めて検索にかかるものとす これは , あるべきところ以外にコントロ ールシーケンスのコードが現れた場合には , データを不正とみなすという扱いて、ある。 ② 1 バイト制御キャラクタを受信すると , 短 いキャラクタ監視タイマ ( 1 秒 ) をセット し , 後続データを監視する。そして , 監 視中に後続データが到着しない場合。 この場合には , 制御キャラクタは , その 1 バイトの制御コードが独立して送信される ことが前提になっているのて、 , 直後に別の 文字コードが送信されてないことを確認す る。時間待ちを行うのて、あるから , これが 内 Table 10 送信局タイマー覧 送信局タイマ 八ンドシェイクタイマ ( STI ) フェーズ 機能概要 タイマ値 セット条件 リセット条件 タイムアウト処理 ネゴサプフェーズ 1 く CAN > を送信し異常終了 タイムアウト時 く CAN > 受信時 く NAK > 受信時 ( ホスト側ては , 受信局起動促進 MSG 送出直後 ) 送信局起動時 120 秒 送信局起動後 , く NAK > 受信監視タイマ トランスポートネゴタイマ ( ST2 ) フェーズ 機能概要 タイマ値 セット条件 リセット条件 タイムアウト処理 ファイル情報ネゴタイマ ( ST3 ) フェーズ 機能概要 タイマ値 セット条件 リセット条件 タイムアウト処理 テータ転送タイマ ( ST4 ) フェーズ 機能概要 タイマ値 セット条件 リセット条件 タイムアウト処理 終了監視タイマ ( ST5 ) フェーズ 機能概要 タイマ値 セット条件 リセット条件 タイムアウト処理 ネゴサプフェーズ 2 S 爪げ送信後 , 印 NIT 受信監視タイマ 120 秒 NIT 送信時 NIT 受信時 く NAK > 受信時 く CAN > 受信時 タイムアウト時 く CAN > を送信し異常終了 ネゴサプフェーズ 3 , 継続サプフェーズ V 日 LE 送信後 , VRPOS 受信監視タイマ 120 秒 V 日 LE 送信時 VRPOS 受信時 VSKIP 受信時 ( オプション ) タイムアウト時 く CAN > 受信時 ネゴサフ、 3 の場合 NIT 受信時 継続サフの場合 VSTAT 受信時 く CAN > を送信し異常終了 テータ転送フェーズ 応答待ちフロックリストの次のテータブロックに対応する NAK プロック受信時 応答待ちプロックリスト内のテータフロックに対応する ACK / NAK 目的ファイルの最終プロック送信後 VENQ 送信時 応答待ちプロック数がウインドウサイズと等しくなった 200 秒 ウインドウクローズ後 , VACK/VNAK/VSTAT プロック受信監視タイマ タイムアウト時 く CAN > 受信時 VSTAT 受信時 プロック受信時 く CAN > を送信し異常終了 不正コード受信時 タイムアウト時 く CAN > 受信時 く ACK > 受信時 く EOT> 送信時 200 秒 く EOT > 送信後 , く ACK > 受信監視タイマ 転送終了サプフェーズ く CAN > を送信し異常終了 VRPOS 受信時 (V(S):O 時のみ ) 転送速度に影響することも考えられるが , スライディングウインドウが順調に処理さ れている間て、あれば , この程度の待ち時間 が無視て、きるだけの先送りを行うことによ って , 速度への影響を回避て、きるだろう。 実際にエラーが発生したときは問題がある かもしれないが , 現実的にはエラーが発生 したときは別の意味て、時間がかかってしま うのて、 , あまり大きな影響はないかもしれ ない。実際にテストて、きるならば計測して みたいところて、ある。 ヾントの形式 Quick-VAN のデータブロックは Fig. 25 のような構造て , 見かけ上 , XMODEM の もっとも標準的なプロックとまったく同じ の機能にお互いの実際に利用する機能を合 は , パラメータをそれぞれ比較し , 低い側 行う。双方の機能が食い違っている場合に し , 受信側は RINIT プロックにより応答を て、きる機能を受信側に通知する。これに対 送るプロックて、あり , 送信側が使うことの SINITI ロックは , 送信側から受信側に 類がある。 イトとした固定長て、あり , 以下のような種 送信側のプロックは , BODY 部分を 128 バ め , データブロックと混同されることはな 常はチェックサムなどの差異が発生するた しかし , 内容は独自に変更されており , 通 け上は XMODEM の形式を踏襲している。 ファンクションプロックは , やはり見か 0x1a などと書かれている。 存となっており , ドキュメントには 0X00 , うが , Quick-VAN て、はキャラクタは OS 依 とになる。 XMODEM て、はここに 0x1a を使 た部分を余分なデータて埋めて送信するこ データが 128 バイト未満の場合には , 余っ 形式て、ある。 特集通信プロトコル研究 59 報は , バージョン情報 , 再送方式 , ウイン んて、いる。 SINIT プロックて、送信される情 この処理をネゴシェーションと呼 わせる。

通信プロトコル研究 CRC XMODEM の場合は , XMODEM の 転送開始の合図となる NAK の代わりに , ℃〃 というキャラクタを受信側が指定する。℃〃 を送っても 3 秒以内に応答のない場合は 4 回 まて、℃クを送る。それて、も応答のない場合 は , 送信側が CRC の機能を持っていないと みなし , NAK を送信して , 以後は CRC て、な くチェックサムを用いた XMODEM 手順を 実行する。この方法て、は , ℃〃が NAK に化 けた場合 , あるいはその逆のケースがトラ プルの原因となることが考えられる。しか し , 現実的には極めて希なトラブルて、ある ため , このエラーチェックレベルは実用上 ひとまず耐えられると考えるのが妥当だろ う (Fig. 4 ) 。 バケット回線を経由してデータ通信を行 う場合は , プロックが長いほうがバケット の長さに対する余り部分のタイムアウトが 少なくなり , さらに , アクノリッジを戻す Fig. 5 XMODEM ー lk テータフロー概路 ACK ー > MODEM-lk ACK ー - > 回数も減るため , 総合的に転送速度を向上 することがて、きる。そこて、 XMODEM のプ ロックサイズを 1024 バイトにしたものが XM ODEM-1k て、ある。これは従来の XMODEM と手順はまったく同じて、 , ロングバケット に対する処理が追加されているだけて、ある。 バケットの長さが 128 バイトのときに使われ る SOH の代わりに STX が用いられていると 1024 バイトプロックと解釈される。フロー 概略は Fig. 5 のとおりて、ある。 実際は , 128 ノヾイトプロックと 1024 ノヾイト プロックの混在が可能て、ある。受信側は , SOH と STX を見分けて処理すれば , 両者を 区別て、きるからだ。 とくに , データの長さ がプロックサイズて、割り切れないような場 合 , 残り部分をパディングして最後のプロ ックの長さを合わせなければならないが , このときに残りデータが 128 バイト以下て、あ ある。バケットが長くなることにより , チ XMODEM ー lk のエラーチェックは CRC て、 れば , 128 バイトプロックを利用したほうが 合理的て、ある。 受信側 <— STX <— C 日 C <— CRC く一 STX く一 02 《ー CRC 《ー CRC ACK ーラ 《・一 EOT 送信側 ー > ( チェックサムによる送信指定 ) ( プロック開始 ) ( プロック番号 ) ( フ、ロック番号を反転させたもの ) ( 実際のデータ 1024 ノヾイト ) ( CRC の上位ノヾイト ) ( CRC の下位ノヾイト ) ( 転送終了 ) ( 上記手順を , テータがなくなるまて繰り返す ) ( CRC の下位八イト ) ( C 日 C の上位バイト ) ( 実際のテータ 1024 ノヾイト ) ( フロック番号を反転させたもの ) ( プロック番号 ) ( フロック開始 ) ェックサムの検査て、は , 特定のビットが化 けるようなエラーへの回復力が期待て、きな くなるためて、ある。 MO ロ EM 誕生の背景 XMODEM は BBS の転送プロトコルとし て標準的な位置を占めると急速に普及した が , その機能があまりにも単純て、あるため , 改善の余地をいくつか残す結果となった。 とくに大きな問題は , ある種の環境下て、は 速度が著しく低下してしまうことだった。 通信回線の中には , バケット回線を経由 する場合がある。大量のデータをやり取り YMODEM 入されている。一定の時間待っても次のデ トの処理にはタイムアウトという概念が導 きない。これて、は都合が悪いのて、 , バケッ ては , いつまて、たっても送信することがて、 しかし , 256 バイト受け取るまて、待ってい には送信されない ら一気に送信することになるから , ただち 則として 256 バイトのデータを受け取ってか ある。このようなときには , バケットは原 トという長さが 256 より小さいということて、 こて、注目してほしいのは , 128 十バイ トを再度送信することになる。 る。 NAK が戻ってきたら , 今送ったバケッ かの応答を待ち , OK なら次のプロックを送 ところて、 , データが正しく伝わったかどう クて、データを送る。各プロックを送信した EM のプロトコルは , 128 十バイトのプロッ トを処理する場合を考えてみよう。 XMOD たとえば , 256 バイトのデータ単位て、バケッ ータがまとまってから送信することにある。 バケットの基本的な発想は , ある程度デ に関しては弱点を持っことになる。 あるが , 反面 , リアルタイムのレスポンス するためにはバケット化は効率的な技術て、 特集通信プロトコル研究 43 ータがこないなら , 受け取ったデータがパ

アクノリッジには 2 種類ある。データを正 て、ある。便りのないのはよい知らせと解釈 件となる。 常に受け取ったという合図のためのアクノ するのて、ある。 これを達成するためには , 次のふたつの リッジのことを , ポジテイプアクノリッジ 機能が不可欠て、ある。まず , 工ラーが発生 ACK や NAK に用いられるキャラクタ , あ したときに , それを検出して , なんらかの (ACK) と呼ぶ。これに対して , データが正 るいはデータは , コントロールコードの AC 方法て、対応てきること。これは , 検出の手 しく受け取れなかった , すなわち異常があ K, NAK だけて、はなく , プロトコルによっ ったことを知らせる合図のためのアクノリ 順がまず重要て、あり , さらに , 工ラーが発 て異なっている。 ッジを , ネガテイプアクノリッジ (NAK) と 生したときに , どのようにして修正するか という点がポイントになる。方法としては , 送信側は , NAK が戻ってきた場合には , バイナリのデータを転送するためには , ある程度冗長なデータを生成しておき , 多 それに応じて適切な処理をしなければなら すべてのデータを誤りなくやり取りて、きな 少のエラーは受け取り側て、修正するような ければならない。て、は , 全データが正しく ことも考えられるのて、あるが , 現在主流の もう一度バケットを送信 ない。おそらく , するか , 処理をすべて中断するかて、ある。 受信て、きたことを , どのようにして確認す 通信プロトコルにおいては , バケット単位 このように NAK の判断は重要て、あるが , A ればよいだろうか。通信プロトコルて、よく て、エラーの有無を判断し , もし工ラーがあ 使われるエラー検出方法は , チェックサム CK が戻ってきた場合は , 基本的に次々とデ れば再度同じバケットを送信するように送 と CRC て、ある。チェックサムは , プロック ータを送っていればよい。そこて、 , 通信プ 信側に指示することによって , 工ラーを回 ごとに , すべてのバイトの情報を加算した ロトコルをうまく設計することによって , 避しているものが多い ACK を受け取る処理を省略することがて、き 結果を比較する方法て、ある。 もうひとつは , すべての文字をデータに れば , ACK を待っための時間が節約て、きる 処理は簡単だが , 合計が同じになるよう 含める機能を実現することて、ある。 XMOD な化け方て、データが変化していると検出て、 のて、 , データ転送を高速化することが可能 EM のように , 全キャラクタが通ることをあ らかじめ回線の前提条件としてもよいが , TabIe 2 コントロールコードー覧 その場合にはコントロール文字の扱いに難 コントロールコード があるのて、 , 一般的手法としてはコントロ Cont 「 0 ト@ ール文字をクオートすることによりこの間 Contro ト A 題を解決する。 Contro ト B Contro ト C Contro ト D Contro ト E Contro ト F Contro ト G Contro ト H Cont 「 0 ト Contro ト J Contro ト K Contro ト L Contro ト M Contro ト N Cont 「 0 ト 0 Contro ト P Cont 「 0 ト 0 Contro ト R Cont 「 0 ト S Contro ト T Contro ト U Contro ト V Contro ト Contro ト X Contro ト Y Contro ト Z Cont 「 0 ト Cont 「 0 ト \ Cont 「 0 ト ] Contro ト Contro ト 工ラー検出 表記 ( 値 ) NUL(OxOO) ( 0X01 ) STX(Ox02) ETX ( 0X03 ) EOT ( 0X04 ) 日 ( 0X05 ) ACK(Ox06) BEL(Ox07) BS ( 0X08 ) HT ( 0X09 ) LF (OxOa) VT (OxOb) FF (OxOc) CR (OxOd) SO (OxOe) (OxOf) DLE(Ox10 ) DCI ( 0X1 1 ) DQ ( 0X12 ) Dß ( 0X13 ) DC4 ( 0X14 ) ト↓ ( 0X15 ) S Ⅷ ( 0X16 ) ETB(Ox17 ) 、」 ( 0X18 ) EM ( 0X19 ) SUB ( 0X1 a) ESC(Ox1 b) FS ( 0X1 c) GS (Ox1d) RS (OxIe) US (Ox1f) Nu 広旧厄 Start of heading Start Of text E nd of text End Of transmission Enquiry Acknowledge BeII, beep, 0 「 fleep Backspace Horizontal tab Line feed Vertical tab Form feed (top of page) Car 「 iage 「 eturn Shift out Shift in Data link escape Device control 1 , XON Device control 2 Device control 3 , XOFF Device control 4 Negative acknowledge Synchronous idle End of transmission block Cancel End of medium Substitute Escape, prefix, altmode File separator Group separator Record separator Unit separator 明 説 五ロ 用 いくつか , 通信プロトコルに特有な用語 について説明を試みる。 アクノリッジ , ネガテイプアクノリッジ バケットごとにデータを送る機能を実現 するには , 送信側 , 受信側の役割を次のよ うに分担すればよい。まず , 送信側はバケ ットを送り出す。受信側は , バケットを受 け取る。これらは当然の処理て、ある。しか し , 実際はデータが化けたり抜けたりして , 正常に送受て、きないことがある。このよう な場合には , 受信側から送信側に , データ が受け取れなかったとか , 正しく受け取れ たとか , 知らせてやることになる。このよ うな応答のことをアクノリッジという。 38 C MAGAZINE 1993 2

通信プロトコル研究 解釈すれば , < DLE > 十十の部分が , 十バケ このようなコードはまず必要ないのだが , コントロールコード 途中て、インタラクテイプな処理が必要にな ットの送信要求を意味し , < DLE > 0 は ACK を意味することになるのだが , そこまて考 った場合には , 判断まて、の時間がどれくら B Plus プロトコルて、使われるコントロー える必要もないだろう。 いかかるかわからない。「このファイル名て、 ルコードを以下に説明する。 いいて、すか」と尋ねると , ューザが考え込む ACK ENQ B Plus て、は , ポジテイプアクノリッジの かもしれないのて、ある。 表現は < DLE > にシーケンス番号を続けて たとえばレジュームダウンロードを指定 0X10 。イニシェータからレスポンダに対 して最初に送られてくるコード。 B Plus に 2 バイトとする。これにより , どのバケット したが内容が異なっているとき , 既存ファ よるデータ転送開始を意味する。レスポン を正常に受信したかを相手に正しく伝える イルに上書きするか , それとも別のファイ ダはこれを受け取った時点て、 , 1 プロック = ことがて、きる。工ラーが検出された場合は , ル名て、ダウンロードするかを選択させる場 512 バイト , 工ラーチェック = チェックサム 当然 ACK を送信せず , NAK を送ることにな 合などにこのような処理が発生する。ュー 形式 , シーケンス番号 = 0 の状態に初期化す ザが考えている間にタイムアウトとなり転 る。 送処理が中断してしまったら笑い話になっ Wait レスポンダはこの初期化が完了して , デ BPlus て、は , <DLE> ; ( セミコロン ) とい てしまう。 ータを受信て、きる状態になったら , <DL う 2 バイトが時間待ちのためのコントロール また , 双方の都合て、 , 処理に時間がかか E > 十十く DLE > 0 の 5 バイトのデータをイニ コードに割り当てられている。 る場合も考えられる。 B PIus の場合は , レ データ転送が実際に始まってしまえば , シェータに送信する。この内容を分解して シュームダウンロード , レシュームアップ ロードの処理を始めるときに , ファイルの TabIe 5 (Type) の種類 内容に対する CRC を計算しなければならな い。大きなファイルの場合や , システムの 負荷が高い場合には , この計算時間がかな り必要になることも考えられる。おそらく , その時間の大部分は計算そのものて、はなく , ファイルアクセスに費やされるのて、あるが , この間にタイムアウトになってしまうと , これも笑えない そこて、 , 一定時間処理を行っても , 次の データを送る見通しが立たない場合には , タイムアウトとみなされる前に もう少し 待たせるための指示を出すのて、ある。 NAK NAK (Negative Acknowledge) は , < N AK> ( 0X15 ) の 1 バイトて、ある。これはなん らかのエラーが発生したことを意味する。 バケット番号が異常て、あるとか , CRC が合 致しなかったり , 一定時間待っても相手か ら何もデータが到着しない場合 ( タイムアウ ト ) に送るコードて、ある。データ送信側が N AK を受け取った場合は , < ENQ > く EN Q > を送信し , これに対してふたつの異なっ た ACK が戻ってくるのを待つ。これは双方 のシーケンス番号を合致させるための処理 て、ある。 内 容 転送のためのバラメータを含むノヾケット ファイル転送のための情報を含むバケット テータを含むバケット 処理失敗を意味するバケット 十下 Z tL Fig. 17 ダウンロードレジュームの例 レスポンダ ( 以下 , 通常と同様 ) TC イニシェータ Dow 司 oad 要求 既存テータ情報の通知 続きのテータを送信 送信終了 レスポンダ Download 要求 既存テータ情報の通知 失敗した ( 以下 Failure Packet の手順に従い処理中止 ) イニシェータ レスポンダ ( 以下 , 通常と同様 ) イニシェータ DownIoad 要求 既存テータ情報の通知 テータが一致しないことを通知 最初からテータを送信 送信終了 特集通信プロトコル研究 51

れ以外の関数は見えても意味がないのて、あ る。そこて、 , 外部から呼び出す関数以外を static とし , 隠蔽するためにひとつのファイ ルにまとめたのだ しかし結果としては BPlus の処理を記述 するソースファイルが 90K バイトにもなって しまい , あまりおもしろくない。さらに検 討が必要て、あるといえよう。 BPL は現在最新バージョンが 52 て、ある が , 細かい変更により不規則に更新されて いる。最新のソースプログラムは NIFTY- Serve のプログラマーズフォーラム (FPRO G) て、公開されているのて、 , あまりおもしろ くないプログラムて、あるが , 参照していた だければ幸いて、ある ( 編集部注 : 1992 年 12 月 12 日現在のものを付録ディスクに収録した ) 。 BPIus のプロトコルの仕様概略はすて、に 述べたのて , 以下は , ポイントとなる処理 がどのように記述されているかを中心にい くつかの処理を例に説明をする。 バ , ット処理 ( 受信 ) いうまて、もなくもっとも重要な処理がパ ケットの送受信処理て、ある。 BPL の中て、 は , wait for acknowledge という関数がパ ケット受信処理になる。 BPIus の処理の中 て、もっともややこしい処理なのだが , ドキ ュメントを参考にして , てきるだけ忠実に 書いたつもりのものが List 2 て、ある。しか し , C のプログラムとして見ると , あまり美 しい構造とはいえないようて、ある。 構造としては , while ループの中て、 , デー タを受信して , それによってバケットが完 成したり , ACK や , そのほかコントロール コードを受け取れば , 受信データに応じた 処理を行うという感じて、ある。 sts という変 数が終了条件になっている。 あまり美しくない点を指摘すると , まず , チェックサムを計算する処理のために , < c hecksum > という変数がアドレス渡しとし 62 C MAGAZINE て使われていること。 1993 2 という変数を外に見せたくないために こは , < checksum > List 3 : 5 : 6 : 9 : 10 : 13 : 14 : 18 : 19 : 20 : 21 : 22 : 23 : 24 : 25 : 26 : 28 : 29 : 30 : 32 : 33 : 35 : 36 : 37 : 38 : 39 : 40 : 43 : 44 : 45 : 46 : 48 : 49 : 50 : 52 : 53 : 54 : 55 : 56 : 58 : 59 : 60 : 62 : 63 : 64 : 66 : 68 : 69 : 76 : * packet を受け取った場合は、 1 を戻す。内容は current-packeto * ack が得られたら、 0 を戻す。 2 : / * ACK 待ち状態の FSA wait for acknowledge 関数 sts ニ s-resend-packets() : case S_Resend-Packets: break; sts s-send-enq() ; case S_Send-ENQ. break, s ts = 0 : s_send_ack(); case S_Send_ACK : break; sts = s-send-nak ( ) : case S_Send-NAK : break; sts = s-verify-packet() , case S-Ver i fy-Packet : break , sts s-veri fy-cks(checksum) : case S-Vei fY-CKS : break. sts s-veri fy-crc(checksum) , case S-Ver i fY-CRC: break; sts = s-get-crc(&checksum) ; case S_Get_CRC: break; sts = s-get-check(&checksum) : case S_Get-Check: break; sts = s-get-data() : case S_Get_Data: break; sts = s-dle-b-seen() : case S_DLE_B_Seen. b reak ; StS = s_dle_seen(receive) : case S_DLE_Seen: break ; sts = s_get-dle(receive) : case S_Get_DLE: svitch (acknovledge-status) { vhile (sts > = の { after-enq = 0 : int sts UWORD checksum; 7 : STATIC int wait_for-acknovledge(int receive) * error の場合はく 0 break; if (sts = FINISH) { sts = acknovledge-status return Sts; = S-Verify-Packet ? 1 : 0 :

そのバケットまて、戻ってそれ以降のバケッ トを再送する方式て、ある。ドキュメントに 書いてある特徴としては , 以下の 2 点が指摘 58 C MAGAZINE 1 3 2 クがうまくいかなかった場合に , コントロ に , なんらかの原因て、双方のハンドシェイ に基づくひとつの弱点て、あろう。このため プロック構造をそのまま継承していること この特徴は , Quick-VAN が XMODEM の たまま使えないなどのデメリットも生じる。 ないが , その反面 , XON/XOFF を有効にし て、速度の点て、はメリットが生じるかもしれ 類のコードとなる。クオート処理がないの ODEM と同じく生のデータそのままの 256 種 すなすち , Quick-VAN て、扱うデータは XM サポートされていないという特徴がある。 較すると ,Quick-VAN のみクオート処理が Quick-VAN と ZMODEM, B Plus とを比 は記述されていなかったため不明て、ある。 葉がドキュメントに出てくるが , その詳細 ack N のほかに , 選択的再送方式という言 Quick-VAN の再送方式としては , Go b 方法は処理が若干複雑になる。 理時間の節約にも結びつく。ただし , この のネックになるような場合には , 全体の処 が節約て、きるのて、 , 回線の通信速度が処理 えられる。この場合は , 当然データ転送量 あれば , それは再送しないという選択も考 ケット以降に正常に受信て、きたバケットが 式もある。すなわち , 工ラーが発生したパ 工ラーが発生したバケットのみ再送する方 バケットをすべて再送する方式のほかに と思われる。工ラー発生時に , それ以降の 処理が簡単になる , ということて、はないか よく意味がわからなかった。プログラムの とがて、きる , と書いてあるのだが , これは その結果 , オーバヘッドを低く抑えるこ ーケンス番号のみ保持すればよい 信し , 正常に受信した最終プロックのシ ・受信局はシーケンシャルにプロックを受 号のみを保持していればよい 応答された最終プロックのシーケンス番 ・送信局は送信済みの最終プロックと肯定 されている。 TabIe 9 受信局タイマー覧 受信局タイマ トランスポートネゴタイマ (RTI) タイムアウト処理 リセット条件 セット条件 タイマ値 機能概要 フェーズ ファイル情報ネゴタイマ (RT2) タイムアウト処理 リセット条件 セット条件 タイマ値 機能概要 フェーズ ネゴサプフェーズ 1 内 転送開始要求タイマ ( RT3 ) タイムアウト処理 リセット条件 セット条件 タイマ値 機能概要 フェーズ く NAK > 送信後 , S 爪受信監視タイマ 20 秒 く NAK > 送信時 S 爪ほ受信時 タイムアウト時 く CAN > 受信時 <NAK> 再送 1 0 回目はく CAN > 送信で異常終了 ネゴサプフェーズ 2 スキップサプフェーズ ( オプション ) 印 NIT または VSKIP ( オプション ) 送信後 V 日 LE 受信監視タイマ 20 秒 NIT または VS 灯 P ( オプション ) 送信時 V 日 LE 受信時 タイムアウト時 く CAN > 受信時 く EOT > 受信時 ネゴサプ 2 の場合 R 爪ぼを再送 スキップサプの場合 V 引 KP を再送 同一ファイルに対し 10 回目はく CAN > 送信で異常終了 1 0 回目はく CAN > 送信で異常終了 VRPOS を再送 タイムアウト時 く CAN > 受信時 VDAT 受信時 (n=l 以外も該当 ) V 日 POS 送信時 20 秒 VRPOS 送信後 , 最初のテータロック受信監視タイマ テータ転送フェーズ ( 開始モード テータブロック監視タイマ ( RT4 ) フェーズ 機能概要 タイマ値 セット条件 リセット条件 タイムアウト処理 テータ転送フェーズ ( 通常モード , 再送モード ) VACK または VNAK 送信後 , VDAT 受信監視タイマ 20 秒 VACK または VNAK プロック送信時 VDAT 受信時 タイムアウト時 く CAN > 受信時 VENQ 受信時 VNAK プロック送信 同一プロックに対し 10 回目はく CAN > 送信で異常終了 転送終了 / 継続監視タイマ (RT5) タイムアウト処理 リセット条件 セット条件 タイマ値 機能概要 フェーズ ールコードは , データにそれが含まれる場 BPlus て、は <DLE> という特別なコントロ タが区別て、きない , ールコードとプロックに含まれているデー 1 0 回目はく CAN > 送信で異常終了 VSTAT 再送 く EOT > 受信時 く CAN > 受信時 タイムアウト時 V 日 LE 受信時 VSTAT 送信時 20 秒 VSTAT 送信後 , く EOT > または V 日 LE 監視タイマ 転送終了 / 継続フェーズ という問題が生じる。 けるために , Quick-VAN においてはコント の処理が問題て、ある。このような事態を避 受信側においては , データが欠落した場合 されているが , Quick-VAN の場合 , とくに 合には必すクオートされるのて、区別が保証 ロールシーケンスの検出方法が定められて おり , 少し工夫が必要になっている。 コントロールシーケンスは以下の条件が 満たされた場合のみ有効とみなす。 ①プロックのヘッダ , またはコントロール シーケンスを検索中に , 初めの 1 バイトが 当該 1 バイトキャラクタて、あった場合。た だし , ヘッダまたはコントロールシーケ ンス検索中に , 初めの 1 バイト以外に当該