Wataのルームについて

Wataでは、クライアントが配信や受信するためにはルームを作る必要があります。

ルーム内にWataクライアントが入っていれば、配信側のWataクライアントが配信したオーディオやデータを、受信側の全Wataクライアントが受信できるようになります。

ルームはクライアントが作るのではなく、Wataを使ったサービスの提供者が事前に作っておくものになると思います。そのためこのAPIにはクライアントから直接呼べないように何らかの認証を付けることになるでしょう（未実装）。

WataサーバはgRPCだけでなくHTTPサーバとしても機能している（※）ので、WataサーバにHTTP APIのリクエストを投げることでルームを作成できます。

※ Boost.Beast を使っています。

こんな感じです。

$ curl -X POST \
>  -H 'Content-Type: application/json' \
>  -d '{"name": "room", "expires_in": 3600}' \
>  http://localhost:8888/api/room/create
{"room_id":8306256155981411136}

これで誰も入っていないルームができます。

ここに、誰が入る予定なのかという情報を、クライアントを追加するAPIで追加していって、クライアント側がその時に貰ったセッションIDで入室して、配信したり受信したりすることになります。

$ curl -X POST \
>   -H 'Content-Type: application/json' \
>   -d '{"room_id": 8306256155981411136, "players": [{"player_id": "Player1", "sendable": true}, {"player_id": "Player2", "sendable": false}]}' \
>   http://localhost:8888/api/room/add_players
{
  "name":"room",
  "players":[
    {"player_id":"Player1","session_id":94167185320571792},
    {"player_id":"Player2","session_id":6127863560785855}
  ]
}

この例だと２人のクライアントは「セッションID: 94167185320571792」と 「セッションID: 6127863560785855」で入室することになります。

デバッグ機能

これが一般的なルーム作成となりますが、開発中やデバッグ中は、わざわざHTTP APIを叩いてから入室するのが面倒です。

そのためデバッグ用の機能として、Wataサーバには暗黙にルームを作る機能があります。

var publisher = new WataClient("localhost", 50051, -1);
var subscriber1 = new WataClient("localhost", 50051, -2);
var subscriber2 = new WataClient("localhost", 50051, -3);

コードは雰囲気です。重要なのは WataClient コンストラクタの三番目の値で、ここには本来セッションIDが入ります。

ここに-1, -2, -3を指定すると、自動的に「ルームID: -1」のルームを作って、そのルームの中にこれらのクライアントを追加します。

「セッションID: -1」から「セッションID: -65536」までは、全て「ルームID: -1」のルームを作って、そのルームに入室します。

「セッションID: -65537」から「セッションID: -131072」までは、全て「ルームID: -2」のルームを作って、そのルームに入室します。

ただし、既に入室しているセッションIDで、もう一度入室しようとした場合、そのルームは一度壊されてから再度作り直します。こうすることで、例えばデバッグ実行をし直した時に繋いでいたクライアントが全て切断されるため、ちゃんと新しい状態からやり直すことができるようになりました。

このような機能を入れることで、クライアントだけで入室して配信や受信ができるようになります。