Getting three frames instead of two between client/server

[Jared-Sprague]

The following code results in a mysterious third frame:
451-["clientMsg",{"_placeholder":true,"num":0}]

Cient

function sendMessage() {
    var bufArr = new ArrayBuffer(4);
    var bufView = new Uint8Array(bufArr);
    bufView[0]=6;
    bufView[1]=7;
    bufView[2]=8;
    bufView[3]=9;

    // send binary message to server
    socket.emit('serverMsg', bufArr);
}
sendMessage();

Server

    socket.on('serverMsg', function (bufArr) {
        var ba = new ArrayBuffer(4);
        var bv = new Uint8Array(ba);
        bv[0]=10;
        bv[1]=11;
        bv[2]=12;
        bv[3]=13;

        var bufView = new Uint8Array(bufArr);
        console.log("Data: ", bufView[0], bufView[1], bufView[2], bufView[3]);

        // Send message back to client
        socket.emit("clientMsg", ba);
    });

Client

    socket.on('clientMsg', function (bufArr) {
        var bufView = new Uint8Array(bufArr);
        console.log("Data: ", bufView[0], bufView[1], bufView[2], bufView[3])
    });

The above code is resulting in THREE frames I would expect only TWO frames, one from the client to the server and one from the server to the client. Can anyone explain what this third frame is, and how to get rid of it? See the blow screenshot:

[WesThorburn]

I know it has been nearly 9 months since you posted this, but did you solve your problem? I also have a seemingly unexplained third frame appearing with almost identical content to yours. And I'm trying to work out how to get rid of it.

[Jared-Sprague]

I did figure this out for my case and it's not a bug, it's how socket.io is designed to match a binary frame to a message name. When you emit a binary type message with a string name, socket.io sends two frames, one for the string name and one for the binary message. That's how it knows which handler to use on the server. It's a convenience of being able to name a binary message with a string, at the cost of an extra frame.

For us this was to much, so we opted to go a pure websocket route and we use the first byte of a binary message as an "op code" to route the message to the appropriate handler on the server. Then we only have to send on frame per binary message. One library that helps a lot with this is SchemaPack: /~https://github.com/phretaddin/schemapack

[WesThorburn]

I've spent the last day or so exploring schemapack and integrating it into my project. It's a terrific library, and it's working well. I just wanted to say thanks Jared-Sprague for the recommendation, this will save us a lot of bandwidth.

[darrachequesne]

For future reference, since version 2.0.0 you can now provide your own parser:

Please take a look at:

• Each binary packet results in two packets, and two websocket frames socket.io-parser#61
• /~https://github.com/socketio/socket.io/tree/master/examples/custom-parsers