Re: Data API Proposal aligned to WebSocket

On 2/24/2012 11:02 AM, Adam Bergkvist wrote:
> On 02/24/2012 03:00 PM, Randell Jesup wrote:
>> As you mention, if you allow multiple channels with the same label, then
>> the label glare case goes away. You don't *have* to require in-order
>> creation; you'd merely need to state that ordering of creates from side
>> 1 doesn't have to match the ordering on the receive side (and that's
>> only to deal with the case of creating two channels with the same label
>> from the same side at virtually the same time - extreme edge case). I
>> think I prefer this solution, and it leads to a simpler wire protocol
>> and implementation. In some rare-ish cases, applications might need
>> additional logic, but few would need it.
>
> I prefer this solution as well since it removes a way for a channel
> setup to fail. This also makes the API more consistent - a successful
> channel creation on one side will always result in a "datachannel" event
> on the other side.

Yes, that's a nice side-effect.

> I think you're right that we could get away with undefined order of
> creation, but it would be very nice to have in-order if possible. In
> that case, a web app that sets up a number of channels during
> initialization could skip the labels and simply rely on order (i.e. it
> knows that the DataChannel object in the first event should go into the
> chatChannel variable and so on).

The simplest way to do that would be to put the control messages (at 
least create messages) on Stream 0 (and reserve it), and mark them as 
reliable in-order.  That will guarantee order-of-creation; if we put 
them on PPID messages in-Stream, we can't easily guarantee 
order-of-arrival/creation.  It inherently means blocking for these 
cases, but that's implied by the API (in-order creation).

It may still make sense for close messages to be in-Stream (or to signal 
close with a reset of the stream), to guarantee all messages have been 
delivered or dropped before close.

So: I propose we allow duplicate labels, and there will be no matching 
of labels on creates from opposite ends, and we require in-order 
notification of dataChannel creations via ondatachannel.

The only remaining glare issues will be internal to the wire protocol 
(stream number selection) and not visible to the JS API.

At the wire level, we'd reserve stream 0 for control messages, use PPIDs 
in the streams for typing the data blobs, and use stream reset to signal 
dataChannel close.  Detailed protocol description will be done in IETF 
rtcweb.

How does this sound to people?

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Friday, 24 February 2012 16:22:58 UTC