Странное поведение с BinaryReader

Question

У меня есть приложение на основе сокетов, которое предоставляет полученные данные с помощью объекта BinaryReader на стороне клиента. Я пытался отладить проблему, когда данные, содержащиеся в считывателе, не чистые ... то есть буфер, который я читаю, содержит старые данные, превышающие размер новых данных.

В коде ниже:

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

Когда я закомментирую первую строку, данные не будут загрязнены (или не будут загрязнены так же регулярно), как когда я получаю это выражение для строки печати. Насколько я могу судить, со стороны сервера данные поступают чисто, поэтому возможно, что у моей реализации сокетов есть некоторые проблемы. Но есть ли у кого-нибудь идеи, почему добавление этой строки для печати приводит к более частому загрязнению данных?

Answer 1

Ваш двоичный читатель выглядит так, как будто он является закрытой переменной-членом (если начальное подчеркивание является признаком «сказать-сказать»).

Является ли ваше приложение многопоточным?Вы можете столкнуться с состоянием гонки, если другой поток пытается использовать ваш двоичный ридер во время чтения из него.То, что у вас возникают проблемы даже без этой линии, кажется мне довольно подозрительным.

Answer 2

Проблема была глупой и не связанной.Однако я верю, что моя логика чтения выше верна.Проблема заключалась в том, что _binaryReader, который я использовал, был ссылкой, которой не владел мой класс, и, следовательно, основной поток переписывался с неверными данными.

Answer 3

Вы уверены, что ваша логика чтения правильная? Stream.Length указывает длину всего потока , а не оставшихся данных для чтения.

Предположим, что изначально было доступно 100 байтов. Length равно 100, а BinaryReader исправляет чтение 100 байтов и увеличивает позицию потока на 100. Затем прибывают еще 20 байтов. Length теперь 120; однако ваш BinaryReader должен считывать только 20 байтов, а не 120. «Дополнительные» 100 байтов, запрошенные во втором чтении, либо приведут к его блокировке, либо (если поток реализован неправильно), прервутся.