Re: [hybi] Frame size

[Jamie Lokier <[e-mail]>]

Thomson, Martin wrote:
> Jamie writes:
> > Alas, there are very good reasons to send non-final frames that aren't
> > the full length.
> 
> From my perspective, the only very good reason you stop sending one thing is because you want to send something else (i.e. multiplexing).
> 
[...]
>
> Addressing shortcomings in the abstraction (graceful close, etc...)
> is another thing.  It's reasonable to say that the TCP abstraction
> does not provide graceful close, so providing it at a higher layer is
> OK.

If you want to send a graceful close response when you have only sent
half a message, you cannot do it unless the half message was sent as
a non-final, non-full-length frame.

That's why it's useful.

It's not because you want to send something else _now_, it's so you
have the _possibility_ to send something else later.  Because you
can't abort a half-sent frame later.  (You would need TCP urgent data
or something, and that's not feasible to use.)

> Aligning with segments isn't a good argument for me.  How the WS
> layer is aware of layers below it and the way that it interacts with
> those is orthogonal to frame size.  TCP provides an abstraction of a
> stream.  If a particular implementation wants to optimize, it can,
> but that shouldn't affect layers above those key abstraction points.

Feel free to ignore segment alignment.  It's just an implementation
tunable, not a requirement and doesn't need to appear in any
specification.

The frame size is part of the WS transport layer, and is closely
related to buffering and forwarding decisions.  (Note that eager
sending is sub-optimal for latency, in case you're curious.)

Those decisions have little or nothing to do with TCP segments, but
the timing of forwarding decisions cause certain kinds of alignment
anyway.  The same outcome occurs with other types of pipe abstraction.

You said "it shouldn't affect layers above those key abstraction
points".  Note that frame size is *not* present in the layer above WS
buffering and forwarding decisions.  (If it is, it is misdesigned.)

You might be thinking of the message size, which is.

-- Jamie