1

BinaryReaderクライアント側のオブジェクトで受信データを公開するソケットベースのアプリケーションがあります。リーダーに含まれるデータがクリーンではないという問題をデバッグしようとしています...つまり、読み込んでいるバッファには、新しいデータのサイズを超えた古いデータが含まれています。

以下のコードでは：

System.Diagnostics.Debug.WriteLine("Stream length: {0}", _binaryReader.BaseStream.Length);
byte[] buffer = _binaryReader.ReadBytes((int)_binaryReader.BaseStream.Length);

最初の行をコメントアウトすると、その print line ステートメントがあるときのように、データがダーティになることはありません (または、通常のようにダーティになることはありません)。私が知る限り、サーバー側からのデータは問題なく入ってくるので、ソケットの実装に問題がある可能性があります。しかし、その印刷行を追加するとデータがより頻繁にダーティになる理由を誰かが知っていますか?

4

3 に答える 3

1

バイナリ リーダーは、プライベート メンバー変数のように見えます (先頭のアンダースコアが Tell Tell 記号の場合)。

アプリケーションはマルチスレッド化されていますか? 読み取り中に別のスレッドが binaryReader も使用しようとすると、競合状態が発生する可能性があります。その行がなくても問題が発生するという事実は、私にはかなり疑わしいようです。

于 2012-02-10T17:59:53.883 に答える
0

読み取りロジックが正しいことを確認しますか？読み取られる残りのデータではなく、ストリーム全体Stream.Lengthの長さを示します。

最初に、100バイトが使用可能であったと仮定します。Lengthは100であり、BinaryReader読み取り値を100バイト修正し、ストリーム位置を100進めます。その後、さらに20バイトが到着します。Length現在120です。ただし、BinaryReader読み取りは120バイトではなく、20バイトのみである必要があります。2回目の読み取りで要求された「余分な」100バイトは、ブロックするか、（ストリームが正しく実装されていない場合）中断します。

于 2012-02-10T20:17:36.877 に答える
0

問題はばかげていて、無関係でした。ただし、上記の私の読み取りロジックは正しいと思います。問題は、使用していた _binaryReader がクラスによって所有されていない参照であったため、基になるストリームが不良データで書き換えられていたことです。

于 2012-02-10T22:56:31.080 に答える