[whatwg] WebSocket bufferedAmount includes overhead or not.

On 3/5/10 10:39 PM, Alexey Proskuryakov wrote:
>
> On 05.03.2010, at 10:27, Olli Pettay wrote:
>
>>> 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?
>
> I assume you are asking why JavaScript code needs this information for
> flow control.
>
> My recollection is that feature was added as a result of discussions
> about implementing flow control. How else are you supposed to know that
> you're streaming too fast without modifying the server? Since WebSockets
> is a match for TCP/IP, and the latter provides ways to adaptively change
> data rate, it's natural that one expects the same from WebSockets.

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.


>
>>> 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.
>
> This is something we agree about.
>
> I guess the root of our disagreement is in how one uses the API. I'm
> saying that the interesting question is how many bytes are buffered to
> be sent over the wire, so in order to keep the API usage the same we
> need to include protocol overhead in this number.

Or we need not to include protocol overhead in this number.
I'd like bufferedAmount to work the same way as .loaded and .total in
XHR+progress events; protocol specific headers aren't counted in.



>
>>> 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.
>
>
> 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.


-Olli





>
> - WBR, Alexey Proskuryakov
>
>

Received on Friday, 5 March 2010 12:56:48 UTC