問題タブ [networkstream]

プロジェクトの一部として、NetworkStreamから派生したクラスがあります。この場合、ReadやReadByteなどのメソッドのラップされた実装を提供して、コンテキスト固有の安全性を提供します（いくつかの追加ロジックを使用して基本メソッドを呼び出します）。

しかし、これをテストすることは問題です。このクラスでは、コンストラクター（コンクリート型）にSocketが必要であり、モックは機能しません（ここでは、Moqを使用します。おそらく、TypeMockのようなものですが、コストのかかるツールは避けたいと思います）。

もう1つの方法は、継承するのではなく作成し、NetworkStreamをラップし、NetworkStreamと同様の独自のインターフェイスを実装するクラスを作成することです。しかし、これも問題です。StreamReaderなどのBCL内のストリームのほとんどのコンシューマーは、具体的なStreamまたは派生型を必要とするため、作成されたクラスでは機能しません。

だから、誰かが代替案を考えることができますか？それは私がまともな報道なしで去ることについて私が幸せに感じるものではありません-それは多くがうまくいかないかもしれない領域であり、そしてそれはしっかりしているべきです。

TCPを介して実装された単純なプロトコルがあり、各メッセージは次のもので構成されていると仮定します。

1. int指示データ長。
2. 1で指定された長さのバイナリデータ。

そのようなメッセージを読んで、私は次のようなものが欲しいです：

使用中Socket.ReceiveまたはNetworkStream.Read使用可能なバイト数が読み取られます。バイトが使用可能ReadBytesになるまで呼び出しをブロックしたい。length

読み取りをループせずに、残りのデータを待機するオフセットで再起動することなく、これを行う簡単な方法はありますか？

実際のアプリケーションでは、読み取りはおそらく非同期またはバックグラウンドスレッドで実行する必要がありますが、今のところそれを無視しています。重要なことは、すべてのデータが利用可能になるまで読み取りが完了しないようにすることです。

編集

私は自分でデータをバッファリングできることを知っており、その方法も知っています。Receive次のオフセットで続くループです。私が求めているのは、そのようなループの再利用可能な実装があり、いかなる種類の独自のループも必要ないかどうかです（または、すべてのデータが利用可能になったときに終了する再利用可能な非同期実装）。

通常、クライアント/サーバー通信用に異なるポートが必要になるのはいつですか？（この質問は、C＃および一般的なソケットプログラミングに関するものです）。

単純なC＃クライアントサーバーアプリケーションを実装して使用しています。基本的に：

• サーバーはクライアントをリッスンします
• 受け入れられた/接続された
• サーバースポーンクライアントスレッド-
• サーバーはクライアントが話すのを待つ
• クライアントトーク
• サーバーの応答
• クライアントトーク
• サーバーの応答など。

NetworkStream.Read()クライアントが会話を停止した場合、クライアント側が切断しない限り、サーバーはその生成されたスレッドで永久にモードでブロックします。

私は今、どちらかの側で何らかのイベントが発生するまで両側が静かになり、クライアントまたはサーバーのみがデータを送信する状況を考えています。そのため、両方が何らかの形で同時にNetworkStream.Readモードになり、同時に相互に送信できる必要があります（イベントが両側で同時に発生した場合）。

この場合、異なるポートが必要ですか、それともクライアントとサーバーの両方をNetworkStream.BeginReadモードにすることができますか？NetworkStreamが書き込みモードと送信モードの両方で同時に発生するという問題のリスクはありませんか？

ありがとう。

Networkstream.Read()スレッドのブロックを停止する方法を知りたいです。NetworkStream.Read()サーバーからのデータを待っている別のスレッドがあります。ユーザーが何らかのデータをサーバーに送信するボタンを押したとします。しかし、データを待っている他のスレッドにいるNetworkStream.Write()間は呼び出すことができません。毎回NetworkStream.Read()ロックできますが、スレッドをブロックするため、少なくとも 1 バイトを読み取るまでデータを送信できません。NetworkStreamNetworkStream.Read()

MSDN のドキュメントは、NetworkStream.Read が常にすぐに返されることを示唆しているようです。データが見つからない場合は 0 が返されます。ただし、現在展開されているコードがいくつかありますが、そのコードは一部のケース (まだどのケースかはわかりません) でのみ、NetworkStream.Read がハングしているように見えます。これは、ダンプファイルから収集できたスタックトレースです

NetworkStrea.Read が実際に Socket.Receive を呼び出していることに気付きましたが、これは私が理解している限りブロックされている可能性があります。なぜ時々ブロックされ、時々ブロックされないのかわかりません。

iOS で、ネットワーク ストリームから取得した文字列と文字列を比較しようとしています。

ストリームを読み取るコードは次のとおりです。

相手側のサーバーは常に 1024 バイトの応答を生成し、データの最後に chr(0) を配置してバッファを埋めます。

文字列比較を行う場合:

おそらく、文字列に応答と多くのヌル文字が含まれているため、常に否定的な結果が得られます。

応答を文字列に読み込むときに、バッファから空の文字を削除できるようにしたいのですが、iOS でこれを行うのはうまくいきません。

助けてください！

ありがとう。

デイブ

クライアントからリクエストを受信し、リクエスト タイプに応じたレスポンスを返すサーバーを構築しました。リクエスト タイプがストリーミングの場合、サーバーはデータ配列を送信する必要があります。サーバーがデータをストリーミングしている間、クライアントは停止要求を送信してストリーミングを停止する場合があります。要求と応答が同じ TCP 接続で転送される場合、サーバーは、すべてのデータがクライアントへのストリーミングを終了したときにのみ停止要求を受信します。この問題を解決するには、非同期書き込みを使用する必要があると思います。これは私のコードです:

最初に、クライアントからの接続を受信するためのループ バックを作成します。

ClientInteraction クラスの In Process 関数:

HandleRequest 関数では、リクエストが STREAM の場合、配列内のデータをクライアントに送信します。

このコードで、クライアントに接続し、データをクライアントに送信します。しかし、すべてのデータがストリーミングされるまで、停止要求を受信できません。私の問題を解決する正しい方法を教えてください。ありがとうございました。

私は現在、私が書いたマネージ C# ネットワーク ライブラリをテストしていますが、時折問題に遭遇しました。この問題は、おそらくすべての送信操作の 1% で、networkstream.write() で非常に一貫した (常に 30 ミリ秒以内) 5000 ミリ秒のブロックとして現れます。これはテスト環境で、毎回まったく同じパケット サイズ (2MB) を使用して、すべてローカルで実行されています。クライアント側では、接続されたネットワーク ストリームに次の内容を継続的に書き込みます。

サーバー側では、データを待機する非同期読み取りを使用します。データが表示されたら、すべてのデータが受信されるまで、tcpClientNetworkStream.DataAvailable に対して while ループを使用します。

バッファがいっぱいの場合、 networkstream.write() がブロックされる可能性があることは認識していますが、これが問題である場合、サーバー側でバッファをクリアするより迅速な方法は考えられません (送信および受信バッファ サイズはデフォルトで 8192 バイトです)。 . ブロックが非常に一貫しているという事実は、非常に奇妙に思えます。私が最初に考えたのは、おそらく何らかの形の Thread.Sleep でしたが、プロジェクト全体を検索しても何も表示されませんでした。誰かがこの問題に光を当てるのを助けることができれば、それは大歓迎です.

マルク

追加する編集：問題を解決するように見えるハックは次のとおりです（BlockCopyによる関連するパフォーマンスヒットがありますが）：

add2 への編集: また、2 つの非同期書き込みを使用して、2 つの間のスレッド シグナルを使用して問題を再現しました。現時点で私が持っている唯一の解決策は、上記の編集のように単一の書き込み操作です。

add3 への編集: OK、別の可能な修正が続きます。連続した書き込みが時折「ブロック」する理由を知りたいと思っています。

add4 への編集: 「add3 への編集」の解決策をさらに広範囲にテストした後、問題は解消されず、発生が送信の約 0.1% に減少するだけです。はるかに優れていますが、解決には程遠いです。PaulF が提案したように、次に非同期読み取りをブロック読み取りに置き換えて、それがソートされるかどうかを確認します。

接続先のネットワーク ストリームから行を読み取る非常に単純なコードがあります。コード例では、1 行だけが読み取られ、サーバーからさらに取得することはありません。

なにが問題ですか？