Таким образом, может показаться, что блокирующий Read () может вернуться до того, как он завершит получение всех отправляемых ему данных. . В свою очередь, мы заключаем Read () в цикл, управляемый значением DataAvailable из рассматриваемого потока. Проблема в том, что вы можете получить больше данных в этом цикле while, но не будет никакой обработки за кулисами, чтобы система знала об этом. Большинство решений, которые я нашел для этого в сети, так или иначе не были применимы ко мне.
В конце концов я сделал последний шаг в своем цикле: я делаю простой Thread.Sleep ( 1) после чтения каждого блока из потока. Похоже, это дает системе время на обновление, и я не получаю точных результатов, но это кажется немного взломанным и довольно «косвенным» для решения.
Вот список обстоятельств, с которыми я имею дело: Один TCP Соединение между приложением IIS и автономным приложением, написанным на C # для передачи / получения. Он отправляет запрос, а затем ожидает ответа. Этот запрос инициируется HTTP-запросом, но у меня нет этой проблемы с чтением данных из HTTP-запроса, это постфактум.
Вот базовый код для обработки входящего соединения.
protected void OnClientCommunication(TcpClient oClient)
{
NetworkStream stream = oClient.GetStream();
MemoryStream msIn = new MemoryStream();
byte[] aMessage = new byte[4096];
int iBytesRead = 0;
while ( stream.DataAvailable )
{
int iRead = stream.Read(aMessage, 0, aMessage.Length);
iBytesRead += iRead;
msIn.Write(aMessage, 0, iRead);
Thread.Sleep(1);
}
MemoryStream msOut = new MemoryStream();
// .. Do some processing adding data to the msOut stream
msOut.WriteTo(stream);
stream.Flush();
oClient.Close();
}
Все отзывы приветствуются для лучшего решения или просто одобряют необходимость использования Sleep (1) для правильного обновления данных перед проверкой DataAvailable значение.
Думаю, через 2 года я надеюсь, что ответ на этот вопрос не в том, как дела обстоят до сих пор :)