アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
バックボーンは１つ (スコア:0)
Re:バックボーンは１つ (スコア:2, すばらしい洞察)
あとサーバー側の帯域を狭くできるとか。
全体のトラフィックは確実に増えるよね。
Re:バックボーンは１つ (スコア:1, 興味深い)
条件次第でしょ。
まったく同時に複数のクライアントが要求すれば、全部１次サーバからダウンロードする訳で、P2Pの利点は無し。＝今までと同じトラフィック。
何らかの方法でマルチパスルーティングみたいな事が行われる条件で、理想的なピラミッド構造が構築されればマルチキャストのような振る舞いもするでしょ。
まー無理だと思うけど。
とネタを振って識者の登場を待つｗ
Re:バックボーンは１つ (スコア:1, 興味深い)
と書いた限定条件だけが今までと同じトラフィックで、あとはどうあれ確実に増えるんだから、
「全体のトラフィックは確実に増える」で正しいでしょ。
Re:バックボーンは１つ (スコア:1)
確かに「基本的なデータ通信量に変わらないが、P2Pネットワークを構築するプロトコルによる通信量だけ増える」ことになりますが、
その数値自体には意味がないと思います。
端末A─(経路a)─┐
端末B─(経路b)─中継ノード1─(経路d)─中継ノード2─(経路f)─サーバ
端末C─(経路c)─中継ノード2─(経路e)─┘
というネットワークで、サーバから端末A～Cに配信する場合、発生するトラフィックは
(P2Pネットワークのための通信量を無視すると)
普通のユニキャストの場合:
経路a:1本、経路b:1本、経路c:1本、経路d:2本、経路e:1本、経路f:3本
P2Pによるマルチキャストもどき(端末Aが中継)
経路a:3本、経路b:1本、経路c:1本、経路d:2本、経路e:1本、経路f:1本
本物のマルチキャスト
経路a:1本、経路b:1本、経路c:1本、経路d:1本、経路e:1本、経路f:1本
となります。
このとき「全体のトラフィック」が「3本」から「3本+α」に増えると言ったところで、トラフィック評価に何の意味もないですね。
重要なのは、個々の経路でトラフィックがどう変化するか。
端末側(経路a～c)ではP2Pによってトラフィックが増えますが、サーバ側(経路f)ではまず確実に減ります。
P2Pネットワークを上手く構築すれば、バックボーン(経路d～e)でも減る可能性が高いでしょう。
あとは、どこがボトルネックになっているかの評価ですね。
普通は、クライアント側のトラフィックには余裕がある場合が多いですから、
バックボーンやサーバ側のトラフィックを減らすようにするのがメリットが大きいと思います。
WinnyはP2Pネットワーク構築の際に「ネットワーク的距離」を無視しているのが
バックボーンのトラフィックを増大させている最大の悪。