カテゴリー別アーカイブ: Unity

StreamingMeshのネットワーク周りについて(UDP通信の課題)

Unity Advent Calender 2016の11日目の記事となります．
10日は@lycoris102さんの「[Unity] GO Mapの世界におもむろに雨とか雪とか降らす」でした．
地形データの生成は非常に魅力的で，私はまだスマホ向けのUnity開発に手を出したことが無いので，凄く勉強になりました．

StreamingMeshというアセットを作っています

現在StreamingMeshを現在公開しております．このソフトはUnityのEditor上で動作させている3Dのモデルデータをストリーム化して，受信側に直接表示する仕組みになっていますが，インターネットを経由して快適に使用するにはいろいろと課題が残っています．ネットワーク周りがボトルネックになっており，その話をしたいと思います．

WebRTC(P2P)での通信について

WebRTC

StreamingMeshの現行バージョンではWebRTC Networkを使用しています．WebRTC data channelsを使い，サーバーレスのP2P経由でメッシュやマテリアル，テクスチャをバイナリデータとして受信側に送るようにしています．が，テストをしてもらった際に，「うまくストリーミングしない」と報告をくださった方がいました．

(他，報告割愛)

これ以外にも報告を頂いたのですが，まったく表示ができない人がいたようなので，原因を調べてみました．
通信の具合を調べるためにNetLimiterというソフトを導入しました．このソフトではアプリケーション内部で動いてるプロセス単位でネットワークの状態を監視できるうえ，さらに通信帯域を絞った際にどのような挙動になるかを再現できるソフトです．このソフトで検証してみました．
NetLimiter 4

UnityChanのモデルを使った際，大体250~400KB/s(2Mbps~)ぐらいの通信速度が必要になりますが，これを100KB/s以下まで絞った場合，報告のあった通りになりました．

ISPの規制問題

うまく動かなかった人の環境では固定のブロードバンド回線で，スループット自体には問題が無いということを聞きました．

怪しいと思ったのがUDP周りの挙動です．

WebRTCはUDPホールパンチングという技術を使っており，SkypeのようにUDPポートのうち，通信利用できるUDPのポートを探します．上のNetLimiterのスクリーンショットでは送信側は55893，受信側は55899のUDPポートを利用しています．送信受信とも同じローカル環境なので素直に受信できていますが，ISPを介すとうまくいかないのではないかと考えています．

ISP規制情報から，プロバイダのうちP2P規制(UDPの通信規制)を行っている所がかなり存在し，表示すらできない状態というのは，ちょうどこのP2P規制に引っかかってUDPの通信帯域が極端に絞られるか，強制切断されているのではないかと考えています．

単純にUDPを使用するだけで帯域を絞るというプロバイダもあるため，これだと合法非合法関係なしに通信がうまくいきません．
結果的にP2PタイプのWebRTCを使ったストリーミングはかなり実用性から離れてしまうということになり，現在はUDPからTCPのうち，HTTPから通信する方法を模索しています．

今後の方針について

WebRTCを使った理由はサーバーレスでお手軽だと考えていましたが，実際にインターネットを利用するには高速な通信処理ができるサーバーが必要になり，またローカル間での通信であってもUnity上で簡易Webサーバーが作れることが分かったため，ホスト側でサーバーを立てるか，ネットワーク上に通信が高速なHTTPサーバを立てて規制に引っかからないようにStreaminMeshを組みなおしています．
HTTP上でストリーミング処理が可能なHLSベースの仕組みを現在考えています．この方法だったら仕組みが単純になり，さらに高速なHTTPサーバーさえ用意できればISPの性能差を埋められるのではないかと考えています．

明日のUnity Advent Calender 2016は @RyotaMurohoshiさんです．