[whatwg] WebSocket bufferedAmount includes overhead or not.

[Olli Pettay]

On 3/4/10 12:17 PM, Fumitoshi Ukai (鵜飼文敏) wrote:
> On Thu, Mar 4, 2010 at 18:52, Olli Pettay <Olli.Pettay at helsinki.fi
> <mailto:Olli.Pettay at helsinki.fi>> wrote:
>
>     On 3/4/10 4:42 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
>
>         Hi,
>
>         I noticed that WebSocket spec updated to not inlcude framing
>         overhead in
>         bufferedAmount.
>
>     I asked that since from API point of view it doesn't make
>     much sense to have the frame bytes to be magically included in the
>     bufferedAmount.
>     What if we change the protocol and require different amount framing
>     bytes?
>     Also why to have framing bytes and not the bytes related to http
>     handling?
>
>
> I think bufferedAmount is a number of bytes are buffered to be sent on
> wire, so including frame byte is reasonable.
>
>
>     Also, XHR+progress events don't include http headers etc in the
>     .loaded or .total.
>
>
>
>         http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html
>         I tried to implement it in WebKit, but found it make hard to
>         implement
>         correctly.
>
>     Not hard at all in gecko's implementation (the patch is still
>     waiting for a review and will be possibly updated to include the latest
>     changes to the protocol before pushing to hg repo).
>
>
> I just look over https://bugzilla.mozilla.org/show_bug.cgi?id=472529
> It looks just updating bufferedAmount once a whole message has been
> sent, isn't it?
There might be still a bug there, but fortunately easy to fix one.
Thanks for noticing that.

> But I think user of the API might want to know progress while partial
> transfer of large messsage,
Indeed.


> so this implementation isn't so happy, IMO.
>
> Anyway, if this level of feedback is ok, it would be better to have
> onsent event listener to fire after each message has been sent.
That would make the JS code a bit uglier and I think JS needs to know if 
there are some pending messages.


-Olli


> Then, we don't need to poll bufferedAmount as do in example in WebSocket
> API draft.
> What do you think?
>
> --
> ukai
>
>
>
>
>         https://bugs.webkit.org/show_bug.cgi?id=35571
>         It's easy after WebSocket is closed (just add length of message),
>
>     right
>
>
>
>         but
>         while it's open, we'll manage buffer including frame bytes
>
>     In the patch for gecko there is a different buffer for each
>     "message", so it is easy to count how many frame bytes are in the
>     buffers.
>
>
>
>         and
>         underlying socket will write arbitrary length of the buffer (may
>         not be
>         on frame boundary)
>         To get bufferdAmount correctly without framing overhead, we need to
>         parse the buffer again.  It's not light operation and it's
>         challenge to
>         make it effective.
>         I think including frame overhead is much easier.
>
>
>
>         Could you revert it?
>
>     That would make the API worse, especially for web developers, IMO.
>     They shouldn't need to know about the protocol, they should just be
>     able to use the API and understand easily what bufferedAmount means.
>
>
>
>     br,
>
>
>     -Olli
>
>
>
>
>         --
>         Fumitoshi Ukai
>
>
>