locked
When does Network Stream Read returns 0? RRS feed

  • Question

  • Hello.

    I have the exact same question as 

    https://social.msdn.microsoft.com/Forums/en-US/6dbd1467-6a90-43bb-abaa-df5ca5a1cd85/when-does-networkstreamread-return-zero?forum=netfxnetcom

    In other words, when does network stream read returns 0? The post there was not answered clearly, so I am still confused. It is supposed that read is blocking, but on the other side, if data is not available what happens?

    My code is like this

                          do
                             {
                                nbytes = clientStream.Read(bytes, 0, bytes.Length);
                                data = Encoding.ASCII.GetString(bytes, 0, nbytes);
                                myCompleteMessage.AppendFormat("{0}", data);
    
                                Console.WriteLine("read {0}", nbytes);
                                Console.WriteLine("> {0}", data);
    
                            } while (clientStream.DataAvailable);

    and there when there is no message available, the read returns 0! ( i thought it would block!) so I have a lot of "Read 0 bytes" in the screen. 

    Can someone clarify please the correct behavior of Read because the documentation seems to be misleading

    Thanks

    Tuesday, October 11, 2016 2:48 AM

Answers

  • Hi Robothito,

    When check the documentation for `Stream.Read()' states from MSDN

    In remark section:

    Implementations of this method read a maximum of count bytes from the current stream and store them in buffer beginning at offset. The current position within the stream is advanced by the number of bytes read; however, if an exception occurs, the current position within the stream remains unchanged. Implementations return the number of bytes read. The implementation will block until at least one byte of data can be read, in the event that no data is available. Read returns 0 only when there is no more data in the stream and no more is expected (such as a closed socket or end of file). An implementation is free to return fewer bytes than requested even if the end of the stream has not been reached.

    So it stands now the NetworkStream should block until either it is closed or until at least one byte is available.

    Best regards,

    Kristin


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.



    Friday, October 14, 2016 6:31 AM

All replies

  • I think that your results corresponds to the documentation for NetworkStream, which says that if no data is available for reading, Read returns 0.

    Perhaps you should use a loop where DataAvailable is checked before the Read.

    Probably the behaviour depends on the kind of streams. In case of network, the receiving stream does not always know the length of transmission. In case of files, the length is known, therefore FileStream.Read usually blocks until the amount of data is read.

    If you want to perform other useful actions while there are no data, then consider ReadAsync or BeginRead.

    Tuesday, October 11, 2016 11:09 AM
  • >Can someone clarify please the correct behavior of Read because the documentation seems to be misleading

    "If no data is available for reading, the Read method returns 0. The Read operation reads as much data as is available, up to the number of bytes specified by the size parameter. If the remote host shuts down the connection, and all available data has been received, the Read method completes immediately and return zero bytes."

    NetworkStream.Read

    That seems pretty clear to me.  Read() returns 0 when no data is available and the other side has shut down the connection.  This is not always the most convenient behavior, but NetworkStream usually wraps the sockets API which behaves the same way.

    Winsock recv

    So with NetworkStream you can't assume that each Read() will return the requested number of bytes.  It may return fewer.

    David


    David http://blogs.msdn.com/b/dbrowne/



    Tuesday, October 11, 2016 11:57 AM
  • Thank you for your answer. And sorry to disagree but it is not clear to me, because when there is no data, read does not return 0. It blocks. 

    Yes, when the connection on the other side is closed, read returns 0. but if not as far as I know it does not return 0.

    I analyzed more of my problem and it seems the user was closing the application without doing the appropriate closing streams and sockets. When he started the application again, the read operation returned 0 all the time...

    I advised him to properly close the application. 

    Wednesday, October 12, 2016 2:18 AM
  • Hi Robothito,

    When check the documentation for `Stream.Read()' states from MSDN

    In remark section:

    Implementations of this method read a maximum of count bytes from the current stream and store them in buffer beginning at offset. The current position within the stream is advanced by the number of bytes read; however, if an exception occurs, the current position within the stream remains unchanged. Implementations return the number of bytes read. The implementation will block until at least one byte of data can be read, in the event that no data is available. Read returns 0 only when there is no more data in the stream and no more is expected (such as a closed socket or end of file). An implementation is free to return fewer bytes than requested even if the end of the stream has not been reached.

    So it stands now the NetworkStream should block until either it is closed or until at least one byte is available.

    Best regards,

    Kristin


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.



    Friday, October 14, 2016 6:31 AM