Bayeux Protocol 2.0

[sbordet]

Now that binary JavaScript is real, it is time to review the Bayeux Protocol and make it binary.

Goals:

• Reduced overhead for meta messages.
  Messages such as those on /meta/connect channels should amount to just few bytes, therefore using less bandwidth and be faster to parse.
• Binary message.data payloads, but still support JSON payloads (Content-Type)
• Optional payload gzip compression (Content-Encoding)

[sbordet]

@gregw more ideas?

[gregw]

We need to do some experiments first. Is there really a difference between:

1. javascript map -> json text -> gzipped http message -> json text -> java map
2. javascript map -> binary with gzip -> http message -> ungzipped binary -> java map

Json is very compressible and json parsing is pretty fast and I expect much of the time is actually spent visiting/contructing the map objects being sent.
We'd probably get almost as much benefit by just defining short aliases for our common json names: "channel" -> "C"; "clientId" -> "I"; "version" -> "V", although with gzip such common names are probably not that much of a hassle either.

So I'd like to see some JMH benchmarks of the server-side differences for some binary messages before committing to reworking the clients.

[sbordet]

@gregw agreed. Although the main reason is binary payloads such as images or video/audio.

Right now we can Z85 encode/decode with some overhead in size with respect to the binary size (Z85 is similar to Base64 just slightly better).

[gregw]

Binary payloads are not that common and it would be easy enough to come up with a solution that you just push a URI to fetch the value and if latency is an issue then use http2 to push the binary so it arrives with the message. I think we'd need to see general benefits of binary message format before making the change.