このプロジェクトでは、プロトコルは次のとおりです。
ログで、タイムアウト後に ack を受信することがあることに気付きました。ソケットは閉じた後もクリーンアップとストラグラーのために開いたままなので、その理由は理解できます。
しかし、これを処理するより良い方法はありますか? ライン オペレータに何かを報告する前に、接続が本当にダウンしていることを確認したいと思います。
現在のタイムアウトは、外部タイマーに関連付けられた任意の値 (2.5 秒) です。.Net TCP スタックにはありません。
あなたの側でソケットが閉じられない限り、TCP 接続は実際にはダウンしていません。データを送信した後、ネットワークから応答を受信しない場合、TCP が接続がダウンしていると判断してソケットを閉じるまでに数分かかります。
ソケットの抽象化は、TCP チャネルを介して双方向ストリームをレイヤー化します。Write() (または同等のもの) が正常に返されたとき、および Read() がゼロ以外の文字数を返したときにのみ、スタックがフラグメントを受け入れたことをユーザーは確認します。下位レベルは不透明です。サーバーがデータを受信して確認したことを確認するには、許可された期間内に Read() が予想される量のデータを返すことを確認する必要があります。
リクエストごとに新しいセッションを接続する必要があるため、セッションを破棄して次のセッションに道を譲る以外に選択肢はほとんどありません。特に、サーバーが複数の同時接続を許可しない可能性があるため、セッションをそのままにしておくことはできません。
タイムアウトは 2.5 秒であると述べています。これがメッセージ間隔よりもはるかに小さい場合、タイムアウトを間隔に近い値に延長すると問題がありますか。これは、同じデータの複数の迅速な要求を打ち消すよりも信頼性が高いようです。