Re: Proposal for API for Data

On Apr 10, 2012, at 10:56 PM, Randell Jesup wrote:

> 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.
Yes, that makes sense.

Best regards
Michael
> 
>>> 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 Thursday, 12 April 2012 09:58:54 UTC