[whatwg] WebSocket bufferedAmount includes overhead or not

[Jonas Sicking]

On Thu, Apr 8, 2010 at 5:22 AM, Niklas Beischer <no at opera.com> wrote:
> On Fri, 02 Apr 2010 20:43:57 +0300, Jonas Sicking <jonas at sicking.cc> wrote:
>
>> On Thu, Apr 1, 2010 at 8:15 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>>
>>> On 3/31/10 6:57 PM, Jonas Sicking wrote:
>>>>
>>>> I would expect that send() is allowed to start streaming data over the
>>>> network as soon as it can, but only update bufferedAmount from the
>>>> event loop.
>>>
>>> Maybe I'm not being clear.  Let's say bufferedAmount were to reflect the
>>> number of UTF-8-encoded bytes to be sent, for the sake of argument.
>>>
>>> I wait until bufferedAmount is 0, then call send("My text").
>>>
>>> What are possible values of bufferedAmount if I examine it right after
>>> the send() call?  Is 0 a valid possible value?  What about 1?  2? 3? 4? 5?
>>> 6? 7?
>>>
>>> Presumably the value will be somewhere in the integer range [0,7], right?
>>> Or will it always be 7 after that call in that situation?
>>
>> In order to archive maximum interoperability and predictability I
>> think it should always be 7. So bufferedAmount is always adjusted
>> synchronously upwards by the length of the sent message by send(),
>
> I think it should be pointed out that, since we in the current suggestion
> expose the serialization of the protocol in bufferedAmount, the length of
> the message passed in the call to send() may or may not differ from the
> value of bufferedAmount. Depending on whether or not you use non ASCII
> characters the bufferedAmount increase may be larger than the length of the
> original message string.

Indeed. But it's consistent in that every time you call send() with a
specific value .bufferedAmount increases by the same amount. It does
not depend on if the network thread is ready to receive data etc.

>> and always adjusted downwards from events posted to the main event loop.
>
> The event posting I completely agree with (thanks Jonas for teaching me a
> little something about EcmaScript execution :-) ). But for WebWorkers you
> would only need to notify the event loop connected to the WebWorker in
> question, right?

The event loop on which the WebWorker API is running, yes. (Which is
likely a different event loop than the event loop doing the actual
network communication).

/ Jonas