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

[Zhong Yu <[e-mail]>]

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

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
>