混沌の廃墟にて -56-

Flying-XMODEM (3)

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

[↑一覧] [新着] [ホームページ]

次は送信の場合の高速化である。flying するという発想さえ思い付けば、話は 実に簡単だ。まず、通常のハンドシェイクを再掲して、どこに手を入れられるか 考えてみよう。 

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

            ...

        <-- ブロック ---
        ---   ACK    -->
        <--   EOT    ---
        ---   ACK    -->
この場合、MNP という状況を前向きに解釈すれば、必ず ACK が返ってくるとい う都合のよい思い込みができる。ならば ACK など待たずに次のブロックを送り出 してしまえばよい。私はこのような思い込みに基づいたデータ先読みを Look ahead value と呼んでいるが、この際それはどうでもよい。 
    受信側              送信側
        ---   NAK    -->
        <-- ブロック ---
        <-- ブロック ---
        ---   ACK    -->
            ...

        <-- ブロック ---
        ---   ACK    -->
        <--   EOT    ---
        ---   ACK    -->
        ---   ACK    -->
実際はどこで ACK が返ってくるかわからないのである。私の使っているモデム は全二重なのだ。半二重ではない。だから、ACK が返ってくるのが遅れても、次 のブロックを送信している間に ACK が返ってくるのではないかと期待しているの だ。で、返ってこないとどうするか。次のブロックを送ればよいのだが、さすが に調子に乗り過ぎると無手順と変わらなくなってしまうので、バッファがオーバー フローしてしまうだろう。

だから、どの程度ブロックを先送りできるか慎重に判断しなければならない。 慎重と書いたのは実は格好を付けただけで、実際はイイカゲンに判断して、2つ 位なら先送りしても何処かのバッファに留まってくれるだろう、と独断してみた。 2つ送って何も返ってこなければ、そこで初めて何か返ってくるのを待てばよい のである。

MNP で接続したにもかかわらず NAK が返ってくるようなケースもあるだろうか、 その時はその時である。本当にこんなのでよいのかと思いつつ、実測してみると 次のようになった。一つだけ早い測定値があるが、これは先送りの数を１つ増や してみた場合である。 

    No  dir'    bytes   m's"        speed   pr  soft    memo
    5   up      18368    3'09"84     96.7       termy
    6   up      18368    2'06"92    144.6   *   fprgt
    11  up      85862   10'00"46    143.1   *   fprgt
    12  up      85862    6'44"16    212.5   *   fprgt   new upload routine
    21  up      29440    3'29"55    140.5   *   fprgt   FENICS
これを見ると termy が遅いように見えるが、決してそうではない。真面目に XMODEM すればどの通信ソフトを使っても 100 程度の速度になることを付け加え ておこう。 
    *
ついでだからテキストの upload についても高速化した。テキストの場合、主 流は２つあると思う。 
    １）ウエイトを入れて、１行ずつ無手順で送信
    ２）改行コードがエコーバックしてくるのを確認しながら送信
１）は十分ウエイトを入れれば確実に送信でき、エコーバックがなくても利用 できるという特長もあるが、半面ウエイトを入れるから確実に無駄な接続時間が 増えることになる。接続時間の面では２）は安全のようだが、ここで XMODEM の 事例と同様のパケットの葛藤が発生し、MNP で接続するとなぜか MNPなしの場合 よりも遅くなってしまう。図にすると一目瞭然。 
    受信側              送信側
            <--  .. --- (１行のデータ)
                 ..
            ---  LF --> (改行コードのエコーバック)
            <--  .. --- (１行のデータ)
                 ..
            ---  LF --> (改行コードのエコーバック)
うむ、これなら早い話がエコーバックの LF を XMODEM の ACK と同じ扱いにし て、さっさと次の行を送ればよさそうだ。この場合も XMODEM と同様に、数行前 の改行コードが戻ってこなければ休憩して待つことにすればオーバーフローしな いと予想した。 
    *
FPRGT はこのように世界でもまれに見る無節操かつ不作法な通信ソフトに成長 しつつある。それを使ってフォーラムの保守に手を付けようとしている SYSOP が さらに無節操であることは、いまさら言うまでもない。(*1)

補足

(*1) FPRGTは消滅したが、会員にメールを送信するプログラムに処理が部分的に 使われている。FPRGT消滅後数年、現在稼働している自作通信ソフトは「魔王」と いう名前になった。テスト版はFPROGにソース込みで公開されているが、これ専用 の会議室はアクセス不信で閉鎖になってしまった。
「魔王」にはフォーラム保守機能を追加した「裏魔王」があり、かなり役に立っ ている。 

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