Socket "cutting" bytes in two packets

8

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

Whereinredisthesendingofbytesandinblueisthereceipt.Theconnectionbetweentheserverandtheclientisuniqueanddoesnotclose.Wheretherearetwobluearrows,thetwochangesaresentinred.

Everythingworkscorrectly.TheproblemarosewhenIwassendingalargernumberofbytesthanIwastesting,andIrealizedthattheSocketobject"cut" sending bytes to the server, separating it into 2 packets, was received in two parts.

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

The shipping 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 is executed 2 times, "cutting" the bytes in two packages):

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 any limitation on sending the amount of bytes? Should I perform queue management of packages and separate them by processes? Does it happen in any language?

    
asked by anonymous 16.08.2016 / 21:56

1 answer

11

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

How do I know the number of bytes to receive? This is the responsibility of the application. A common method is to place a fixed header at the beginning of each message, containing the following message size. The first step is for the application to receive this fixed header. Even at this step it is necessary to make repeated receptions. Upon receipt of this fixed header, the application knows the size of the following message, and therefore makes repeated receptions until it receives the total bytes of the message.

The need for this procedure stems from the fact that the TCP protocol transmits and receives bytes, not messages. So when an application does a 300-byte send there is no guarantee that on the other side this message will arrive in a single 300-byte chunk. Theoretically, the message can arrive in 3 pieces of 100 bytes, for example, this is allowed by the TCP protocol. With small messages usually each send corresponds a receive from the other side, but as the size of the messages increases, so does the likelihood that they will arrive in several pieces on the other side.

    
26.08.2016 / 16:18