[whatwg] WebSocket bufferedAmount includes overhead or not

[Boris Zbarsky]

On 3/25/10 5:50 PM, Ian Hickson wrote:
> What would the use case be for the second one? As far as I'm aware there's
> only one use case here: making it possible to saturate the network but not
> over-saturate it (i.e. to send data at the exact rate that the network can
> take it, without getting behind by sending more data than the network can
> handle, and without sending so little that the network is ever idle).

In practice, with real networks whose speed varies second-to-second, 
this is not really feasible.

And given the various levels of buffering in a typical network stack, 
I'm not quite sure how you see this working from the JS app's point of 
view.  Or is bufferedAmount reporting the amount of data that the server 
has not yet acknowledged receipt of or something?  The draft I'm looking 
at doesn't say anything like that, but maybe it's out of date?

That's not even worrying about issues like the network becoming "idle" 
while you're waiting for your process's time slice or whatnot.

> I don't see a problem with defining this. I agree that if we include
> overhead that it should be defined, but just saying that it's "the number
> of bytes to be sent that have not yet been sent to the network" does
> define it, as far as I can tell.

I'm still not quite sure why the "number of bytes" would include the 
websocket framing bytes but not the SSL bytes, the IP bytes, the 
ethernet frame, the Tor stuff when that's in use, etc.  What makes them 
special in terms of the protocol consumer needing to know about them (I 
realize they're special in that we're defining the web socket protocol)? 
  This isn't a rhetorical question, to be clear; I genuinely don't see a 
difference....

> Whether it includes the overhead or not is mostly academic for authors, I
> think. It's only relative numbers that actually matter.

Indeed.

> I think viewing the API spec and the protocol spec as separate is a
> mistake. They are one document:

Hold on.  There doesn't have to be a tight coupling between API and 
protocol here, as far as I can see.  The API just deals with messages. 
It seems pretty protocol-agnostic to me (and in particular, it seems to 
me like the protocol can evolve without changing the API).

Is there a good reason to actually couple them?

> It seems that the consensus is now leaning towards changing the spec again
> to include the overhead

It is?

> but I haven't changed it yet because I don't want
> to be flip-flopping back and forth -- if we change this, I don't want to
> change it back. I think the use cases I know of are addressed whether we
> include overhead or not

Seems that way to me.

Given that, do we in fact need byte-exact values here at all?  For 
example, could we make reporting it whichever way conforming as long as 
it satisfies certain criteria (monotonicity, etc)?

This is one of those cases (and I don't say this often!) when I actually 
happen to think that overspecifying (in either direction) precludes or 
over-complicates some perfectly valid and reasonable implementation 
strategies, and since in practice the values returned don't matter much 
I'd prefer to not thus overspecify.

-Boris