Re: Proposal for API for Data

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.

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

> 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 Tuesday, 10 April 2012 20:46:25 UTC