Asynchronous Client Socket, increasing the buffer

Question

I've implemented an Asynchronous Client Socket extremely similar to this example. Is there any reason why I cannot dramatically increase this buffer size? In this example the buffer size is 256 bytes. In many cases, my application ends up receiving data that is 5,000++ bytes of data. Should I increase the buffer size? Are there any reasons why I should NOT increase the buffer size?

Every once in a long while I'll get some issue where the data comes in out of order or a chunk is missing (yet to be confirmed exactly which it is). For example, one time I received some corrupt data that looks like this

Slice Id="0" layotartX='100'

The attribute called layotartX does not exist in my data, it was supposed to say layout=... but instead the layout got cut off and other data was appended to it later. I counted the bytes and noticed that it was cut off at exactly 256 bytes which just so happens to be my buffer size. It's very possible that increasing my buffer size would prevent this problem from happening (data coming in out of order??). Anyways, as stated in the 1st paragraph, I'm just asking if there is any reason I should NOT increase the buffer size to be say like 5,000 bytes or even 10,000 bytes.

Adding some code. Below is my modified ReceiveCallback function (see the linked example code above for the rest of the classes. When the ReceiveCallback receives data, it calls the "ReceiveSomeData" function which I've also posted below. For some reason every once in a while I get data out of order or pieces missing. The "ReceiveSomeData" function is in a class called "MyChitterChatter" and the "ReceiveCallback" function is in a class called "AsyncClient". So when you see the ReceiveSomeData function locking "this", it's locking the MyChitterChatter class. Is there were my problem could by lying?

    private static void ReceiveCallback( IAsyncResult ar )
    {
        AppDelegate appDel = (AppDelegate)UIApplication.SharedApplication.Delegate;

        try {
            // Retrieve the state object and the client socket 
            // from the asynchronous state object.
            StateObject state = (StateObject) ar.AsyncState;
            Socket client = state.workSocket;

            // Read data from the remote device.
            int bytesRead = client.EndReceive(ar);

            if (bytesRead > 0) {
                // There might be more data, so store the data received so far.
                string stuffWeReceived = Encoding.ASCII.GetString(state.buffer,0,bytesRead);

                string debugString = "~~~~~ReceiveCallback~~~~~~ " + stuffWeReceived + " len = " + stuffWeReceived.Length + " bytesRead = " + bytesRead;

                Console.WriteLine(debugString);


                // Send this data to be received
                appDel.wallInteractionScreen.ChitterChatter.ReceiveSomeData(stuffWeReceived);

                // Get the rest of the data.
                client.BeginReceive(state.buffer,0,StateObject.BufferSize,0,
                    new AsyncCallback(ReceiveCallback), state);
            } else {
                // Signal that all bytes have been received.
                receiveDone.Set();
            }
        } 
        catch (Exception e) {
            Console.WriteLine("Error in AsyncClient ReceiveCallback: ");
            Console.WriteLine(e.Message);
            Console.WriteLine(e.StackTrace);
        }
    }


    public void ReceiveSomeData ( string data )
    {
        lock(this)
        {
            DataList_New.Add(data);

            // Update the keepalive when we receive ANY data at all
            IsConnected = true;
            LastDateTime_KeepAliveReceived = DateTime.Now;
        }
    }

Answer 1

Yes, you absolutely should increase the buffer size to something much closer to what you expect to get in a single read. 32k or 64k would be fine choice for most uses.

Having said that, data never comes in "out of order" or "missing a chunk" if you're using a TCP/IP socket; if you see something like that, it's a bug in your code, not a bug in the socket. Share your code if you want help.