要するに、サーバーは ::send() を正常に呼び出しますが、データはケーブルで送信されません。クライアントは何も受信せず、そのコマンドがサーバーによって正しく受信されるため、数秒後に終了コマンドを送信します。
詳細: サーバーはクライアントに 1/10 秒ごとにコマンドを送信し、1 秒ごとにハートビートを送信します。クライアントは、ハートビートに対してのみ ack を返します。送受信したすべてのコマンドをログに記録するようにサーバー アプリケーションを変更し、PC のトラフィックを Wireshark で記録しました。問題が発生するまで、ログに記録されたすべてのコマンドを TCP パケットに一致させることができます。この問題は、一度に 1 つのクライアントにのみ影響します。データは、他のクライアントと正常に流れ続けます。接続は通常、問題が発生する数分前に機能します。接続は、クライアントが起動してから閉じられるまで (数日) 機能するはずです。
問題が発生すると、ログ ファイルには予想されるコマンドが含まれますが、Wireshark ダンプには何も含まれません。以下の画像は、1 つのクライアントのトラフィックを示しています。赤い線はトラフィックが停止したときですが、サーバーは引き続き ::send() を正常に呼び出しています。
約 4 秒後、クライアントはタイムアウトし、接続を閉じます。終了コマンドを送信し、サーバーはそれを正常に受信します。
さらに困惑するのは、quit コマンドを含むパケットが TCP ACK パケットで確認応答されないことです。あたかも送信側で TCP 接続が完全に詰まっているかのようです。再送信はそのジャムの影響ですが、新しい接続を確立するための TCP SYN でさえ正しく処理されず、単純な TCP ACK を取得しません。
約 30 秒後、問題はなくなり、最終的に SYN パケットが受け入れられ、新しい接続で通信が続行されます。
これは、さまざまな Windows バージョンでテストされています。テスト中、リモート デスクトップ セッションが使用されましたが、同じ問題で切断されることはありませんでした。問題なく何時間も接続されたままです。クライアントがワイヤレス ブリッジを通過すると、問題がより頻繁に発生します。ワイヤレス エンドポイントの両側で Wireshark を使用しましたが、切断率が高いことを説明できる再送信やパケット損失は見られません。
多くのクライアントが同じブリッジに接続されている場合、同時に障害が発生することはありません。一度に 1 つだけ。したがって、ワイヤレス ノイズは説明にはならないようです。Wireshark ダンプに再送信が見られますが、通信は通常どおり継続され、問題が発生する前に再送信はありません。アクセスポイントはサーバーのスイッチに接続されています。クライアント PC とサーバー PC はワイヤレス ネットワーク カードを使用しません。
長い間、私たちは時折の切断がネットワークによって引き起こされたことに固執していましたが、ますます多くのインストールがワイヤレスになり、切断が非常に頻繁になり、ユーザーに問題が発生するようになりました。
Windows ファイアウォールを有効にして、または有効にせずに試してみました。ファイアウォールが無効になっている場合でも、ポートの例外を追加しました。クライアントにもサーバーにもウイルス対策がありません。