アーティクル

#2 Article 751 Posted at 1991/09/20 02:15:01 by 相友優mi (MAP268) [SYS.MODEM]
Subject: Re: Re: Re: 最近 /750 /749 /748
あら、書き込もうと思ってファイルを用意してきたら、もう同様な（ちょっと違うかな）書き込みが…

　リダイヤルしている間に、書き込もうとしている話題があるのは助かるというべきか
　なんか複雑な心境。

　それはさて置き、オフラインで用意してきた内容が以下です。

--


　最近のアクセスする時間帯の問題かもしれませんが、最近のMapleTownのBusy頻度と
　書き込み数の増大で、アクセスするにも通信時間とホストの処理速度（かなり改善さ
　れている様な気はしますが）が気になる気がします。
　つい２日ほどアクセスを空けただけで、MNP4の速度で全速 Allread の最中に

>　あなたの接続時間は 30 分を超えました。当ネットワークでは、できるだけ多くの
>方がアクセスできるよう、1 回のアクセス時間を 30 分以内にしていただくことをお
>願いいたしております。

　こういった警告の出る始末。（つまり３０分を越えてしまう訳です）
　アクセスするボード数の問題とかはこの場合別問題としても、平均的な週末アクセス
　もこう言った状況になると考えます。ボードのマスクなどしていても週１回程度の
　アクセス者なら同様の問題があるであろうと考えられる訳です。
　（最近の疑問点の指摘）

　アクセス頻度(=Busy頻度)については、回線数を用意するなどMapleTownではユニーク
　なホストシステムにより改善されているかに思っていたのですが、そのためか逆にホ
　ストの能力というかホストの処理速度がやや気になってきているのは以前の書き込み
　の内容からもわかる通りですよね。（現状の問題点の確認）

　ところで、このホストの処理速度の問題が解決してもアクセス頻度を下げる方向では
　無いような気がするのです。
　ホストの処理速度が改善しても、アップロードに関わる部分の改善があるのみで、ア
　クセス頻度にはそれほど影響は無いと思えるからです。（次の問題点への導入）

　そこで安易ではありますが、ホスト速度改善をした場合に次のステップとしてモデム
　の通信速度を上げる事を考えてみたいのです。（今回の論旨）

　現在のモデムの通信速度（物理速度）は 2400bpsが最高速度です。また、エラーコレ
　クション（訂正）機能としては MNP-Class4 が用いられています。回線によっては
　Class5 による圧縮もかかっていますが、最終的に得られる通信速度は、2400bpsを
　前後する速度になっているのが現状と言えるでしょう。なぜなら 圧縮されたデータを
　ish データで変換している場合には Class5 の圧縮はほとんど期待出来ず、フルタス
　ク（回線が全て埋まっている状態）ではホスト側の処理が重いので転送速度が 平均
　速度（Class4では実効2900bps/Class5では3800bps程度）を下回るのは実感できる訳
　です。結局は 2400bpsの速度に限りなく近付いているという事なのでしょう。
　それはそれで、今のほとんどの通信には問題が無いとは思います。しかし、MapleTown
　の現状ではそれでは不足だと考えます。なぜなら、前に書いた通り、常識的な通信時
　間ではアクセスに足りないという現実があるからです。
　もう、説明の必要はないと思いますが、もうMNP-Class5まででの通信速度では足りな
　いという事が言いたい訳です。（今回の私の結論）

　現状で考えられる次の手段として以下のスペックを提案したいと思います。

　1. ホストプログラムの改善で、新たなプロトコル等を採用し実アクセス時間を下げる

    ファイル転送プロトコルを用意するというのが一つの手段というか、アクセス時間
　　の短縮になると考えます。なぜなら、ＣＧやソフトウエア等を必要としない人まで
　　アクセス時に無条件にdownloadする結果になる事がある訳です。
　　また、プロトコル等と言っているのは何もファイル転送だけの為の事ではなく、単
　　純にアクセスするときにも専用の端末などを使わないといけなくなりますが、モデ
　　ム等の圧縮とは無関係に圧縮がかかるといったものです。表現力が足りなくて意味
　　不明かもしれませんが、一番簡単に表現するとすると ホスト側の送り出す文字列を
　　一定の法則にしたがって圧縮し（つまり通常の端末では文字列として認識できない
    のですが）通信回線に乗せ、端末側で受信と同時に文字列に展開するといった、新
　　しい通信プロトコル（アクセスを無手順から変えられる）機能を持たすという意味
　　です。lha の結果が標準出力に出るとして
      lha a .. > aux 
　　の様な事をホスト側でして
      cat aux | lha > con
　　という事を端末側ですると言うようなイメージではあります。

　2. モデムの速度を向上させる

　　一番手間がかからずに（とはいえホスト側の速度改善等が先ですが）できる事だと
　　思います。
　　具体的にはモデムの通信速度（及び規格）は多種ありますが、ここ数年の動きを見
　　る限りだと
      CCITT V.32/V.32bis (9600/14400bps 物理速度)
　　の物理速度が一般的で （トレイルブレイザやHSTなども独自規格でしたが、最近は
　　V.32/32bis を含めた製品を用意しているところからも）これから主流になると考え
　　ます。
　　また、エラー訂正は
　　　CCITT V.42 (LAP-M , 含む MNP-Class4)
　　になること、そしてその専用の圧縮手順が
      CCITT V.42bis (最大 300%の圧縮)
　　であり、MNP-Class5 の様に無理にでも圧縮するような事はしないで実効通信速度の
　　維持ができることなどから、考えられるモデムの姿は

　　　CCITT V.32/V.32bis + CCITT V.42/V.42bis

　　という物理層 9600bps 以上 最大効率 40000bps 以上程度のものになるのですが、
　　そこまでは現実的に望めないので おそらく平均 9600bps 程度維持できれば良いと
　　考えます。要は物理層が上がった分、実質的に４倍の通信速度が得られアクセス時
　　間が完全に１／４になると考えられるからです。（当然 chatやオンライン書き込み
　　では改善される訳ではありませんが）

　　予め想像が付きますので、書いておきますが、ユーザ側のモデムがホストの速度と
　　同じものでなければ、現在と変らないのは確かです。ただ、ホスト側が変化しなけ
　　ればユーザ側のモデムが変化しないのも確かです。いくら高速なモデムをメーカが
　　売り出しても、ホスト側のモデムが低速のままであれば誰も買わないでしょう。
　　そういう見地からもホスト側のモデムの速度が改善されることを期待します。

　こう言った事は既に Sysop 側では考えられて居ると思われますし、今更考えるまでも
　ない事だとは思います。が、あえて提言させて貰うのと、全くそういう物に疎い方も
　いらっしゃるでしょうし、他の方がどういう風に考えられているか見たいというのも
　あります。

　次の課題を出した様なものですが> W.M.さん

　相友優

　既に予定が立っているとかなら、全くの余計なお世話ですね

--

　と、このファイルのアップロードでは文字落ちしていない様です