WebSocket、Socket.IO、MQTT をシミュレートする

WebSocket のリクエスト型からは、 選んだプロトコルに応じて 3 種類のサーバーを利用できます。

フォルダーを右クリック ▸ 追加 ▸ WebSocket サーバー / Socket.IO サーバー / MQTT サーバー。

WebSocket サーバー

localhost:<ポート> で着信接続を受け付け、 接続中のクライアントへフレームを送信できます。

Socket.IO サーバー

同じですが、Socket.IO のセマンティクスに従います。 メッセージは 名前付きイベント になります。

MQTT ブローカー

3 つのうちでもっとも興味深いものです。 Restorm は 本物のローカル MQTT ブローカー をホストします。

• ポートごとに 1 つのブローカー。
• 生の TCP と MQTT over WebSocket のゲートウェイ の両方でアクセスできます。 そのため、ブラウザー上のクライアントから直接接続できます。
• パブリッシュとサブスクライブは QoS や保持を含めて通常どおり動作します。

これにより、Mosquitto をインストールしたり共有ブローカーに依存したりせずに、 IoT の一連の流れを丸ごと開発・テストできます。

ポートの共有

これらのサーバーは、同じポートの HTTP サーバー とソケットを共有します。 Restorm は通常のリクエストを HTTP のルートへ、 アップグレード要求（upgrade）をリアルタイム系のサーバーへ振り分けます。

つまり、シミュレーション用の HTTP サーバーと Socket.IO サーバーが 同じ :8080 で一緒に待ち受けられます。 これは実際の Web アプリケーションの構成とまったく同じであることも多いのです。

シナリオの中で

WebSocket サーバーを閉じる と Socket.IO サーバーを閉じる のアクションは、 サーバーモードの接続アクションが開いたサーバーを閉じます。 ホストされるサーバー を参照してください。