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

[Joakim Erdfelt <[e-mail]>]

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