TVバンク、P2Pを取り入れた動画配信システムを開発 33
ストーリー by yoosee
マルチキャストとはだいぶ違う気もしますが 部門より
マルチキャストとはだいぶ違う気もしますが 部門より
hylom曰く、"TVバンクは9月26日、「数万人規模のユーザーに対して高画質の動画コンテンツを同時に配信できるシステム」を開発した、と発表した（プレスリリース）。
このシステムは「BBブロードキャスト」と名付けられており、オーバーレイマルチキャストと呼ばれる技術を用いているそうだ。
動画データを分割してサーバーから配信するとともに、クライアント同士が通信してそれぞれがもつ分割された動画データをやり取りすることで、動画配信に必要な帯域幅を削減する技術とのこと。
すでにこの技術を利用した動画配信も行われており、9月22日にYahoo!動画上で同システムによってダンスボーカルユニットEXILEのライブを768kbpsで配信したところ、一般的な動画配信方式の約5分の1の送信トラフィックで、最大同時視聴者数25,302人、総視聴者数46,904人が実現できたそうだ。
TVバンクではこれを「『通信』と『放送』の谷間にあたる、数万から十数万人のユーザーをターゲットとした動画コンテンツの配信に最適」としており、今後もこの方式を利用した動画配信を予定しているとのこと。
クライアント同士が直接動画の「パケット」をやりとりする、というのはまさにBitTorrentやSkypeなどと同様のP2P技術の利用であり、大量のデータを配布には順当な手段だろう。ただ、当然専用のクライアントが必要となるため、ますます非Windowsユーザーは置いていかれる気がしてならないのだが…。"
どこまでホントなの (スコア:3, 興味深い)
その2つのイベントにおけるトラフィックが4Gbps [impress.co.jp]、1Gbps [impress.co.jp]で頭打ちになっていることから、サーバからの送信トラフィックが削減できたのではなく、配信サーバの能力が頭打ちになっている可能性もなくはない。
仮に配信そのものが上手く動いたしても、Winnyがそうだったように、トランジットや各ISPのバックボーンにおけるトラフィック急増を抑えられるとは思えない。
もし本当に抑制できたのであれば、それはそれでP2Pのロジックとしては興味深いものがあるので、どのようなロジックでパートナーを選択しているのか、概略だけでも発表して欲しいものです。
Re:どこまでホントなの (スコア:1)
> そうだったように、トランジットや各ISPのバック
> ボーンにおけるトラフィック急増を抑えられるとは
> 思えない。
Winny は、不特定多数の情報ソースがネットワークに
流れたからトラフィックが増えたのでは?
ある程度のチャンネル数に絞ってデータを流すなら、
この仕組みはかなり利いてくると思いますけど。
--- show mpls ldp neighbor
Re:どこまでホントなの (スコア:0)
あるネットワーク内に収束させやすいとは思うのですが
勝手に収束していくことはないと思うのですがいかがでしょう?
Re:どこまでホントなの (スコア:1)
> あるネットワーク内に収束させやすいとは思うのです
ということで、私が書いたことに関しては
agree されているとは思うのですが、
> 勝手に収束していくことはないと
> 思うのですがいかがでしょう?
すいません、私は「勝手に収束」するとかしないとか
についてははどこにも書いてないんですが、これは
何の話なんでしょうか?
--- show mpls ldp neighbor
GPLのフリーなクライアントを作ろう。 (スコア:2, 興味深い)
なら、彼らが使いたくなるようなシステムを先に作ればよいのだ。
GPLのフリーなものなら、標準でクライアントが無くても、使いたい機種に移植するのも簡単になるのではないだろうか。
#判っていると思うけど...
Re:GPLのフリーなクライアントを作ろう。 (スコア:0)
コピーされたくないコンテンツもコピーされやすくなるのでは？
Re:GPLのフリーなクライアントを作ろう。 (スコア:1)
関連ないですよ。
SSLとか、信頼して使いますよね。
安全性も検証されてることになります。
※パーフェクトってないんですがね。
Re:GPLのフリーなクライアントを作ろう。 (スコア:3, 参考になる)
そもそもSSLとDRMは別のものですよ。
SSLはホスト同士で安全に通信を行なうためのプロトコルで、少なくともユーザが操作するクライアントはユーザが信頼している前提があります。
対してDRMはユーザが全ての権限を掌握しているはずのクライアント、およびユーザを信頼しないモデルになっていますが、そもそもの目的である映像再生を実現するためには何らかの形でユーザの手元で暗号解除を行なわなければならない、という相反する要求を同時に満たす必要があります。
そのためDRMではソースコードを隠蔽して予期しない暗号解除を防衛する仕組みが備わっているのが通常です。そういう意味で「オープンソースだと危険」という発想が存在していて、それが信じられているのも不思議ではないですよね。
Re:GPLのフリーなクライアントを作ろう。 (スコア:1)
実は、V3への嫌味をちょっと混ぜています。
Re:GPLのフリーなクライアントを作ろう。 (スコア:0)
思うんだけど、どちらにせよ、ソースが公開されて
いる時点で、「画面に表示できるけどディスクに保存は
できない」といった制御は困難ですよね。
Re:GPLのフリーなクライアントを作ろう。 (スコア:0)
Re:GPLのフリーなクライアントを作ろう。 (スコア:1)
それ以外でもTVバンクがほしがるものなら何でも良いのだが。
バックボーンは１つ (スコア: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
peercast? (スコア:0)
Re:peercast? (スコア:0)
こういうのは先に大手で商品化して普及させた方が勝ちです。
Re:peercast? (スコア:4, 参考になる)
記事だけでは詳細はわからないんですが，配信ノードとリレーノードが平等でオーバーレイネットワークトポロジが木構造限定のPeerCastとはまた別の物だと思います．
というのはPeerCastだと↑の特徴のせいで悪意のあるリレーノード（放送中良いところでリレーを切る）がいるとネットワークがかんたんに崩壊するので，ただ改良しただけでは商用に乗せるのは難しいんではないかと･･･．
#個人的にはYahoo動画やYouTubeよりもスター配信者や配信者信者が出てくるようなPeerCast文化の方が好きです
P2P (スコア:0)
Re:P2P (スコア:1)
クライアントには、ダウンロード担当の「レシーバ」と
プレイヤーの「コンテンツナビゲーター」だけが必要。
これの場合は、クライアントがP2Pしているわけで。
オーバーレイマルチキャストとも言うのか (スコア:0)
Application Layer Multicast [google.com]
Application Level Multicast [google.com]
Overlay Multicast [google.com]
用語を統一してくれないだろうか。
Re:オーバーレイマルチキャストとも言うのか (スコア:0)
「P2P」という言葉は出す必要を感じない。