Re: [hybi] Is it important to know frame length at the start of frame? (was: Re: Discontinuation of mux ...)

[Takeshi Yoshino <[e-mail]>]

Thanks, Joakim. So you're still be able to do the fail-fast without
WebSocket frame length header if we adopt HEADERS+DATA+END_SEGMENT approach
but with WebSocket frame length header eliminated. HTTP/2.0 DATA frame has
its own payload length field though it's small compared to the range
WebSocket header can express.

Takeshi


On Wed, Feb 19, 2014 at 3:12 AM, Joakim Erdfelt <[e-mail]> wrote:

> Clicked too soon on that pseudo code.
> This is more clear. (i hope)
>
>    header = frame.parse_header(network_bytes)
>    if (header.size > system_memory_constraints) then
>       fail_protocol(1009)
>       // do not read payload
>       return
>    end
>    if (message.size + header.size > message.max_constraints) then
>       fail_protocol(1009)
>       // do not read payload
>       return
>    else
>       payload = frame.read_payload(network_bytes)
>       message.append(payload)
>    end
>    if (header.fin == true) then
>       message.deliver_to(local_endpoint)
>       // free up any message resources, reset message size to 0
>       message.reset
>    end
>
>
> --
> Joakim Erdfelt <[e-mail]>
> webtide.com <http://www.webtide.com/> - intalio.com/jetty
> Expert advice, services and support from from the Jetty & CometD experts
> eclipse.org/jetty - cometd.org
>
>
> On Tue, Feb 18, 2014 at 11:08 AM, Joakim Erdfelt <[e-mail]>wrote:
>
>> I'm not sure I was clear, as you seem to still have questions and are
>> hinting at alternatives.
>>
>> The most important thing I said:
>>    The size is important at the start of any payload about to be received.
>>
>> All other statements are based off of that.
>> The nuanced questions you are asking seems to indicate that you treat a
>> frame differently than a message is irrelevant.
>> If the frame happens to represent a complete message (eg:
>> opcode=(text|binary) + fin=true) vs being only 1 frame belonging to a
>> series of frames that make up a whole message makes no difference to the
>> statement.
>>
>> Since websocket is message based, not stream based, the above core
>> statement remains true.
>>
>> The fail-fast example applies for fragmented or whole messages.
>>
>>  some pseudo code:
>>
>>    header = frame.parse_header(network_bytes)
>>    if (header.size > system_memory_constraints) then
>>       fail_protocol(1009)
>>       return
>>    end
>>    // is message still being collected and not yet delivered to local
>> endpoint?
>>    if (message.delivered == false) then
>>       if (message.size + header.size > message.max_constraints) then
>>         fail_protocol(1009)
>>         return
>>       else
>>         payload = frame.read_payload(network_bytes)
>>         message.append(payload)
>>       end
>>    end
>>    if (header.fin == true) then
>>       message.deliver_to(local_endpoint)
>>       message.reset
>>    end
>>
>>
>>  --
>> Joakim Erdfelt <[e-mail]>
>> webtide.com <http://www.webtide.com/> - intalio.com/jetty
>> Expert advice, services and support from from the Jetty & CometD experts
>> eclipse.org/jetty - cometd.org
>>
>>
>> On Mon, Feb 17, 2014 at 10:37 PM, Takeshi Yoshino <[e-mail]>wrote:
>>
>>> So, to be clear, Joakim, you're not objecting to make it unable to know
>>> the size of each frame, but objecting to make it completely unable to know
>>> the size of big messages on receiving the head of it, right?
>>>
>>> Your use case (fail-fast) seems to require the sender to send messages
>>> unfragmented. So, it sounds like application (or kind of application)
>>> specific needs. You could do some application specific hack such as
>>> introducing "complete-message-size" header in the payload than depending on
>>> protocol level length header. If not, clients in the wild which are out of
>>> your control may do arbitrary fragmentation. FYI, Chromium's WebSocket
>>> stack is being refactored and after that it starts sending big messages as
>>> fragmented into small frames.
>>>
>>
>>
>