[whatwg] WebSocket bufferedAmount includes overhead or not.

[Olli Pettay]

On 3/5/10 7:54 PM, Alexey Proskuryakov wrote:
>
> On 04.03.2010, at 1:52, Olli Pettay wrote:
>
>>> 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?
>
> I was going to mention this as the primary reason why frame bytes should
> be included. JavaScript code needs this information for flow control,
Why?

> and it's raw bytes that are sent over the tubes, not original message
> strings.
Right. But this is about the API. I assume the underlying protocol may
change or the API can eventually support different kinds of protocols
(some may use UPD, some TCP, some send text, some binary).
The API usage should be still the same, if possible.


>
> Also, I think it's a layering violation.
I don't understand what you mean with this.
bufferedAmount is about the API.

> In WebKit, we'd have to queue
> unsent messages separately just to implement this quirk (see
> https://bugs.webkit.org/attachment.cgi?id=50093 for a proof of concept).
> It becomes very difficult to implement we decide to add size of data
> that an underlying network library buffers internally - which I think
> would be a reasonable thing to do.
I don't see why that would be difficult. If you know you have just 
written x bytes to the whatever network method, you know how many bytes
of those were frame markers.


-Olli

>
>> Also why to have framing bytes and not the bytes related to http
>> handling?
>
>
> Nothing would change for engines or JS code if HTTP headers were counted
> in bufferedAmount. Since they are only sent when establishing a
> connection, adding a small constant at the beginning will make no
> difference to flow control. And the constant is going to be zero in
> practice, because the data will immediately go where we can't see it.
>
> - WBR, Alexey Proskuryakov
>
>