[whatwg] WebSocket bufferedAmount includes overhead or not

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  
question, right?


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

BR,
  /niklas


-- 
Niklas Beischer
Software Developer
Opera Software

Received on Thursday, 8 April 2010 05:22:29 UTC