WebRTC SFU からみた DataChannel の使い所

DataChannel はそもそも P2P で生きるものと思っているので、SFU で使うメリットを感じにくい。そもそもサーバ経由であれば WebSocket でいいのでは … って思うことが多い。

では、WebRTC SFU において DataChannel の使い所はどこか?というのを最近考えてみている。

WebRTC SFU + DataChannel + Native Client + ROS

SFU 経由で音声や映像を利用している場合に、ブラウザから情報を送りたいという場合には有用だと思うが、ブラウザ同士というよりかはエンドに対して何かメッセージをリアルタイムに送りたいというのが必要になるのは ROS を使ったロボットや自動運転の場合だと考えている。

DataChannel は汎用的すぎるため扱いにくい。そのため何かしら独自にやるのであれば ROS と連携するのがスマートだろう。

ROS のデータ層送受信ノードを用意するのが無難だと考えている。需要はあるだろうが、かなり小さい。

WebRTC SFU のシグナリングとしての DataChannel

シグナリングの殆どは WebSocket を利用しているが、 WebSocket は TCP/IP ということもあり不安定な回線には強くない。

ただ WebSocket が切れたら、接続も切断してしまうという方式も多いため、この部分を DataChannel にできないか?と考えている。

最初の offer/answer は HTTP の Req/Res モデルで行い、WebRTC 確立後は DataChannel を利用してしまうという方針だ。

この仕組を実際に採用している WebRC SFU は見当たらないので、面白いチャレンジだと考えている。

サーバ経由であれば WebSocket や MQTT や gRPC でいいのでは?って思う用途

よく言われるのがリアルタイムなホワイトボードを実現するために使いたいと言われるが、それこそ WebSocket でいいだろうという話。

パケロス対策や順序保証を捨ててまで実現したい事がない限り DataChannel を利用するメリットは「新しくコネクションをはらなくていい」だけだ。

そこまでシビア性能を求められるのであればそれこそ P2P で実現したほうが良いとなる。さらにはブラウザを使わないようが良い。

結局、DataChannel は WebRTC SFU から見ると “鶏を割くに焉んぞ牛刀を用いん” にしか思えない。

Written by

Erlang/OTP / 時雨堂 / WebRTC / E2EE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store