Re: [hybi] CML

["Brian Smith" <[e-mail]>]

The protocol should be designed to be optimized for any particular web browser memory allocation strategy. There is so many layers and each is potentially going to do its own fragmenting/coalescing: at the TCP/IP level, in the IP(v6) compression layer, in the operating system network buffer manager, in the operating system’s VMM, in the TLS stack (including an extra layer for compression), in the browser’s networking code (including possibly an extra layer for compression again), in the browser’s JavaScript buffer/string handling, etc. As long as the protocol is not designed maliciously, it should be straightforward to find a memory allocation strategy that adds virtually no overhead.

 

Plus, like somebody else pointed out, a lot of the buffer management stuff can be abstracted out at the application API level like boost::buffer_iterator and the old SGI Rope class do for C++. 

 

I think some basic problems have to be solved before it makes sense to try to resolve issues CML. For example, if WebSockets is to be a TLS-only protocol, then there are no intermediaries fragmenting messages according to their own whims. In the case of a multi-server configuration, the way messages are transferred between the servers is an implementation detail; the wire format used for framing between those servers could be completely different than the standard WebSockets wire format (e.g. just “real” TCP/IP), and even the format of the application data could be different (e.g. using efficient binary encodings instead of data that was originally sent JSON-encoded). It isn’t (necessarily) WebSockets all the way down.

 

Also, I joined the list late. Was there already a discussion about the merits of optimizing framing below the TCP/IP MTU? In particular, what is the motivation for optimizing the overhead of a 128 byte message when even a 512-byte message will still only require a single packet? If the idea is that many frames could be stuffed into a single TCP/IP packet when multiplexing is used, then it is probably better to instead directly address the overhead of that multiplexing. Perhaps techniques similar to the ones used in modern SQL databases (e.g. Oracle) for compression of data within a given block could be used: create a frame header format that can describe multiple frames much more compactly than it can describe frames individually, and send that “multi-header” ahead of all the frames it describes. But, such complexity should first have a clear concrete motivation.

 

Regards,

Brian

 

 

The browser now receives this first frame.  Ultimately, it wants to pass an object containing the message to JS code, and it needs to allocate a buffer to receive the data.  How big does it allocate?  Without CML, it doesn't know and must guess.  Note that if there were no intermediary introducing fragmentation, it would have had the buffer length required after reading the header of the first frame.  Note that it is not the application on the receiving end that consumes the CML, but rather then WS framing level, which is why the CML is included in the framing rather than the application data.