# In Socket.IO, should I use JSON for communication between server and client?

I'm building an MMO with Socket.IO and Node.js. It works quite fast (though I don't have 1000 players yet) but my feeling is that it's not very optimized. JSON is super cool and easy to use within Socket.IO but when I see a broadcast from the server (1 player connected):

   debug - websocket writing 5:::{"name":"snapshot","args":[{"players":[{"id":1,
"tx":-5.62,"y":23.74,"tz":-5.64,"tRotY":0,"tSpeed":0}]}]}


I take it all the variable name are broadcast as well. Isn't that a huge overhead? Wouldn't it be better if I glued all data together using delimiters like this?

1;-5.62;23.74;-5.64;0;0


The disadvantage here would be that I have to split the string each time I receive it. But isn't that much better for latency?

• As you can see in your example, change is not so drastic and whats more importnant you can change your Send method to do this automaticaly - when this will become bottleneck. (Or you can just compress it). Readability will be much more importnant for you in this phase of project. – Kikaimaru May 3 '12 at 10:29

I take it all the variable name are broadcast as well. Isn't that a huge overhead?

That's the case, and yes that's quite an overhead.

Wouldn't it be better if I glued all data together using delimiters like this (...)? The disadvantage here would be that I have to split the string each time I receive it. But isn't that much better for latency?

That would be better for latency, but yes, you lose the handiness of JSON.

A middle ground solution:

• Use short variable names, "n" for "names", "a" for "args", etc. Less readable but saves some precious bytes. In the same spirit, try to avoid strings and use enum-like integers wherever possible.
• Compress your messages, for instance using BiSON.js.

Sure it is an overhead, but if your packets generally ain't much larger than the example you give it is not much overhead, pretty insignificant relative to general overhead of sending a package.

Of course a denser format is a small performance improvement, and it should be considered. At the early development however I'd stick to something like JSON for easy debugging.