Re: Proposal for API for Data

On Apr 10, 2012, at 10: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.
> 
> I agree it would be _useful_, at least for reliable streams. I don't know how you'd define this semantic for unreliable streams.
Well, the streams are partially reliable (the supported policies still need to be specified
(like limiting the lifetime, or limiting the number of retransmissions), but SCTP can report
how many bytes are buffered for a particular stream (not that this statistic is implemented
right now, but it can be added).
> 
>> 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.
> 
>>> protocol error"). So if we want this particular close() API, then we
>>> have some more protocol work to do.
>> 
>> Correct, though we could define that we basically ignore codes/reasons
>> and just provide a generic on at the other end. Or add a close message
>> sent reliably before reset to provide them. If we decide to extend
>> WebSocket this is doable.
> 
> I agree, all of this is doable. I'm just trying to point out what needs to be done to go down this path. With the "reliable close message before reset" approach, you'll also need to define what happens if you get a close message but no reset, or a reset but no close message.
I guess we will need an error message anyway...

Best regards
Michael
> 
>> Or you define that a send() is never too large for the "current buffer"
>> in WebRTC.
> 
> I would have said we're likely going to have to define _some_ limit, just like WebSockets did, but it looks like the WebSockets limit is now 2 GB instead of 16 MB (see https://bugzilla.mozilla.org/show_bug.cgi?id=711205). So apparently not.
> 
>> BTW, the current WebSockets impl in Firefox appears to return
>> ERROR_FILE_TOO_BIG, but nothing more. (However, that's just from code
>> inspection.)
> 
> Yeah, see https://bugzilla.mozilla.org/show_bug.cgi?id=712173
> 
>

Received on Thursday, 12 April 2012 09:58:08 UTC