I am working on a project that will utilize a client device on a bandwidth constrained network (cellular). I am not very familiar with socket communications, but I have figured out how to use Java as the server (from this tutorial), and Python is the language on the client.
I will be sending from a limited number of commands (less than 50) that say to “do command”, but I will also on occasion need to send a longer set that gives the client a future rule/condition. My thinking is to send a single byte for each of the commands, with one of the bytes signifying there is more to come. Would that be the proper way to do it, or should I continue writing to the socket output (I’m guessing it is utf-8, which is 3bytes/char if I’m not mistaken).
Thanks for the input,
James
There are two things you aught to keep in mind when trying to optimize network bandwidth.
The first is that you have to transfer about 40 bytes of overhead every time you want to talk to the peer. That’s just inherent in IP. Trying to get communication down to a single byte is often a false economy. What you should be doing is making the best of the round trip: combine the message with as much additional data as the peer might later need. To a limited extent, the Nagle algorithm already takes care of this for naive services, delaying the packet until the peer actually indicates that it’s ready for more data, and that’s usually sufficient.
The second is that, at typical MTU scales, it’s almost impossible to design an uncompressed, binary protocol that’s more space efficient than a simpler protocol that is tunneled using general purpose compression. There is no “packed binary http” because the gzipped ascii transfer encoding would beat it anyways. When bandwidth is a concern, always include compression. All that’s left is to make sure that your protocol is “easy” to compress.