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

[Tobias Oberstein <[e-mail]>]

> Why does it matter if a frame (of unknown size) is composed of fragments
> (of known sizes), w.r.t. memory management?

I agree with Joakim that frame size length can be important for memory management.

It is also important to be able to fragment a message, for reasons of

- control frame injection (ordered close)
- application data independent keep alive (ping/pong)
- message interleaving

/Tobias

> 
> On Wed, Feb 12, 2014 at 7:49 AM, Joakim Erdfelt <[e-mail]>
> wrote:
> > For various application level APIs that depend on delivery of complete
> > messages, the need to know the frame level size at the start of the
> > frame becomes important for memory management.  Eclipse Jetty uses
> > this information to implement Java's javax.websocket API for limiting
> > memory use, along with lower level (WS+HTTP/1.1) protocol validation
> (close code 1009).
> >
> > Since this group has a history (now) of making protocol decisions
> > based on existing public APIs (re Javascript WebSocket), I would
> > entreat the members here to think about the other public, industry
> > standard, non-javascript, WebSocket APIs already widely deployed.
> >
> >
> > --
> > Joakim Erdfelt <[e-mail]>
> > webtide.com - intalio.com/jetty
> > Expert advice, services and support from from the Jetty & CometD
> > experts eclipse.org/jetty - cometd.org
> >
> >
> > On Wed, Feb 12, 2014 at 6:34 AM, Micheil Smith
> > <[e-mail]>
> > wrote:
> >>
> >> As far as I recall, this was also to enable more efficient reading
> >> and error checking.
> >> Prefixing with the frame size means you don't need to scan every byte
> >> being received in order to find an end of frame delimiter.
> >>
> >> This is a particularly useful thing when doing something like
> >> upstreaming on a websocket server, where all you care about is the
> >> very start of the message, and the length, such that you can then
> >> just read() N bytes which is the size of your frame and just write()
> >> directly.
> >>
> >> In other words, I agree on your reply Takeshi.
> >>
> >> - Micheil
> >>
> >> On 7 Feb 2014, at 7:30 am, Takeshi Yoshino <[e-mail]>
> wrote:
> >>
> >> > I remember that in early days of the standardization, somebody was
> >> > proposing (*) that we should have a message length field in the
> >> > first fragment to allow for allocating buffer for full message at the
> beginning.
> >> >
> >> > On Thu, Jan 16, 2014 at 3:27 PM, "Martin J. Dürst"
> >> > <[e-mail]> wrote:
> >> > On 2014/01/16 15:05, Yutaka Hirano wrote:
> >> > Hi Joakim,
> >> >
> >> > Thanks for the comment.
> >> >
> >> > Knowing the size of a frame at the start of the frame, traditional
> >> > websocket behavior, is desired, as it allows us to fast fail for
> >> > the
> >> > 1009
> >> > (message too big) use case.
> >> >
> >> > Do you know how effective it is?
> >> >
> >> > Having no prior knowledge of frame size is undesirable to us.
> >> >
> >> > On the other hand, the frame sender have more freedom because they
> >> > don't have to know the size of the frame in front.
> >> >
> >> > My understanding of why messages are split into frames was that
> >> > this would allow to start a message without knowing its length. But
> >> > if you don't know the size of a frame before sending it, then the
> >> > right solution is to make it smaller. Frames are just arbitrary pieces of a
> message.
> >> >
> >> > We should be clear if we want to make it able to
> >> > (a) know the length of WebSocket frame on receiving the header of
> >> > each fragment
> >> > (b) know the length of WebSocket message on receiving the first
> >> > fragment
> >> >
> >> > As the proposal (*) has been rejected and not in the RFC6455
> >> > header, (b) is not true even in RFC6455. What Joakim said should be
> >> > to keep (a) which is true now in RFC6455.
> >> >
> >> > But if a message is fragmented into smaller frames, we cannot
> >> > reject (and send 1009) the message on receiving the first frame.
> >> > "Whether we can fast-reject a big message on receiving some
> >> > non-final frame" depends on how the peer fragments a message.
> >> >
> >> > In some plans discussed in the main thread, it's planned to drop
> >> > frame length info for efficiency. But something else such as the
> >> > length field of
> >> > HTTP/2.0 DATA frame tells how much data the fragment (when multiple
> >> > DATAs convey a WebSocket frame, each DATA would be called
> fragments
> >> > of a frame) contains. So, we won't be able to know the length of
> >> > fragments (original/encapsulated WebSocket frames) on receiving
> >> > each of them, but still be able to know the length of sub-fragments
> >> > (e.g. HTTP/2.0 data frames).
> >> >
> >> > I think this change is acceptable and shouldn't be considered as
> >> > breaking of RFC6455 semantics. Even in the mux extension I was
> >> > editing
> >> > (http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-
> >> > 11), I made the same change. The length of the encapsulated frame
> >> > is unknown until receiving all the fragments of the encapsulating
> message. No one was objecting to that when we were discussing the spec,
> IIRC.
> >> >
> >> > _______________________________________________
> >> > hybi mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/hybi
> >>
> >> _______________________________________________
> >> hybi mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/hybi
> >
> >
> >
> > _______________________________________________
> > hybi mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hybi
> >
> 
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi