0

TcpClient から継承するクラスがあります。そのクラスには、応答を処理するメソッドがあります。そのメソッドで、MyBase.GetStream を使用して NetworkStream を取得し、Read を呼び出します。

ブロックを読み取るための最初の呼び出しが長すぎることを除いて、これは正常に機能します。そして、長すぎるということは、ソケットが大量のデータを受信したにもかかわらず、任意の制限に達するまでそれを読み取らないことを意味します。パケット スニファ WireShark を使用して、大量のデータを受信したことがわかります。

受信バッファーを少量に設定しましたが、非常に少量 (ほんの数バイトなど) は役に立ちません。read メソッドに渡すバッファ バイト配列でも同じことを行いましたが、それでも遅延が発生します。

または別の言い方をすれば。私は600kをダウンロードしています。ダウンロードには 5 秒かかります (サーバーへの接続が 100k/秒を少し超える場合、これは理にかなっています)。最初の Read 呼び出しには 2 ～ 3 秒かかり、256 バイトしか使用できないことがわかります (256 は受信バッファーであり、読み込んだ配列のサイズです)。次に、魔法のように、残りの数十万バイトは、わずか数プロセスティックで 256 バイトのチャンクとして読み取ることができます。パケット スニファを使用すると、最初の 2 ～ 3 秒間に、ソケットが 256 バイトをはるかに超える量を受信したことがわかりました。私の接続は、3 秒間は 0.25k/秒ではなく、2 秒間は 400k ではありませんでした。

入ってくるバイトをソケットから取得するにはどうすればよいですか?

4

2 に答える 2

2

オープン ソースのC# ネットワーク ライブラリを作成するときに、同様の問題が発生しました。設定してみてください：

tcpClient.NoDelay = true;
tcpClient.Client.NoDelay = true;

これにより、nagle アルゴリズムの動作がデフォルトで無効になります。これにより、非常に少量のデータを送受信するときに、意図的にあらゆる種類のランダムな遅延が発生します。

于 2011-12-18T20:41:15.197 に答える
0

私もこれに数回遭遇しましたが、2〜3秒の遅延の原因となったマシンのInternet Explorer設定（プロキシ設定/ LAN設定など）を確認する必要があるようです。

System.Net名前空間内のクラス（つまり、WebClient、HttpWebRequest）は、最初の要求でこれを自動的に行うようです。

IEのプロキシ設定/LAN設定、特に自動設定検出オプションをオフにするか変更してみてください。役立つ場合があります。

それでも問題が解決しない場合は、次の記事をご覧ください：HttpWebRequest.GetRequestStreamの最初の使用での不思議な遅延。正確にはTcpClientではありませんが、同じ問題だと思います。

お役に立てれば。

于 2009-12-27T09:21:34.347 に答える