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

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ユーザーは置いていかれる気がしてならないのだが…。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2006年09月27日 8時19分 (#1027287)
    impressの記事 [impress.co.jp]を読んだだけなので詳細はわからないのですが、この方式だと、参加者が増えれてくるとある程度は再生支援サーバからの補完データの送信も増える時間帯があると思われるのですが、記事中の2つのグラフにその傾向が見えないこと。
    その2つのイベントにおけるトラフィックが4Gbps [impress.co.jp]、1Gbps [impress.co.jp]で頭打ちになっていることから、サーバからの送信トラフィックが削減できたのではなく、配信サーバの能力が頭打ちになっている可能性もなくはない。

    仮に配信そのものが上手く動いたしても、Winnyがそうだったように、トランジットや各ISPのバックボーンにおけるトラフィック急増を抑えられるとは思えない。
    もし本当に抑制できたのであれば、それはそれでP2Pのロジックとしては興味深いものがあるので、どのようなロジックでパートナーを選択しているのか、概略だけでも発表して欲しいものです。

    • by mpls (8235) on 2006年09月27日 8時53分 (#1027298) 日記
      > 仮に配信そのものが上手く動いたしても、Winnyが
      > そうだったように、トランジットや各ISPのバック
      > ボーンにおけるトラフィック急増を抑えられるとは
      > 思えない。

      Winny は、不特定多数の情報ソースがネットワークに
      流れたからトラフィックが増えたのでは?

      ある程度のチャンネル数に絞ってデータを流すなら、
      この仕組みはかなり利いてくると思いますけど。
      --
      --- show mpls ldp neighbor
      親コメント
      • 情報ソースが少なければ、トラフィックを
        あるネットワーク内に収束させやすいとは思うのですが
        勝手に収束していくことはないと思うのですがいかがでしょう?
        • by mpls (8235) on 2006年09月27日 12時52分 (#1027488) 日記
          > 情報ソースが少なければ、トラフィックを
          > あるネットワーク内に収束させやすいとは思うのです

          ということで、私が書いたことに関しては
          agree されているとは思うのですが、

          > 勝手に収束していくことはないと
          > 思うのですがいかがでしょう?

          すいません、私は「勝手に収束」するとかしないとか
          についてははどこにも書いてないんですが、これは
          何の話なんでしょうか?

          --
          --- show mpls ldp neighbor
          親コメント
  • 企業は自身の利益を優先するから、彼らが作ったシステムではWindowsが優先されるのだ。

    なら、彼らが使いたくなるようなシステムを先に作ればよいのだ。
    GPLのフリーなものなら、標準でクライアントが無くても、使いたい機種に移植するのも簡単になるのではないだろうか。

    #判っていると思うけど...
  • by Anonymous Coward on 2006年09月27日 0時18分 (#1027204)
    バックボーンは1つなので P2Pを行なえばかえってトラフィックが増えたりしないのかな?
    • Re:バックボーンは1つ (スコア:2, すばらしい洞察)

      by MASA.H (30014) <masahaseNO@SPAMgmail.com> on 2006年09月27日 2時31分 (#1027253) ホームページ
      サーバーにトラフィックが集中してサーバーが落ちるのを防げればいいって考えなんじゃ。
      あとサーバー側の帯域を狭くできるとか。

      全体のトラフィックは確実に増えるよね。
      親コメント
      • by Anonymous Coward on 2006年09月27日 3時08分 (#1027262)
        >全体のトラフィックは確実に増えるよね。

        条件次第でしょ。

        まったく同時に複数のクライアントが要求すれば、全部1次サーバからダウンロードする訳で、P2Pの利点は無し。=今までと同じトラフィック。

        何らかの方法でマルチパスルーティングみたいな事が行われる条件で、理想的なピラミッド構造が構築されればマルチキャストのような振る舞いもするでしょ。
        まー無理だと思うけど。

        とネタを振って識者の登場を待つw
        親コメント
        • by Anonymous Coward on 2006年09月27日 11時46分 (#1027409)
          >条件次第でしょ。

          と書いた限定条件だけが今までと同じトラフィックで、あとはどうあれ確実に増えるんだから、
          「全体のトラフィックは確実に増える」で正しいでしょ。
          親コメント
          • 「全体のトラフィック」の定義次第なんでしょうけど、それが単に「TCP/IP コネクションによるpeer間のデータ通信量の合計」だったら
            確かに「基本的なデータ通信量に変わらないが、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ネットワーク構築の際に「ネットワーク的距離」を無視しているのが
            バックボーンのトラフィックを増大させている最大の悪。
            親コメント
      • 帯域は食いますが、マルチキャストがどこでも使えるようになるまでのつなぎにはいいと思います。ルーターをマルチキャスト対応のものにするなどの整備が不要なので。

        --
        IPv6と共にいつになるのやら・・・マルチキャスト
    • by ikebass (8108) on 2006年09月27日 0時52分 (#1027221)
      トラフィックの集中を防ぐ、ということかと。

      クライアントが10万いれば、単純計算で元データサイズの10万倍の通信が発生するのは、中央集中型でもP2Pでも同じです。
      トラフィックがサーバに集中するか、網内で分散するか、の違いです。

      #間違ってるかな?
      親コメント
      • by shoji12 (14093) on 2006年09月27日 9時13分 (#1027305)
        さらに、各クライアントに他のクライアントの情報をサーバーから送る分のトラフィックが増える。
        10万人の人が互いに異なる10万種類の番組を見たら、きっとサーバーはダウンするだろうな。
        親コメント
      • 間違ってる。そんな単純じゃない。

        クライアントから別のクライアントへとなるから、
        同じ経路を往復することになることもあるし、
        何度も行ったり来たりすることにもなることもある。
        • by ikebass (8108) on 2006年09月27日 1時24分 (#1027239)
          > クライアントから別のクライアントへとなるから、
          > 同じ経路を往復することになることもあるし、
          > 何度も行ったり来たりすることにもなることもある。

          なるほど。
          その点は単純計算ということで無視しました。
          だって、途中がどうあれ、最終的には各クライアントがそれぞれ元データと同じサイズのデータを受信するんだから...という発想です。
          seedを探すトラフィックなんかも無視してます。

          # 無視できるくらいのボリュームかどうかは知りません。ので、私のした見積もりが乱暴なのは確かです。

          実際のところトータルの通信量はどのくらい増えるんでしょう?
          親コメント
        • by mpls (8235) on 2006年09月27日 2時20分 (#1027249) 日記
          私なら(あくまでも私がこのシステムを組む立場なら)、このクライアントを専用ハードにして、ネットワークのそこそこ大きな枝の根元に置くなぁ。

          そうすれば、実際にはそこから配信されるだけで、その先ではいったりきたりがおきたりしないようになると思う。
          コンテンツデリバリーってのを普通の頭で考えたら、そういう仕組みになってしまうと思うんだけど。

          どっかの会社がそんなの開発してたよね。

          もっと斜め上の発想でやってくれてたりするんだろうか。
          --
          --- show mpls ldp neighbor
          親コメント
        • by mpls (8235) on 2006年09月27日 2時29分 (#1027251) 日記
          > クライアントから別のクライアントへとなるから、
          > 同じ経路を往復することになることもあるし、
          > 何度も行ったり来たりすることにもなることもある。

          この辺って、クライアント同士で traceroute 的なものをやって、
          その情報をもって shortest path 作るような仕組みを作ってん
          じゃないのかなぁ。

          もし、私が作るなら、新規に参加したノードと、そのノードが
          join した親ノードまでの traceroute 情報や、遅延情報を
          オーバレイマルチキャストとかいうネットワークのコントロール用
          ネットワークに流すようにして、 最適な親ノードを再度選ぶように
          作るな。

          プログラム組めないから作れないけど orz
          --
          --- show mpls ldp neighbor
          親コメント
  • by Anonymous Coward on 2006年09月27日 0時19分 (#1027205)
    再発明に見えなくもない
    • by Anonymous Coward
      Peercastを元に改良と言うことでしょう。
      こういうのは先に大手で商品化して普及させた方が勝ちです。
      • Re:peercast? (スコア:4, 参考になる)

        by yoc (19731) on 2006年09月27日 3時41分 (#1027264)

        記事だけでは詳細はわからないんですが,配信ノードとリレーノードが平等でオーバーレイネットワークトポロジが木構造限定のPeerCastとはまた別の物だと思います.

        というのはPeerCastだと↑の特徴のせいで悪意のあるリレーノード(放送中良いところでリレーを切る)がいるとネットワークがかんたんに崩壊するので,ただ改良しただけでは商用に乗せるのは難しいんではないかと・・・.

        #個人的にはYahoo動画やYouTubeよりもスター配信者や配信者信者が出てくるようなPeerCast文化の方が好きです

        親コメント
  • by Anonymous Coward on 2006年09月27日 0時36分 (#1027213)
    クライアント同士が直接動画の「パケット」をやりとりする、というのはまさにBitTorrentやSkypeなどと同様のP2P技術の利用であり、
    SkeedCast がそうでないのと異なるのですね。
    • by Elbereth (17793) on 2006年09月27日 3時05分 (#1027261)
      SkeedCastはサーバー側でP2P通信をしている。
      クライアントには、ダウンロード担当の「レシーバ」と
      プレイヤーの「コンテンツナビゲーター」だけが必要。

      これの場合は、クライアントがP2Pしているわけで。
      親コメント
  • by Anonymous Coward on 2006年09月27日 12時06分 (#1027435)
    P2Pオーバーレイネットワークを使ったマルチキャストですね。
    Application Layer Multicast [google.com]
    Application Level Multicast [google.com]
    Overlay Multicast [google.com]
    用語を統一してくれないだろうか。
typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...