bugfix> sockets > 投稿

ソケットを使用して15年間プログラミングを行っており、以前はこれに遭遇しませんでした。

標準のTCPソケットサーバーを実行すると、クライアントはそれに接続し、開いているソケットを介してメッセージが送受信されます。これは、サーバーが実行しているゲームの世界でクライアントが行動しているゲームサーバーです。このサーバーは、過去3か月間に160万のこのようなソケットセッションを処理しました。

サーバーは、クライアントから受信したメッセージを記録しています。クライアントは、サーバーから受信したメッセージを記録し、サーバーに送信するメッセージも記録します。

セッションの途中で接続が失われたように見えるエンドユーザーからバグレポートを受け取りましたが、ログを見ると、接続が一方向にのみ壊れているように見えます。サーバーの送信が正常に通過し続けても、クライアントの送信は通過しませんでした。

何分間も何度もメッセージをやり取りした後、サーバーはこのクライアントから最後のメッセージを1つ受け取り、そのソケットを介してそれ以上何も受け取りません。一方、クライアントはサーバーからメッセージを常に受信し続け、サーバーにメッセージを送信し続けました(その観点からは、これらは小さなメッセージであり、おそらく送信中に蓄積されただけでした)バッファ)。

サーバーは最終的に、クライアントがアイドル状態であることを検出し、別れのメッセージを送信し、接続を閉じました。クライアントは別れのメッセージも受け取りました。

このプロセスは18秒続きました(サーバーがクライアントから最後のメッセージを受信して​​から、さようならメッセージを送信するまで)。

質問:この動作はTCPソケットで可能ですか?一方向にのみ破損または失速する場所

私は通過することになっているcksについて考えています。クライアントの場合->サーバールートが破損している場合、サーバーはもうackを取得しません。つまり、サーバーはタイムアウト後にすべてのパケットを何度も再送します。しかし、それは新しいパケットの送信を停止するという意味ではありません。また、クライアントは送信するパケットに対してACKを返さないでしょうが、別の理由(パケットがまったく通過しないため、サーバーがそれらをACKできない)のため、タイムアウトになりますそして再送。

これは、ネットワークルーティングの質問ほどTCPの質問ではないのかもしれません。 2方向のルートは1つの方法でのみ中断できますか?

回答 1 件
  • おそらくルーティングの問題だと思います。単方向トラフィックに関する上記の他のコメントは、 shutdown(2) の場合にのみ適用されます  アプリケーションが明示的にそれをしなければならないので、おそらくあなたは知っているでしょう。

    ルーティングは、2つの方向で異なる場合があります(@RonMaupinが述べたように)。または、中間ルータで一方向に大量の輻輳が発生した可能性があります。どちらの状況でも、パケットがドロップされる可能性があります。

    このようなドロップされたパケットに直面して、両側はACKを受信しないために送信を再試行し続けます(あなたが正しく説明したと思います)。初期再送信時間は、各エンドポイントマシンによって計算された概算の往復時間に基づいています。その後、後続の再送信のための指数バックオフがあります-たとえば、http://www.pcvr.nl/tcpip/tcp_time.htm#21_2を参照してください。結果は最終的なタイムアウトです。

    指数関数的なバックオフといくつかの再送信(その数はプラットフォーム固有であり、多くの場合構成可能です)を考えると、通常、ローカルネットワークスタックがセッションデッドを宣言するまでに18秒以上かかります。しかし、アプリケーションが独自のタイムアウトでこのプロセスを短絡しているように思えます(ゲームサーバーにとっては妥当なようです)。

    一般にルートは両方向で同じであり、ルーターが「ダウン」しているときは、両方向でダウンしているため、これを見たことはないと思います。

あなたの答え