Is there a chance of a slight delay in receiving data (using any of the .NET tcp socket protocol)

Question

My client-server application uses a basic implementation as provided by this MSDN article. However, the variation is that I am not using the <EOF> type of delimiter because the way my application works is this:

1. Server waits for client
2. Client connects
3. Server waits for clients to request something
4. Client eventually requests something (like "Please send CV of Hans Passant in PDF format?")
5. Server replies appropriately
6. Server waits for clients to request something (i.e. goes back to Step 3 again)

This cycle continues until the connection is closed.

In reference to this SO question, is it possible, via any of the .NET implementations of receiving data from a socket (Socket.Receive, TCP.GetStream().Read(...)...etc.) is it possible that there will be a time when a Read or Receive operation will return a false 0? (e.g. some data is read already, the next packet gets stucked in traffic temporarily and the Read/Receive operation does not know, so it just assumes there is nothing more to read and just returns zero).

My code below:

public void recieveClientData()
        {
            byte[] bs = new byte[1];// 'commStream' is NetworkStream of the socket    
            commStream.Read(bs, 0, 1);//blocks until something comes in 
            // Buffer for reading data 
            Byte[] bytes = new Byte[1024];
            using (MemoryStream m = new MemoryStream())
            {
                //scoop what we have yet
                m.Write(bs, 0, 1);

                //get the remaining
                int length;

                while ((length = commStream.Read(bytes, 0, bytes.Length)) != 0)
                {
                    m.Write(bytes, 0, length);
                }

                //At this point, 'm' is sent for asyncronously processing
                ...

                //wait for another data from this client
                recieveClientData();
            }  
        }

Now at the line while ((length = commStream.Read(bytes, 0, bytes.Length)) != 0), let us assume that the client is sending the server a PDF file of about 32Mb (so the server can save it for future retrieval), is it possible that when the line commStream.Read(bytes, 0, bytes.Length) is executing in a loop, a network lag is preventing that stream from having something to read, such that it returns 0 (meaning there is a network delay of some kind on a network packet but before that packet eventually makes it through and gets transported, commStream.Read has already read 0 and returned)

Note that I can't use delimiters here because transmitted data is not always string.

Answer 1

TCP connections are stream oriented. There is no concept of message. Therefore is is very likely (at least on a bad network), that one of your Write() will be received with multiple Read(), or that multiple Write() will be received with a single Read(). You should never rely on Read() to break your stream in messages/requests.

The usual way is to know in advance what you will receive, or to send a size before actual data of unknown size. With TCP, data is guaranteed to be transmitted uncorrupted, so you should rely on this instead. Of course, a big problem can always occurs and reset the connection, but then you will have an exception, and handle it separately.

You should take a look at BinaryReader and BinaryWriter, these classes might make things simpler for you : a ReadString() will read a string complete, and a ReadBytes() will read exactly the number of bytes specified.

Edit: To clarify a bit, Socket.Receive() and NetworkStream.Read() with 64 as size parameter are not guaranteed to return with 64 bytes. They can return with 1, 10, 32, 63 or whatever (not 0, it would keep blocking, unless there is a timeout). BinaryReader.ReadBytes(64), on the other hand, is guaranteed to wait for 64 bytes. Connection problems are handled separately with exceptions.