Background discussion: three layers of framing

[wenbozhu]

1. Multiplexing-level framing introduced by the "transport layer", i.e. http/2 etc
2. Message level framing, i.e. the delivery semantics
3. WS introduced fragmentation to support length-prefixed framing of Review of WiSH #2, for large messages whose sizes are unknown when messages are being generated in the runtime
   Review of WiSH #2 is always needed.

Mixing #1 and #2 will cause HOL blocking (at the stream level).

Not sure about how much value #3 adds in real world. However, even we can limit the max message size (e.g. to 1MB), there is still an optimization opportunity involved to allow data to be flushed to the network in real-time. Q: has there been any API (in JS or other languages) that supports "streamed message" over WS?

[tyoshino]

Q: has there been any API (in JS or other languages) that supports "streamed message" over WS?

Never on the web platform though there're some plans proposed.

Of course, applications may just implement their own fragmentation mechanism by themselves. Possible real benefit of doing fragmentation at the protocol level I can come up with are:

• (a) applications can skip implementing fragmentation
• (b) applications can instruct the protocol level to store received data in a contiguous memory

But (b) makes sense only if the framework/language on which applications are developed has some restriction. E.g. on the web platform, currently received bytes must be passed to the application as an ArrayBuffer. If the application wants to pass received bytes of a message (semantics at the application level) delivered as fragmented into multiple ArrayBuffers to someone else as a contiguous memory, it needs to allocate such memory by itself and copy bytes into it.

Once the web platform evolves e.g. by using the BYOB readable stream to be able to read(2) directly into an ArrayBuffer provided by the application, this becomes useless.

[wenbozhu]

As long as message fragmentation (intra-message) doesn't incur any runtime overhead as an opt-in feature, I guess it's OK to keep. I did see applications asking for arbitrarily sized messages to be sent over RPC. Since websocket delivers messages as bytes, a streamed byte-buffer is relatively easy to support (if not for JS/web) compared to atomically delivered byte-buffers.

[tyoshino]

As long as message fragmentation (intra-message) doesn't incur any runtime overhead as an opt-in feature, I guess it's OK to keep.

I see. For the WebSocket protocol, all the user-agents had to implement it, but for WiSH users would be able to have control over enable/disable the feature. OK.

So, here's a TODO of marking the feature as optional on the spec.

atomically delivered byte-buffers

Sorry, could you elaborate this?

[wenbozhu]

I.e. without fragmentation, messages (as byte-arrays) will have to be generated/delivered atomically.