Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
4  
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
    
Very good point you're making. I admit I'm thinking a bit early about this. –  Nick May 3 '12 at 11:31
add comment

2 Answers

up vote 4 down vote accepted

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.
share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.