SslStream .read() returns with first byte once a packet

Question

I want to read packets from my SslStream.

I send the packets using websocket. Also, this function is started after i finished the WS Handshake so it is for reading data frames.

This is the function for reading:

byte[] buffer = new byte[16 * 1024];
int read;
while (true) {
    read = input.Read(buffer, 0, buffer.Length);

    Console.WriteLine("Length: " + read + " Buffer: " + GetNumberOfSlotsUsed(buffer));

    if (read <= 0) {
        ...
    } else if (read < 3) {
        ...
    } else {
        ...
    }
}

Once i receive a packet, this is what gets printed out to the console:

Length: 1 Buffer: 1
Length: 57 Buffer: 57

Can the problem be in this function or is it the Browser which sends the packets?

I use the "socket.read()" function in my Websocket Server written in Java and there is no problem, so it must be C# right?

Edit #1:

Javascript code for sending:

var socket = new WebSocket(serviceUrl, protocol);
socket.onopen = function () {
    socket.send(omeString);
}

Answer 1

For future people searching for this exact same issue:

I have found an article explaining that this odd occurrence is by design.

This seems like an odd thing to call a "Feature." Basically (as i understand it) this change was to make SslStream Read and Write the first byte and then push the rest. I personally think that this is an odd change. Kinda weird to force multiple packets of transfer. (I am fully aware that this could happen, its just odd to force an additional packet on top of a possibility that packets could be segmented.)

Link to Article

---

Posted by Nimbus.Hex

When ran on machine updated with KB3147458, this output is produced:
BytesRead => 1
BytesRead => 40
BytesRead => 1
BytesRead => 40
BytesRead => 1
BytesRead => 40
BytesRead => 1
BytesRead => 40
BytesRead => 1
BytesRead => 40

When ran on a machine without KB3147458, this output is produced:
BytesRead => 41
BytesRead => 41
BytesRead => 41
BytesRead => 41
BytesRead => 41

---

Posted by Ilia Jerebtsov

I would guess that this is more specifically caused by KB3142037, which is a security update for MS16-065. The issues herein and a few workarounds are detailed at https://support.microsoft.com/en-us/kb/3155464 . There are registry keys that can be used to disable this "feature".

---

Posted by Microsoft:

Hi Nimbus.Hex, Yes Ilia is correct. This is a behavioral change done for security update for MS16-065. There are more details around the change available at https://support.microsoft.com/en-us/kb/3155464 . I resolving this as "By Design" Regards, Himadri

Answer 2

TCP does not allow the reader to determine what chunk sizes were sent. This information is not present on the write. Your application protocol must be able to deal with the fact that data can and will arrive in arbitrary chunks.