アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
バックボーンは１つ (スコア: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ネットワーク構築の際に「ネットワーク的距離」を無視しているのが
バックボーンのトラフィックを増大させている最大の悪。
Re:バックボーンは１つ (スコア:0)
--
IPv6と共にいつになるのやら・・・マルチキャスト
Re:バックボーンは１つ (スコア:1)
クライアントが10万いれば、単純計算で元データサイズの10万倍の通信が発生するのは、中央集中型でもP2Pでも同じです。
トラフィックがサーバに集中するか、網内で分散するか、の違いです。
#間違ってるかな?
Re:バックボーンは１つ (スコア:1)
１０万人の人が互いに異なる１０万種類の番組を見たら、きっとサーバーはダウンするだろうな。
Re:バックボーンは１つ (スコア:1)
統計多重効果が狙えるものをここに流すという
ことなんでは？
--- show mpls ldp neighbor
Re:バックボーンは１つ (スコア:0)
クライアントから別のクライアントへとなるから、
同じ経路を往復することになることもあるし、
何度も行ったり来たりすることにもなることもある。
Re:バックボーンは１つ (スコア:1)
> 同じ経路を往復することになることもあるし、
> 何度も行ったり来たりすることにもなることもある。
なるほど。
その点は単純計算ということで無視しました。
だって、途中がどうあれ、最終的には各クライアントがそれぞれ元データと同じサイズのデータを受信するんだから...という発想です。
seedを探すトラフィックなんかも無視してます。
# 無視できるくらいのボリュームかどうかは知りません。ので、私のした見積もりが乱暴なのは確かです。
実際のところトータルの通信量はどのくらい増えるんでしょう?
Re:バックボーンは１つ (スコア:1)
そうすれば、実際にはそこから配信されるだけで、その先ではいったりきたりがおきたりしないようになると思う。
コンテンツデリバリーってのを普通の頭で考えたら、そういう仕組みになってしまうと思うんだけど。
どっかの会社がそんなの開発してたよね。
もっと斜め上の発想でやってくれてたりするんだろうか。
--- show mpls ldp neighbor
Re:バックボーンは１つ (スコア:1)
SkeedCast [google.co.jp]?
Re:バックボーンは１つ (スコア:1)
> 同じ経路を往復することになることもあるし、
> 何度も行ったり来たりすることにもなることもある。
この辺って、クライアント同士で traceroute 的なものをやって、
その情報をもって shortest path 作るような仕組みを作ってん
じゃないのかなぁ。
もし、私が作るなら、新規に参加したノードと、そのノードが
join した親ノードまでの traceroute 情報や、遅延情報を
オーバレイマルチキャストとかいうネットワークのコントロール用
ネットワークに流すようにして、 最適な親ノードを再度選ぶように
作るな。
プログラム組めないから作れないけど orz
--- show mpls ldp neighbor