0

私は同期Beginを使用して切り替えたネットワークサーバーを持っています..短期間のリクエストを処理するために、これは大きな改善でした. 存続期間の長いものについては、2 つのスレッドが作成され、クライアントの数が増加するにつれて問題になり始めています。

これらの接続を介して転送されるデータは、4 ～ 40 バイトのメッセージです。ただし、それらは長さで区切られておらず、その長さはメッセージ内の部分によって異なります。残念ながら、プロトコルを変更することはできません。このプロトコルは、ペースの速い telnet 端末プロトコルと考えることができます。

Stream.BeginRead を使用して受信メッセージ/「行」を読み取って解析することを検討しており、2 つの懸念事項に達しました。

  1. 10 バイトのメッセージに対して BeginRead を 3 回ほど呼び出すのは効率的ですか?
  2. これを行うコードを効率的に書くにはどうすればよいですか

ここに一例があります。メッセージ自体には長さの接頭辞が付いていませんが、その内容の一部に長さの接頭辞が付いている場合があります。

同期方式(現行)

int length = reader.ReadInt32();
byte[] buffer = reader.ReadBytes(length);

非同期方式

    ...
    //Here we have received a byte array
    int length = ParseIntegerFromBuffer(buffer);
    stream.BeginRead(buffer, 0, length, Part1Read, null);
}
private void Part1Read(IAsyncResult result)
{
    ...

非同期の例は私が使用しているものではありません。リクエストされたバイト数の読み取りが成功したかどうかをチェックするラッパーをいくつか作成しました。これは、私が取得できる記述されたコードを記述して理解するという点で効率的ですか?

私のコードは.NET 3.5で実行する必要がありますが、将来的には5がオプションになるので、それを待ってから非同期プログラミングを行う必要がありますか?

このコードはインターネットに面し、同期読み取りを使用すると、着信接続がハングするとスレッドプールスレッドがロックされます。

4

1 に答える 1

0

非同期実装を完了した結果、接続ごとに1つのスレッドを使用する設計の4倍のCPU負荷が発生しました。

解析されるプロトコルはそれ自体が不適切に設計されており、非同期で解析しようとしても、より多くの接続を管理するのに役立ちませんでした。

于 2012-08-02T17:00:50.433 に答える