混沌の廃墟にて -55-

Flying-XMODEM (2)

1989-05-09 (最終更新: 1996-03-29)

最初に一言書きたい。以下のアイデアは言わばあまりにも当然の発想であるため、既に他の人が考案しているかもしれないし、発表しているかもしれないが、私自身はこの方法を完全に独自に発想したと宣言しておく。(*1) 権利を主張するのではないのでアイデアは勝手に使ってもらって構わないが、たとえどのような被害にあっても私は一切責任を持たないので、そのつもりでいてください。(*2)

XMODEM のプロトコルの高速化というのは発想がそもそも普通じゃない。プロトコルが固定されているため、データを勝手に圧縮して送るわけにはいかない。しかし、常々 MNP と XMODEM のパケット干渉による速度低下によって、「電話代」という重いリスクを背負っていたので、今回は本格的に気合いが入ってしまったようだ。

まず、MNP + XMODEM という組み合わせに対して、ド素人の発想にしてすでに無駄だと思うようである。MNP でエラーフリーが保証されているはずなのに、XMODEM でエラーチェックするのは無駄だと思わないだろうか？ Checksum 程度ならまだしも、CRC のように面倒な計算をするのはもってのほかだ（本当は面倒という程のこともないのですが）。

では、まあせっかく自作の通信ソフトなんだから、MNP で接続した場合には受信の時の checksum の計算は省略してしまいましょう、と極めて行儀の悪い発想から全ては始まった。こういうオプティマイズは滅多に実現できるチャンスがあるものではないから、ものは試しである。エラーフリーなら checksum も CRC も合わないわけないと思えば、一応理屈には合っているでしょうが。計算しないで無条件で ACK を送ってしまおう。信じるものは救われる。

しかし、最近のパソコンは力をもてあましているので、たかが checksum の計算を省略した程度で速度は上がるだろうか(*3)。結局 MNP と XMODEM の葛藤が全く解決していないので、おそらく絶望的に効果がないだろう。プログラム作る側に取ってみれば、checksum の計算をはしょるだけでも楽だけど。

そこで、「どうせ ACK を送るんだから、ブロックを全部受け取る前に見込みで送ってしまえばいいじゃないか」と、極め付けに恐ろしいことを思い付いたのである。

普通の XMODEM は次のようにハンドシェイクする。

    受信側              送信側
        ---   NAK    -->
        <-- ブロック ---
        ---   ACK    -->
        <-- ブロック ---
        ---   ACK    -->

            ...

        <-- ブロック ---
        ---   ACK    -->
        <--   EOT    ---
        ---   ACK    -->

MNP と XMODEM のパケットが干渉するというのは、ACK を 1 文字送信する時に、しばらくタイムアウトを待ってから送り始めるのでその分損すると思えばよい。ところが、私の作った通信ソフトの XMODEM は次のようにハンドシェイクするのである。なんて不作法なんだ！(*4)

    受信側                          送信側
        <-- ブロック送り始め     ---
        ---         ACK          -->
        <-- ブロックを送っている ---

少し待つんだから、速めに ACK を送れば待たずにすむだろう。どうせ MNP だから文字が化けないに決まっている（と思い込んでいる）。ううーむ、しかしこれでは完全にフライングではないか、というワケで、これを Flying-XMODEM と名付けることにした。今試作中の通信ソフトでは、最初のバージョンでは ACK は 28 bytes データを受信した時に送る仕様になっていた。こんな無節操な発想で本当にうまく動作するのかいまいち不安はあったが、結果はちゃんと受信できて次の通り。補足しておくと、termy というのはフリーソフトの通信ソフトで、とてもお世話になっている。fprgt は言わずと知れた fprg term という意味だ。

    No  dir'    bytes   m's"        speed   pr  soft    memo
    1   down    33197    4'42'79    117.3       termy
    2   down    33197    4'31'96    122.0       fprgt
    3   down    33197    3'34"94    154.4   *   fprgt
    4   down    33197    3'21"94    164.3   *   fprgt

※OMRON MD2400F + EPSON PC-286U-STD を使い、NIFTY-Serve 東京直通回線に MNP class/5 2400bps で接続。(PC286-MODEM 4800 bps)。speed は bytes/sec.、pr が無印なのは普通の XMODEM、* があるのは Flying-XMODEM による。

※NIFTY-Serve のセンターホストとモデム間が 2400bps で接続されているため、 MNP/class 5 と言えども実効速度が 2400bps を越えることは理屈上ありえないことに注意。

120 bytes/sec から 160 bytes/sec に高速化されて、万歳、というわけだが、本当にこんな安易な発想でよいのだろうか？ …と一抹の不安を抱きつつ、FENICS だとどの程度改善されたのだろうと思い立って NIFTY-Serve 入会後初めて FENICS 経由でアクセスする(*5)。ところが、結果は芳しくなかった。

    20  down    29440    5'16"96     92.9   *   fprgt   FENICS

途中でパケットが衝突する機会が１つ増えたので、flying の効果がなくなってしまったのだろうか…。これでは fprgt を PDS にする売り文句がない(*6)。やはり全国どこでも遠くの人とオンライン・コミュニケーション、が全国ネットの売り文句であって欲しい。そのためには VAN の上でもちゃんと動作しなければ意味がない。

そこでさらに開き直って、途中でなどとケチなことは言わずにいきなり ACK を返してしまうことにした。

    受信側              送信側
        ---   NAK    -->
        ---   ACK    -->
        <-- ブロック ---
        ---   ACK    -->
        <-- ブロック ---

            ...

        ---   ACK    -->
        <-- ブロック ---
        <--   EOT    ---
        ---   ACK    -->

ブロックを受け取る前に ACK を返しているのである。こういうのもハンドシェィクと言うのだろうか…。どうせここまで開き直ったら、極めなければ面白くない。最後の EOT の後の ACK は受信開始の時に送ってしまえ、ときたもんだ。返すのは全部 ACK なのだから、数さえ合っていればいいじゃありませんか。

    受信側              送信側
        ---   NAK    -->
        ---   ACK    -->
        ---   ACK    -->
        <-- ブロック ---
        ---   ACK    -->
        <-- ブロック ---

            ...

        ---   ACK    -->
        <-- ブロック ---
        <--   EOT    ---

全体の ACK の数は変わらないので、ちゃんと理屈には合っている。

こんな目茶苦茶なハンドシェイクで本当によいのかと言うと、途中経路が MNP であることも影響していると思うのだが、どうやら何処かでバッファリングが正常に行なわれているらしく、非常識なことに問題なく動作してしまった。恐ろしいことだ…。

    22  down    52992    4'09"65    212.3   *   fprgt   FENICS / new fprgt
    23  down    29144    2'10"46    223.3   *   fprgt   FENICS

速度が 210 bytes/sec というのは、理解を越えた早さである。異様である。ほとんどテキストを無手順で表示する速度に近い。こんなに安易に成功してしまってよいのだろうか、呪いはかからないだろうか。なんと速度は倍近くになっている…ということは、電話代が半分ですむということではないか！

（つづく）

補足

(*1) 実際、あったそうである。

(*2) ニフティから「使うな」と言われた人がいたとか。もちろん、私にはそんなことを言ってこない所が渋い。そりゃニフティから見れば同じデータを半分の時間でやりとりされたら面白くなかろう。

(*3) 当時は2400bps程度だからよかったが、最近は回線速度が10倍になったので、下手な作りだとなかなか大変。

(*4) NIFTY-Serveプログラマーズフォーラムに「ソフトウェア無作法」(Software Fools)という会議室がある。

(*5) 当時は、東京にはFENICSを経由しない直通回線があった。そちらの方が実効速度が速かったのである。

(*6) fprgtは、当時勝手に作っていたFPROG専用通信ソフトの名前。フォーラムのgoコマンドがFPRGだった。このソフトは頓挫し、現在作成中、テスト公開されている「魔王」に思想が受け継がれることになる。

    COMPUTING AT CHAOS RUINS -55-
    1989-05-09, NIFTY-Serve FPROG mes(?)-096
    FPROG SYSOP / SDI00344   フィンローダ
    (C) Phinloda 1989, 1996