Socket "cutting" bytes into two packets

Question

I am developing a Socket communication of my program with the server. This server is responsible for bridging between my program and the users that are connected to it, that is, the user when executing a change in the "program A", the user of the "program B" will receive this change and apply the changes automatically. The number of connected programs is undefined. Below is an example diagram:

Where in red is the sending of bytes and in blue is the receiving. The connection between the server and the client is unique and does not close. Where there are two receiving arrows in blue, it means the two changes sent in red.

Everything works correctly. The problem arose when I went to send a larger amount of bytes than I was testing and realized that the Socket object "chopped" the sending of bytes to the server, separating it into 2 packages, which, consequently, was received in two parts.

It turns out that these bytes are part of a single JSON object, and upon receiving the packages, the event ProgressEvent.SOCKET_DATA is dispatched twice, with the first and second part of the JSON object.

The sending code is:

function enviar(json:Object):void {
    var str:String = JSON.stringify(json); // transformo json em string
    socket.writeUTFBytes(str); // escrevo a string no objeto socket
    socket.flush(); // faço o envio
}

On receiving (This function runs 2 times, "cutting" bytes into two packets):

function receber(e:ProgressEvent.SOCKET_DATA):void {
    var str:String = socket.readUTFBytes(socket.bytesAvailable); // transformo os bytes em string
    var json:Object = JSON.parse(str);
}

Is there some kind of byte quantity submission limitation? Should I manage packet queues and sort by process? It happens in any language?

Answer 1

The standard (and necessary!) procedure when programming in sockets is to repeat the reception until the expected number of bytes has been received.

How do you know the number of bytes to be received ? This is the responsibility of the application. A common method is to place a fixed header (header) at the beginning of each message, containing the size of the following message. The first step is the application to receive this fixed header. Even in this step it is necessary to eventually make repeated receptions. After receiving this fixed header, the application knows the size of the following message, and therefore makes repeated receptions until receiving the total bytes of the message.

The need for this procedure comes from the fact that the TCP protocol transmits and receives bytes, not messages. Thus, when an application sends 300 bytes there is no guarantee that on the other side this message will arrive in a single piece of 300 bytes. Theoretically, the message can reach 3 pieces of 100 bytes, for example, this is allowed by the TCP protocol. With small messages usually each send corresponds to a receive on the other side, but as the size of the messages increases the probability that they reach several pieces on the other side.