Re: [hybi] Framing take IV

[Greg Wilkins <[e-mail]>]

On 4 August 2010 12:50, Jamie Lokier <[e-mail]> wrote:

> 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"
>


In an earlier message I proposed that fragmentation should not change the
semantics of a message and that intermediaries should be free to fragment
and/or aggregate.



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

This has not been discussed, other than the discussion that we had many
months ago about a must-flush bit, that you mention below.



> 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.
>

I think that the semantic difference between have a stream of messages and a
stream of fragments is pretty fine, so if somebody really wanted to have
partial content that was forwarded eagerly, then they can have a message
content type that is a partial content.

So I  would be happy to say that intermediaries SHOULD eagerly forward
fragment frames and MUST forward end of message frames.

cheers