Re: Data API Proposal aligned to WebSocket

On 02/24/2012 05:20 PM, Randell Jesup wrote:
> 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?

Sounds good to me.

/Adam

Received on Friday, 24 February 2012 16:49:37 UTC