[RESOLVED] [TCP] What to do with empty buffer?

[toxicious]

I have now successfully written a tcp client and server thingy, following some tutorials.

But I have one question, I am reading data from "the stream" into a 4096 sized buffer. If the message is shorter than that, for example just a serialized string, the rest of the buffer is just zeros.

The tutorial handled the zeros as "keep-alive" messages. Well, it works, but then the program will have to read 4 bytes at a time and check if they converted to an int is zero (I am using "length-framed" writing/reading). That takes some time if there are like 2k+ bytes that needs to be looped through, when other messages just need to wait in queue.

I am sorry if this explanation got messy, but to simplify it:

I have an array of bytes, and I want the program to detect when there are no data left in that array (just zeros), so I can trash it. Is that possible?

Any other suggestions on how my networking should work are welcome too since I am new in this area of programming

[toxicious]

I have solved it for now, by doing this:

If I am looking for a length buffer (containing the length of the message), and I can't find a valid length (>0) in the next 4 bytes I analyze, I report that back to the method that holds the complete 4k buffer I last read from the stream so that method can discard the rest of the data.

I am not sure if this is the right way to solve it, but it works.
I would be really happy to receive some feedback on how to improve/change this solution

Since this solution has at least one con:

If the sender would fail with something and write 4 empty bytes (or more than that) and then write the data it wanted to send, the whole message would be discarded since I throw away the whole 4k read buffer if some bytes fail.

[Evil_Giraffe]

When you read from a stream, you pass it a buffer and tell it how man bytes it is allowed to read from the stream and write into the buffer (this is generally the length of the buffer).

The Read method returns the number of bytes that were actually read from the stream and written into the buffer. You need to save this return value into a variable and then only read that many bytes out of the buffer.

Remember that the buffer only holds zeroes as long as nothing has been written to that element of the buffer before. For example, if the first call to read reads 1024 bytes from the stream, the first 1024 elements of the buffer will be "non-zero" (they may in fact still be zero if the stream had any zero bytes in it, obviously).

If the second call only reads 256 bytes, the first 1024 bytes will still be non-zero. The call to Read doesn't set any unused elements of the buffer back to zero.

I don't know what this "length-framed" technique is, could you provide a link to the tutorial you're referring to? What I can tell you is that you are not guaranteed to read from the stream in the same "chunks" that you wrote to the stream from the other computer, so you need to be prepared to read part of a message, and also more than one message, in a single call to Read.

[toxicious]

Wow I feel so dumb.

Here:
http://nitoprograms.blogspot.se/2009...x-message.html
and this:
http://www.switchonthecode.com/tutor...ded-tcp-server

As you can see in the nito site, he stores the amount read, but he never passes that count on -.-'
Anyway, I have modified the code now to do so

private void HandleClient(object client)
        {
            TcpClient tcpClient = (TcpClient)client;
            NetworkStream clientStream = tcpClient.GetStream();
 
            byte[] data = new byte[4096];
            while (true)
            {
                int bytesRead = 0;
                try
                {
                    //blocks until a client sends a message
                    bytesRead = clientStream.Read(data, 0, 4096);
                }
                catch
                {
                    //a socket error has occured
                    break;
                }
 
                if (bytesRead == 0)
                {
                    //the client has disconnected from the server
                    break;
                }
 
                //data has been received, process it
                ProcessData(data, bytesRead);
            }
 
            tcpClient.Close();
        }
 
        private void ProcessData(byte[] data, int count)
        {
            int i = 0;
            while (i != count)
            {
                int bytesAvailble = count - i;
                if (dataBuffer != null)
                {
                    //We're reading into the data buffer
                    int bytesRequested = count - bytesReceived;
 
                    //Copy the incoming bytes into the buffer
                    int bytesTransferred = Math.Min(bytesRequested, bytesAvailble);
                    Array.Copy(data, i, dataBuffer, bytesReceived, bytesTransferred);
                    i += bytesTransferred;
 
                    //Notify read completion
                    ReadCompleted(bytesTransferred);
                }
                else
                {
                    //We're looking for the length buffer
                    int bytesRequested = lengthBuffer.Length - bytesReceived;
                    int bytesTransferred = Math.Min(bytesRequested, bytesAvailble);
 
                    Array.Copy(data, i, lengthBuffer, bytesReceived, bytesTransferred);
                    i += bytesTransferred;
 
                    ReadCompleted(bytesTransferred);
                }
            }
        }

I haven't copy and pasted anything, though I have written the same lines since I was following his tutorial

Oh and I am taking care of the half-message situations in the later methods, as the second tutorial does

[Evil_Giraffe]

I found a link to the nito blog from another thread you posted. The fixed-length stuff is about how to break apart and stitch back together the multiple/partial reads. It's the logical layer above the stream reading code.

Good luck with the rest of it, you probably should go back and read the previous post on the nito site regarding why why you need to do this, if you haven't already.

[toxicious]

Oh yeah I read that "discussion" over at codeproject before, always interesting to know how stuff works