混沌の廃墟にて -246-

トラブルの日々

1996-03-02 (最終更新: 1996-03-21)

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


何か、最近、いきなり仮名漢字変換で思った漢字が出てこないことがある。 Windowsを起動した後はどうも変だ。「廃墟」が「廃虚」になってしまうのだ。 「廃虚」という単語は最初から入っているのだが、こんな単語は使わないので消 してしまいたいのだけれども、その方法が不明なのである。WWWにアクセスしなけ れば、Windowsなんて使わずに済むのだが。

WWWを使うにしても、とにかく混雑を何とかしてもらわないと話にならないとい う現実があって、28,800bpsでコネクトしたのに、画像の転送時に表示される速度 が200バイト/秒だったりすることは日常茶飯事。途中でエラーが発生することも ある。

RIMNETからアクセスしていると、特にbekkoameを見に行く時に遅いような気が する。bekkoameの人に言わせると、特にRIMNETは遅いんだそうだ。bekkoameと RIMNETの間はもしかして2400bpsのRS232Cで繋がっているかもしれない。:-)奇妙 なことに、かなり遠方にありそうな海外のサイトからデータを持ってくるような 時には3KB〜4KB/秒の速度が出たりして、不思議だ。

RIMNETは、まるでFENICS-ROAD5東京APをアクセスしているがごとく、BUSY,BUSY の嵐で、なかなか繋がらなかった。(*1) 1200bpsのモデムでネットに初めてつないだ時、 百回リダイアルしても繋がらなかったものだが、まさにあの頃の再現のようだ。 最近、電話番号を変えたら繋がりやすくなった。

しかも、なかなか接続できないだけならともかく(それだけでも許し難い状況だ が)、PPPの接続が成立してから、何をやっても他と接続できないことがある。こ れは課金されるので、とんでもない話だ。(*2)

    *
私のページで一つ困ったのは、音楽データを掲示したいのに、それをどうすれ ばよいか分からないということで、いろいろ調べたのだが、どうもデフォルトの 方法が確立していないような気がしてきた。midのデータをそのまま入れてあるサ イトもあれば、lhaで圧縮している所もある。wave形式にしている場合もあって、 これはやや標準的かもしれないが、データがMIDIのデータの100〜1000倍程度のサ イズになってしまって大きくなりすぎである。

.midのままデータを入れる方法がよく分からないのだ。そのまま入れてしまえ ばよいのかもしれない。

逆に、音楽データを掲示しているサイトは、いくつか見つかった。ところが、 そのデータを聴こうとしているのだが、まだ一度も成功したことがない。どうす れば聴けるのか分からないのだ。ということは、逆もまたしかり、ということで、 私が音楽データを掲示しても、どうやって聴けばいいか分からない人が出るとい うことだ。マルチメディアの実態はこの程度のものなのだろうか。

    *
WWWで情報発信と言っても、発信する情報がなければ何にもならない、と以前書 いたことがある。私の場合は、一応、出すネタがあって、例えば、「混沌の廃墟 にて」の昔のデータを出している。なにしろこの回数なので、毎日一つずつ出し ても半年以上持つ。できるだけ毎日追加することにしている。

ところで、これは順番に出しているわけではないため、読む方は何を読んだか 分からなってしまうかもしれない。そこで、一応、新規登録をまずいくつか最初 にメニューで出すようにして、その後に全リストを出すように工夫した。毎日ア クセスしている人なら、ページの最初だけを見ればOKである。もっとも、1週間 以上アクセスしないと未読の回へのリンクが新規登録のメニューから消えてしま うから、NetScapeのようにキャッシュが効いたブラウザを使って、一度読んだリ ンクを色で見分けるしかない。

それにしても、このデータをその場で読むとすれば、やはり200バイト/秒程度 の速度でデータをアクセスすることになってしまうので効率が悪いはずだ。

さて、この方法でも、だんだん件数が増えると、「廃墟にて」のエントリペー ジのサイズが大きくなってきて、時間がかかってしまう。そこで、エントリペー ジとリストページを分けることにした。これだと、毎日読んでいる人には便利か もしれない。ちなみに、一か月でアクセスした人がのべ約600名である。(*3)

ISDNでない電話回線でアクセスしていると、接続の手順に結構時間がかかる。 すると、接続したまま読んでしまったりするのである。回線が絶望的に足りない 所に、こうやって無駄な使い方をしていると、みんなで協力して破滅へ向かって いるようなものだ。インフラが整備されていない世界を開放するとこうなる、と いう典型的な例のようなものだ。話のネタになるかもしれないから、ISDN接続を 検討してみるという手もあるが、NIFTY-ServeのISDN回線は9600bpsだそうで、こ れまた困る。

    *
最近はどのネットでもニュースグループを読めるようになってきた。私が頻繁 に使っているサービスだけでも、NIFTY-Serve以外にASCII net、People、日経MIX、 RIMNETでニュースを読むことが可能だ。で、どこを使うかというと、NIFTY-Serve は例の致命的欠陥(*)があるので論外として、やはり課金と使いやすさからRIMNET を使うことが多い。
 (*) 記事の中に1行の長さが改行コードを除いて80バイトの倍数になった時に、 改行コードが消滅してしまう。例えば、ヘッダーのPath:が偶然この長さに なると次のFrom:フィールドと連結してしまって、「行頭からFrom:」で検 索してもヒットしないという問題が発生したことがある。
ただ、trnでその場で読むのは28.8kbpsの速度が無意味なので、一旦ファイルに セーブしてからダウンロードして、それをゆっくり読んでいる。ここでちょっと 問題が発生した。ファイルにセーブすると、できるファイルはJISコードのままで ある。UNIX上でlessを使って自動判別させる手もあるが、基本的にDOSで読むなら Shift-JISに、UNIXで読むならEUCに変換しなければならない。そこで、これを手 元のパソコンで読む時にShift-JISに変換することにした。最初、RIMNETにシェル モードに入った状態で、jistosjというフィルタを使ってこの変換を行っていたの である。これがどうも様子がおかしい。ある記事から後がバケまくることがある。 それも、いわゆる1バイトのアスキーコードに該当する所が読めないというから尋 常ではない。

そのデータをJISのまま手元に転送して調べてみた。DOS上でnkf -sを実行して みたら、その「ある記事」の内容が全く意味不明のコードで、読めないのである。 最近、この手のワケのわからない記事がちらほらしている。実は私もメールでこ の失敗をしたことがあるので、偉そうなことは言えないのだが。

しかし、その後は問題なく読める。どうやら、jistosjで処理すると、一旦何か の拍子に状態が狂った後、ずっと変な状態のまま処理を続けるらしい。nkf -sの 方が状態復元能力は強いようだ。とりあえず、jistosjは使わないことにして、問 題は一応解決した。

さて、メールの場合もニュースと同様だが、こちらはEUCで入っている。これを nkf -sで処理すると、所々変だ。調べてみると、いわゆる半角仮名の処理が変な のである。nkfはこのコードに対応していないとドキュメントに書いてあったよう な記憶がある。仕様なら仕方無いので、とりあえず、EUCからS-JISに変換するよ うなプログラムをちょこちょこと書いて使うことにした。ついでに改行コードの 変換もしてしまう。UNIXだと改行コードはLFのみだから、CRを追加するのである。 85行のプログラムである。ただ、実行するとnkfに比べてやけに遅い。出力に問題 があるのかもしれない。とはいっても、何時間もかかるのではなく、数秒とか10 秒程度で処理できるので、そのまま使っている。

    *
ネットニュースでない方のニュース、つまりニュース速報のクリッピングサー ビスは、相変わらず利用しているのだが、ここの所やけに調子が悪い。表示中に いきなり停止して、そのままである。しばらくすると、FENICSのレベルに落ちて しまう。

先月末にこの状況になった時に、ついに頭に来たわけで、GO CENTERで「こんな ので金を取る気か」とどやしてみた。何も表示されない状況で1分あたり150円と いうのはたまったものではない。経験的に、この手のトラブルは「言ってみる」 のがよい。ダメもとなのだし、もし通ればラッキーである。実際、これは通った のである。で、この分の課金は相殺するというメールが届いた。ラッキー…ん?  ちょっと待てよ。何かおかしい。

そう、実はこの時の課金は、ミニマムチャージ以下だったので、料金が相殺さ れようがされまいが、同じだったのだ。やられた。

こういうトラブルの場合、課金はどうでもいいから、とにかく再発しないよう に対策しろという一文を添えることにしている。謝ってもらえばいいという人も いるようだが、その都度謝ればいいという考えでいるなら、余計に納得できない ではないか。

で、まあ何とかしたかなと思ったのだが、ついさっきクリッピングサービスを 見ている時に、全く同じ障害発生。ニフティは直す気がないのか。とりあえずま たメールを出してみよう。オートパイロットで処理するというのもいいかもしれ ない。クリッピングサービスの処理中に放り出されたら、その次のアクセスでGO CENTERするようにしてみようか。


補足

(*1) これを書いた当時(2月初旬)はそうだったのだが、3月になってからほとんど一発接続になっている。

(*2) rim.questionsなどを見た感じでは、どうやらRIMNETのサーバーの何かのプロセスが動いていないとか、そのような問題があったらしい。

(*3) 毎日(実は毎時なのだが)カウンタをチェックしている。統計によると、最初の一か月は全く伸びなかったのだが、一日のアクセス数がだんだん増えていて、3月10日頃は一日100程度増えている。


    COMPUTING AT CHAOS RUINS -246-
    1996-03-02, NIFTY-Serve FPROG mes(6)-134
    FPROG SYSOP / SDI00344   フィンローダ
    (C) Phinloda 1996