パスワードを忘れた? アカウント作成
129963 journal

shado2001の日記: ゆらゆら」したら即カキコは、{回線}交換方式の帯域を浪費する? 4

日記 by shado2001

地震のようです。少し長い、関東から震源は遠いのかな

594kHzは特別番組に切り替わっている。

ところで、
題名にも書いたが「地震が起きると通信が増えて被災地等への電話が
掛かりにくくなる。」現象は知られています。
IP化が著しい今日でも同様な事は想定されるので
命題「ゆらゆら」したら即カキコは、帯域を消費する
 は正とした場合
「ゆらゆら」してもすぐにはカキコせず、帯域を空けるべき
と言えるのだろうか?

{動画や音声のリアルタイム伝送じゃないから}とかの条件は
あるんだろうけど

この議論は、shado2001 (6090)によって テキ禁止として作成されたが、今となっては 新たにコメントを付けることはできません。
  • by okky (2487) on 2009年08月09日 23時57分 (#1619905) ホームページ 日記

    昔、淡路大震災が起こったとき。

    丁度、四国から神戸、大阪の辺りから何も情報が来なかったのを覚えています。
    「あーなんか、あの辺りがやばそう」
    というのが判ったものです。

    「ゆらゆら」とした場合に「即書き込み」をする事で、『この辺りは大丈夫ですぅ』という事を世の中に知らしめる効果があります。普段そういう書き込みがある地域から何も書き込まれなかったときが、すわ、一大事 な時。

    そう考えると、帯域を潰してでも即書き込みはするべきでしょう。

    .

    むしろ厄介なのは、今の日本のインターネットは非常に数の少ないバックボーンに支えられている、と言う点です。バックボーンがブッツリ切れてしまうと、他のパスへの負荷が一気に増大してしまい、緊急通信を優先するために次々と通信が落ちる。結果としてどこが 一大事なのか が判らない。どこかがやばいのは判るのに。

    本来、IPというのは、拠点が数箇所潰されても大丈夫なように、というデザインで作られているはずなのに、バックボーンがブツッと切られただけで通信が連鎖反応的に落ちてしまうのは、冗長性が全然足りていない 証拠です。

    普段から、契約している流量の最大値の5倍以上を流せるだけの回線を平常時には確保し、工事や緊急時などに際しても2倍以上が流せるような迂回路が存在するようにネットワークをデザインすること ぐらいの容量規制(減らすんじゃなく増やす方向で)は欲しいものです。そのためにも、 Winny とかは規制するんじゃなく、むしろ 緊急時には優先度を下げてよいが、普段は xxTbps 以上常に流れるようにすること ぐらいの勢いで回線確保と、健全性確認のために使いたいものです… (^w^)。

    --
    fjの教祖様
    • 例えば、首都圏のような人口密集地で、
      想定以上の大勢の人々が同時に書き込もうとして、
      輻輳が発生したら、面倒じゃないでしょうか。

      p2pなどで、回線のキャパが常時確保されていたとしても、
      物理的な発呼要求の殺到を捌ききれるかどうかは、
      担保できませんよね?

      // あれ? 携帯でも何でも、常時接続をデフォにすれば
      // 発呼要求の殺到は避けられる?

      // 地方では「無事なら無事で、ちゃんカキコしやがれ」
      // みたいに言われたりして。

      • 想定以上の大勢の人々が同時に書き込もうとして、
        輻輳が発生したら、面倒じゃないでしょうか。

        キーポイントはまさにここだと思います。

        想定以上の

        えぇ、問題はそこでしてね。 なんで想定を上回るんだ と。

        .

        まず、ネットワーク側から。shado2001さんがメインに注目しているのはこちらのようなので。

        想定を上回るって事は、普段は使っていない人が使う って事ですよね?
        たとえば在宅勤務とかそういうので、会社との Secure Session を張っていると結構な通信量が発生するんですが、そういうことを想定していないってことですよね?
        # つーか NTT 自体、そういう勤務体系を 例外的な処置 としてすら考えていない。

        もし、こういうのを考えていたなら、災害が起こったときは仕事どころじゃありませんから、仕事のための通信は激減するはずです。で、その分この手の書き込みの通信が増える。増減で考えると「減る」はずなんです。

        ネットワークに関する限り、 想定が間違っている だけだと思うんですよ。

        .

        で、書き込みサーバの所で輻輳が起こっている場合。

        んー、クラウドコンピューティングにどれぐらい追従したシステムを作るか、依存ですよね、実は。 /. は文字しか使えないので、比較的負荷が軽い。MySQL で実装されている部分の分散化と、Perl スクリプト部分の高速化をどうするか…という点が難問ですが。

        逆に今の /.J ってサーバは一極集中なんでしょうかね。つまりデータセンターが物理的に一箇所にあって、そこが天災で大崩壊を起こすと全くサービスが止まるのか? という問題。もし止まるなら…輻輳どころじゃない。止まらないなら、分散化されているのでしょうから、簡単には輻輳も起こさないはずです。ロードバランサーは泣きを見るでしょうが。

        .

        少なくとも今の日本の多くのシステムは、いまだにエンドノード能力よりもネットワーク能力のほうに問題があります。エンドノードに存在するサーバの能力に比べてネットワークが弱すぎる。2ch ですら「エンドノードに到達できなくて」サービスがダウンすることはあっても、ネットワーク的には無事なのにサーバがオーバーロードしてダウンした、と言う話は聞かない。ストレージが限界まで行って、データを失ったとか、そういう話はない。

        これはある意味正しい設計ですが、ちょっとバランスが悪いんじゃないかと。サーバをもっと弱くしろと言う意味じゃなくて、ネットワークをもっと強化するべきじゃないか。それもすぐバックボーンボトルネック & バックボーン信頼性問題に落ちてしまうような「ネットワークと言いつつ実はスターハブ」じゃなく、もっと としての性質を持たせるべきなんじゃないか、という気はします。

        --
        fjの教祖様
typodupeerror

あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall

読み込み中...