従来の Web サーバーで実行されている Web アプリケーションをデプロイする場合、通常はコードの更新後に Web サーバーを再起動します。HTTP の性質上、これはユーザーにとって問題ではありません。次回のリクエストで、彼らは最新のアップデートを取得します。
しかし、WebSocket サーバーはどうでしょうか? 古いプロセスを再起動または強制終了すると、接続されているすべてのユーザーが切断されます。私の質問は、WebSocket サーバーをスムーズに展開するためにどのような戦略を使用したかということです。
サーバーが再起動すると、接続しているすべてのユーザーが切断されます。
クライアントの方法でクライアントに再接続するように指示することは、それほど悪くない解決策だと思いonCloseます。
WebSockets は単なる転送メカニズムです。socket.ioのようなライブラリは、そのトランスポートを構築するために存在し、ハートビート、ブラウザ フォールバック、適切な再接続を提供し、リアルタイム アプリケーションで見られるその他のエッジ ケースを処理します。
私たちの WebSocket 対応アプリケーションでは、socket.io は、継続的な展開のセットアップがユーザーのアクティブなソケット接続を切断しないようにするための中心です。
クライアントが、すべてのソケット ネットワーキングとアプリケーション ロジックを実行するサーバーに直接接続されている場合、はい - 接続を保持する TCP レイヤーにより、クライアントは切断されます。
クライアントが接続するゲートウェイがあり、そのゲートウェイ アプリケーションが別のサーバーで実行されているが、論理サーバーと通信してメッセージを転送する場合、論理サーバーはメッセージを送り返し、ゲートウェイはクライアントの応答に送り返します。このようなインフラストラクチャでは、論理サーバーとの接続が再確立されるまで、ゲートウェイにパケットのスタッキングを実装する必要があります。再起動する前に、論理サーバーがゲートウェイ サーバーに通知する場合があります。そうすれば、クライアントは接続を確立し、応答を受信しなくなります。
または、クライアント側の再接続で実装できます。HTTP では、ナビゲートするたびに、ブラウザは実際にサーバーへのソケット接続を作成し、すべてのデータを送信して閉じます (ほとんどの場合)。そして、移動するまで、すべての Web サイト データはローカルです。
WebSocket では連続接続であり、リクエストによる再接続はありません。そのため、WebSockets が終了イベントを取得するときに単純なメカニズムを実装する必要があり、クライアント側で定期的に再接続を試みます。
それはあなたの特定のニーズにもっと基づいています。