[whatwg] WebSocket bufferedAmount includes overhead or not.

[Olli Pettay]

On 3/5/10 11:13 PM, Alexey Proskuryakov wrote:
>
> On 05.03.2010, at 12:56, Olli Pettay wrote:
>
>> And you're saying that javascript really needs to know about the
>> frame boundary bytes to detect if it is streaming too fast.
>> Doesn't sound likely to me.
>
> OK
>
>>> That's true, but I don't know how many of these have already been sent
>>> unless I perform lots of additional bookkeeping.
>> "lots"
>>
>>> Consider sending "data"
>>> message three times in a row:
>>>
>>> \x00data\xFF\x00data\xFF\x00data\xFF
>>>
>>> If we are to exclude protocol overhead in bufferedAmount, and we know
>>> that there are 8 bytes still queued (a\xFF\x00data\xFF), and we know
>>> that there were three frames sent (with an overhead of 6 bytes) how
>>> would we know that the answer is 5?
>>
>> You could for example have a circular list for the frame boundary byte
>> indexes and when something is removed from the queue, you just update
>> the pointer which points to the first frame boundary byte index in the
>> queue. Then if the circular list is implemented in a reasonable way,
>> counting all the frame boundary bytes in the queue is just one
>> subtraction.
>
>
> Yes, that's lots of work
lots? I wouldn't call that "lots".


> for something no one should care about, as you
> implied above.
 From API perspective I do care. Web developers shouldn't need to know
about the protocol, yet (s)he should be able to understand what
bufferedAmount means.


-Olli

> And that's work that makes the results slightly
> misleading, even if that's so slightly that it's not important in practice.
>
> Remembering frame offsets even after data has been serialized to a
> stream is an unusual requirement for networking code.
>
> - WBR, Alexey Proskuryakov
>
>