Re: [hybi] Framing take IV

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
>    I'd like to refocus on what I believe we do have near-consensus on, so
>    that we don't lose progress while we debate other possible features.
>    I think that we have reasonable consensus on something like:
> 
>    +--------------------------------------------------+
>    | frag(1) |unused(3) | opcode(4) |   Length(16)    |
>    +--------------------------------------------------+
>    |                       Data                       |
>    +--------------------------------------------------+

Two questions:

   1. Are intermediaries allowed to move the fragment
      boundaries to optimise their delivery?

         1a. .... "add fragment boundaries"
         1b. .... "remove fragment boundaries"

   2. Are intermediaries allowed to delay delivery of incomplete
      messages by an arbitrarily long time, including forever?

Related to 2, the JS API always delays delivery of incomplete received
messages, and in a sense the JS API is acting as an intermediary
between the server and client application.  So it should cause no harm
for other intermediaries to do it, when the receiver is a browser
providing the current JS API.  But other clients may be harmed by such
delays, or not, depending on what they expect.

Also I'd like to remind you of a past discussion where we learned that
carrying general byte stream protocols over WebSocket is slightly more
efficient if the flag meaning "tell intermediary to forward" is
independent of the flag "this boundary is adjustable".

It's tempting to specify "intermediaries shall forward all bytes they
receive eagerly, without interpretation", but that is (a) not going to
happen as firewalls will inevitably filter some WebSocket applications
so we might as well suggest what they must do right, and (b) not ideal
for TCP latency, especially where MTUs differ on either side, although
it's not too bad, and (c) a multiplexing/demultiplexing WebSocket
proxy cannot do this.

I've no issue with eager byte forwarding being the default behaviour
expected of intermediaries if nothing else is negotiated, and it makes
considerable sense to me for the questions to be deferred over to
the multiplexing-and-intermediaries discussion.

-- Jamie