Re: Proposal for API for Data

On 4/10/2012 4:45 PM, Timothy B. Terriberry wrote:
> Randell Jesup wrote:
>> It's actually the amount of data that has not been ACKed at the
>> WebSocket protocol level by the other side, so it does give an idea of
>> how badly you've overrun the connection. Basically it's sent_data -
>> acked_data.
>
> I don't think this is true. It's certainly not implemented this way in
> gecko (see
> http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/websocket/WebSocketChannel.cpp#2707
> through 2744). Nothing in the WebSocket protocol acknowledges message
> delivery (at least nothing I can find in RFC 6455... please feel free to
> point me at what I missed). There are ACKs at the TCP layer, but that
> information is not normally exposed to userspace.

In content/base/src/nsWebSocket.cpp, lines 1232 (return amount), 1322 
(amount += len), and line 370 (amount -= acked size).

> I agree it would be _useful_, at least for reliable streams. I don't
> know how you'd define this semantic for unreliable streams.

I wouldn't define it this way; I'd define it as data currently buffered 
in libsctp and thus available for transmission (or re-transmission 
because it's un-acked reliable (or partly-reliable) data).  I would not 
attempt to include anything in layers below sctp.

>> We don't ack messages at the user protocol level; our definition had
>> been planned to be a measure of the amount of data queued for
>> transmission by the stack (depending on what the stack makes easy to
>> get). We hadn't put a precise definition on it yet.
>
> It may be worth thinking about "what's useful for an application
> developer", rather than "what the stack makes easy to get". Hopefully
> those are the same, but of course that's not guaranteed.

Agreed, though I care about both.  And bufferedAmount typically is 
actually just a crude indicator of "am I getting ahead of the channel" 
so the application can adapt and avoid inducing delays.  Actually far 
more useful than a single DataChannel's queued amount is the total 
queued across all channels (and that might be easier to get).  But that 
would be a very different api than WebSockets.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 10 April 2012 21:00:58 UTC