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 から見ると “鶏を割くに焉んぞ牛刀を用いん” にしか思えない。
