アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
バックボーンは１つ (スコア:0)
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