[whatwg] WebSocket bufferedAmount includes overhead or not
no at opera.com
Thu Apr 8 05:22:29 PDT 2010
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.
> 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
> Though it's possible that this is overengineering given how people are
> likely to use bufferedAmount. Interested to hear opinions.
Just to be clear, I definitely prefer the current spec over completely
hiding the serialization from the API. Though I wouldn't mind if we
specified bufferedAmount to include protocol overhead and have it
represent exactly the amount of bytes waiting to be pushed to the network.
More information about the whatwg