Re: [hybi] Frame size

Greg Wilkins wrote:
> In fact, I would argue for a 16k max frame size with 2
> bits given over to help with partitioning and aggregation,
> but with no requirement that an endpoint can handle
> aggregation and partitioning (unless they indicate they
> can in the handshake).
>   
16k is fine, but why are two bits needed instead of one? One bit is 
needed for final vs non-final frame in a message, but I don't see how 
the second bit would be used. (Although, hmm, are you thinking in a 
multiplexing context where the second bit could mean "use the same 
channel"? Or messaging "use the same sender/recipient"? That would be a 
useful capability.)

I'd think basic chunking would be a requirement like HTTP/1.1, not a 
negotiated capability, to support messages over 16k and also to the 
reduce the round trip latency as discussed in the other thread.

For example, a high performance client might pipeline the first request 
frame(s) with the HTTP header since, in reality, it expects the server 
to understand the requested protocol, but it would need some 
fundamental, non-negotiated capabilities like fragmenting for the 
pipelining to work.

-- Scott
> cheers
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
>   