Friday, October 7, 2011


I tried to implement a binary protocol the whole evening and it turned out to be a lot harder than expected. The way Java and the Metro API handle binary TCP streams is very different, resulting in very convoluted serialization and deserialization of messages.

I am currently considering to go back to string streams and use JSON to encode my network messages. This might mean some more network traffic though, especially for number-heavy messages.

When I want to tell the client that an object moved to position r:l I could do this with:
2 Bytes "this is a movement package"
4 Bytes beingID
8 Bytes position (2*float)
= 14 Byte.

In JSON this would look like this: {"type":"move", "id":1234,"r":12.000004,"l":15.9999998} which are 60 bytes in ASCII.

This might look like a large difference (1:4), but I must not forget that there is also TCP/IP overhead. When I design the protocol efficiently and send as few messages as possible, most messages will be in a single TCP/IP packet, which has an IP header of 20 bytes and a TCP header of 20 bytes. With this additional protocol overhead, the real comparison is 54 to 100 bytes - less than double.

I could reduce protocol overhead by using UDP instead of TCP which has just 8 byte of protocol overhead and has also better real-time capabilities, but with UDP I have to worry about messages disappearing without a trace or arriving in a different order than they were sent. Dealing with those situations would require additional information to be transfered which would quickly eat up the saved bandwidth. 

On the other hand using JSON has a lot of advantages like making it easier to keep the protocol backward-compatible, not having to worry about different data representations and much, much easier parsing on the client side.

No comments:

Post a Comment