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

[Joakim Erdfelt <[e-mail]>]

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 <http://www.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
>