Browser MCU Plan

Browser_MCU_Plan.md

https://github.com/mganeko/browser_mcu

（ディレクトリ構成は変更予定）

6つのコンポーネントを想定

• MCU core ... 合成だけして、通信は関知しないjsライブラリ
• MCU server ... MCU coreを使った、MCU役ヘッドレスブラウザー。最低限のGUI
• MCU App ... MCU役のElectronアプリ
• MCU docker ... MCU serverをコンテナにしたもの
• Signaling server ... シグナリングサーバー/Webサーバー(node.js)のサンプル実装
• Signaling service ... 簡易サービスとして提供。事前にroom名を予約 → MCU dockerを起動する

検討事項0

どの様な位置付けにするか？

検討結果

複数の位置付け

• MCUライブラリ、サンプル実装
• 簡単に使える、MCUサーバー実装(コンテナ）
• 簡単に使える、シグナリングサービス

候補：

• 部品/ライブラリ
• サンプル/参考実装
• 簡単に動かせるアプリ
• サービス

検討事項1

mcuなのでスケールしない弱点をどうするか？ おそらく参加者20人前後が限界になりそう。

検討結果

• (d) シグナリングサーバーは共通、MCUコンテナは1部屋ごとに利用者で動かしてもらう
  • (c) に近いが、コンテナは動的に制御せずに、利用者側で明示的に用意、起動してもらう

考えられる構成パターン

• (a) 1シグナリングサーバーあたり、1部屋(1ヘッドレスブラウザ)、最大人数20人
• (b) 1シグナリングサーバーあたり、複数部屋(複数ヘッドレスブラウザ)、合計人数20人
• (c) 1シグナリングサーバーから、部屋ごとに別VM/コンテナを動的起動 →それぞれ1ヘッドレスブラウザ、最大人数20人

(a)ぐらい割り切っても良いか？ (c)まで必要か？

検討内容

• スケールする部分と、スケールしない部分を切り離す
  • 具体的には、シグナリング/Webサーバーと、MCUを分離する
• スケールする部分はサービスとして用意し、すぐに使える様にする
• スケールしないMCUを、利用者側で用意してもらう様にする

検討事項2

httpsにするための証明書はどうやって準備、指定してもらうのが良いか？ これの所為で手軽に docker pull & run にならない可能性あり

検討結果

• シグナリング/Webサーバーはこちらで用意する(証明書付き）
• 利用者側ではMCUだけ docker pull & run

検討事項3

認証は必要か？ 必要な場合どうやって実現するか？

検討結果

• アカウント管理はしない
• 部屋を事前登録
  • ルーム名を指定
  • パスワード指定可能(オプション）
  • → トークンが発行される(当面、共通トークン？）
• 部屋の永続化が必要か？ redis?

部屋登録

• (a) シグナリング/Webザーバー 側に登録用ページを用意 --> シグナリングサーバーで期限付き永続化
• (b) MCUサーバーにもWebサーバーを用意 --> ルーム作成ページ、MCU起動、停止の制御。メンバー用エントリーページも用意
• (c) MCUヘッドレスブラウザ起動時に、ルームをシグナリングサーバーに登録、MCU終了時に部屋を閉じる

部屋名がかぶるのを、どう予防するか？

候補

• 認証/アカウントなし
• 部屋を作る際にパスワードを付けられる様にする
• 独自にアカウント管理
• 外部アカウント連携
• 外部に問い合わせる連携口を用意する

検討事項4

画面デザインをどこまで作りこむか？ 利用者がかっこよく修正できる余地を提供するか？

いただいたアドバイス

1. シグナリング/Webは提供する(証明書も合わせて)
2. MCU サーバは自前で立ててもらう(doker)
3. 利用する場合はトークンが必要（当面は、試用トークンで利用可能に）

ポイントは、MCU部分だけを独立させて、利用者側で立ててもらう。それによってスケールさせる役割を利用者側に移す