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

[Joakim Erdfelt <[e-mail]>]

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