C＃Socketasynceventargsは、完了したイベントの発射を停止します

Question

Socketasynceventargsのコンプレットされたイベントが問題に気づきました 発砲をやめるようです. 。同じSAEAが適切に発射し、プールに数回交換できますが、最終的にはすべてのインスタンスが発射を停止し、プールでそれらを交換するコードがイベントハンドラーにあるため、プールは空になります。

次の状況 また、明らかに真実です：

1）サーバー側のソケットが接続されたクライアントのいずれかにデータを送信する場合にのみ発生するようです。同じクラスがクライアントとして接続している場合、誤動作しないように見えます。

2）高負荷の下で発生するようです。スレッドカウントは、最終的にエラーが発生するまで忍び寄るようです。

3）同様の応力下のテストリグは、誤動作しないように見えます。 （1秒あたりわずか20のメッセージであり、テストリグは20kで証明されています）

私はかなり複雑なコードを貼り付けることができませんが、ここにあります 私のコードの説明:

1）主なインスピレーションはこれです： http://vadmyst.blogspot.ch/2008/05/sample-code-for-tcp-server-using.html. 。イベントを使用して完了ポートを接続する方法、TCP接続でさまざまなサイズのメッセージを取得する方法などを示しています。

2）すべてのSAEASには、重複しないピースがあるバイトバッファーがあります。

3）ブロッキングコレクションに基づいて、SAEASのオブジェクトプールがあります。これは、プールが長すぎる場合にスローします。

4）サーバーとして、クライアントのエンドポイントによってインデックス化されたAcceptAsync関数から返されたソケットのコレクションを保持します。単一のプロセスでは、1つのインスタンスをサーバーとして、および複数のインスタンスをクライアントとして使用できます（Webの形成）。 SAEASのデータバッファとプールを共有しています。

これを説明するのは難しいと思います。私はそれを昼も夜もデバッグしてきました。誰かがこれを聞いたこと、または有用な質問や提案があることを願っています。

現時点では、私はある種のスレッドの疲労を疑っており、SAEASが完了を呼び出すことができないと疑っています。あるいは、発信バッファーのある種のバッファー問題。

Answer 1

だから、別のデバッグの日と最後に説明があります。

1）SAEASは、完成したイベントをさらに送ることができなかったため、完成したイベントを解雇していませんでした。これは、WiresharkによってTCPウィンドウが空になっているために明らかにされています。 （TCP Zerowindow）

2）TCPウィンドウは、ネットワーキングレイヤーが完了するのに時間がかかりすぎるスタックにイベントを渡していたため、空になっていました。つまり、ネットワークレイヤーとUIの間に生産者/消費者はいません。したがって、ACKを送信する前に、ネットワークOPは画面の描画を待つ必要があります。

3）時間がかかりすぎたイベントは、GUIのイベントハンドラーのスクリーンドローでした。テストリグはコンソールウィンドウ（着信メッセージを要約したもの）であったため、はるかに高い負荷で問題を引き起こしませんでした。各メッセージで画面を再描画しないことは普通ですが、これはプロジェクトがまだ完成していないために起こっていました。再描画率は後で修正されていました。

4）短期的な解決策は、単にショーを保持しているGUIがないことを確認することです。より堅牢なソリューションは、ネットワークレイヤーで生産者/消費者を作成することです。