HTML5Experts.jp

WebRTC DataChannelの活用方法とその可能性─WebRTC Conference Japan

本記事では、WebRTC Conference Japanのセッションの1つである、「WebRTC DataChannelの活用方法とその可能性」について紹介する。講演者は、Mist Technologies株式会社CEO・田中晋太朗氏だ。

Mist Technologies株式会社  田中晋太朗氏

セッション内容は、大きく以下の2点である。

以下でそれぞれの内容について紹介する。(発表資料全体はこちらから

WebRTC DataChannelのおさらい

概要

DataChannelは、サーバを介さずにテキストやバイナリデータを送ることができる。特にバイナリデータが重要で、ArrayBuffer、ArrayBufferView、Blob、Stringを送信可能だ。

DataChannel概要

注意点として、CreateOfferでSDPを作成する前に、createDataChannelしておく必要がある。なぜなら、相手との通信に必要なSDPが作成できないためだ。

プロトコルスタック

DataChannelを支えるプロトコルとしてSCTPがある。SCTPは、簡単に言ってしまえば、TCPとUDPの良いとこどりのプロトコルで、createDataChannelの引数にオプションを設定することにより、動作を変更できる。

ひねりのある使い方

事例1:DHT webrtc-chord

P2P技術が好きな方はご存知かもしれないが、DHT(分散ハッシュテーブル)のアルゴリズムの1つであるchordのWebRTC実装が、webrtc-chordだ。chordは、分散型のKVSに似ており、様々なノードが、バランスよくデータを保持できる。

webrtc-chord

DataChannelはこの中で、データの挿入・検索を実現するために利用されている。特に面白いのは、コントロールプレーン(実際のデータではなく、それを制御する通信のこと)をWebRTCのデータチャネルに担わせている点だ。

WebRTC Chordを利用すると、サーバでデータを持つ必要がなくなり、Pure P2Pに近づく。

事例2:ファイル共有 WebDrop

Mist Technologies社で、ウォーミングアップとして作ったサービスだ。ファイル共有をする際に、クラウドストレージにアップロードしたくないが、メール添付の容量を越えてしまう場合に、役立つ。

WebDrop

実装としては、JavaScriptからFileAPIを利用し、データを送る際に必要なメタ情報を、BinaryPackでArrayBufferへシリアライズして送っている。

Sharefestや、ShareDropが類似サービスだ。

データ送受信の注意点

ブラウザによって実装の違いが大きい点に注意する必要がある。例えば、ChromeやOperaでデータを送る場合は、バイナリの長さに制限がある。制限の長さを越えてしまうと、DataChannelがクローズされてしまう。

データ送受信の注意点1

一方でFirefoxは良く出来ていて、どれだけの長さを送信しても、不都合は生じない。ただし、受信時のonmessageでのバイナリの扱いが特徴的で、Firefoxではblobで取り出せるようになっている。そのため、他のブラウザと処理を合わせるためには、Blobで出てきた場合は、ArrayBufferで処理するように実装する。

Chrome等でバイナリの長さ上限を回避するには、2つの方法がある。

データ送受信の注意点2

データを輪切りにして送信する場合は、送信側はデータをキューにためておいて、よいタイミングでsendを呼び出して送信する。受信側は、分割して送信されてくるので、Chunkを組み立てる必要がある。

事例3: MistCDN

もう1つの応用としてMistCDNを紹介する。

MistCDN1

MistCDN2

MistCDNはP2P型のCDNで、同じサイトを閲覧している近いユーザから、DataChannelでデータを受信する仕組みだ。フロントエンドの実装はTypeScriptを利用している。

どういう利点があるかというと、CDNを使った場合に、ユーザレスポンスの向上が挙げられる。また、CDN自体の利用量(コスト削減)も実現できる。

類似のサービスも色々あるが、動画の配信という点では、MistCDNに優位性がある。

P2P型CDNの要所

既存のCDNは、HTTPの仕様に沿って実現されており、オーバヘッドが少ない。P2P型のCDNを実現しようとすると、シグナリングが必要になり、オーバヘッドが生じる。オーバヘッドが大きい場合は、結局遅くなることもある。

P2Pの要所

そこで、シグナリングのメッセージを減らす、また、小さいコンテンツはまとめて送る、等の工夫が必要になる。

また、データを受信するPeerを選択する場合には、遠いPeerを選ばないように、帯域を利用する等の工夫をしている。(詳細は企業秘密)
ただし、クライアントサイドのコードは、誰でも読めてしまうので、将来的にオープンソース化も視野にいれている。

対応ブラウザの問題もつきまとうので、iOS向けにネイティブライブラリも開発している。

活用方法とその可能性(Discussion)

DHTのWebRTC実装等の事例を紹介してきたが、いくつかを組み合わせると、サーバの仕事を極力減らして、1つのシステムを組めるようになるのでは、と考えている。

今後登場しそうなWebRTC応用

シグナリングはどうしても必要になるが、SkyWay等のPaaSを使えばサーバを持たなくてよい。また、データについてもChordの上に載せてしまえば、これもサーバが不要だ。

Ustreamはメディアをサーバにアップロードして、各ユーザがダウンロードする仕組みになっているが、これをブラウザで実現できないか。まだ現実的にできるかは、わからないが。

最後に、ブラウザをエージェントとして利用すれば、グリッドコンピューティングも実現できるのではないか、と考えている。