Re: DataChannels API

On 9/6/2012 10:19 AM, Adam Bergkvist wrote:

>> Supported channel types are reliable (and and out of order) channels,
>> unreliable and partly-reliable channels.  (See the dictionary below.)
>>
>
> What role do partly-reliable channels have here? I don't see a natural
> way to expose such channels to JavaScript ATM since we put the transport
> properties on the channel and not on every package.

Messages are returned to onmessage when we get them from the stack. 
With an unreliable channel, you won't know if there were missed packets 
unless you include framing information in the application data.  (SCTP 
doesn't have per-stream sequence numbers, so it can't easily tell us if 
there was a lost message *on that stream*.)

>> When can createDataChannel() be called?
>> ----------------------------------------------------------
>>
>> Currently pc.createDataChannel() must be called after onconnected
>> fires.  This was a point of discussion at the meeting and on the rtcweb
>> list, since DataChannels need some RTTs to establish; allowing the
>> application to pre-request data channels would allow them to be included
>> in the signaling (and thus save 1 RTT off the setup time).
>>
>
> What triggers the onconnected callback?

SCTP/DTLS Association connection.

>> Do we need a DataConnection object?
>> -----------------------------------------------------
>>
>> It was suggested that we have a DataConnection object, and hang
>> createDataChannel off of that.  (see the thread "DataConnection objects"
>> from June.)  Doing so would minorly reduce the number of methods on
>> PeerConnection (by moving onconnection/onclosedconnection/ondatachannel
>> to it, and maybe an attribute for initial number of streams).

>> Overall, I'm very mildly in favor of adding the DataConnection object,
>> because it might be useful in some other contexts in the future.  I do
>> think it complicates PeerConnection slightly, but only slightly  (less
>> methods, but PeerConnection now needs to trigger renegotiation when
>> createDataConnection is called.)
>>
>
> I'm still a bit hesitant to insert another object. However, if we need
> the extra state machine (onconnection and onclosedconnection) I'm, on
> the other hand, a bit hesitant to just add that to PeerConnection as
> well (since it already exposes two types of states).

I waffle about whether I want a DataConnection object.  It's cleaner, 
but a little more work with little practical win.  We could name 
onconnection/onclosedconnection to be more explicitly related to data 
Connections.

>> Label glare:
>> ---------------
>> A previous discussion ("Data API symmetry", in April/May) covered this.
>> This is the "what happens if both sides call createDataChannel("foo",{})
>> at the same time" question.  You can:
>>
>> 1) Create two channels labelled "foo".  Each side would get an onopen to
>> their createDataChannel, and each would get an onDataChannel and onopen
>> for the one created by the other side. Handling the glare would be the
>> application's domain.
>> 2) Fail both (or find some agreed-on tiebreaker that lets you have one
>> fail and the other succeed).
>> 3) Create one channel labelled "foo", and each side would believe they
>> created it.  Both would simply get "onopen", and it might even come
>> faster than normal.  NOTE: if the two sides select different options for
>> the channel, then you still may need to return errors! (or create
>> channels with the same label)
>>
>> #3 is mildly appealing, until you think about how you handle errors with
>> disagreement on reliability.  So I think I end up preferring #1.  #3
>> also implies you should have a unique label for each channel, to avoid
>> confusions with opening multiple channels with the same name at the same
>> time when the other side tries to as well.
>>
>
> Since we want to support the "create at A, dispatch at B"-method I agree
> to #1.
>
> #3 also comes with timing issues when channels can be created by both
> "label matching" and "create at A, dispatch at B"-methods. How long
> should you wait for a matching label before dispatching a channel on the
> B-side instead?

You wouldn't wait; either there's glare and you "connect" the two 
create's to the same channel (and both just get onopen), or there isn't 
glare, and on the receiving side you get ondatachannel (and again both 
will get onopen).

>> Attributes:
>> -------------
>> Is the single "reliable" attribute enough?  Do we need to expose the
>> dict entries?  Do we need a FindDataChannel(label) to get a reference to
>> an existing channel?
>>
>> (My opinion: Probably no to all of these, though I can see exposing the
>> dict entries.)
>>
>
> I think a reliable property is preferable since the developer doesn't
> have to derive what reliable is from a set of other properties. It
> shouldn't prevent us from exposing other properties (later) to tweak the
> transfer mode.

Ok.  (I mis-spoke about "no to all of these", I had meant effectively 
that a single reliable attribute is probably enough.)

>> This is the dictionary for RTCPeerConnection's createDataChannel()
>> method: (xpidl)
>>
>> /* If either maxRetransmitTime or maxRetransmitNum are set, it's
>>      unreliable, else it's a reliable channel.  If both are set it's an
>>      error.  outOfOrderAllowed can be used with any type of channel.  The
>>      equivalent of UDP is { outOfOrderAllowed: true, maxRetransmitNum:
>> 0 }.
>>      The TCP equivalent is {}. */
>>
>> dictionary DataChannelInit {
>>     boolean outOfOrderAllowed;
>>     unsigned short maxRetransmitTime; // in ms
>>     unsigned short maxRetransmitNum;
>> };
>>
>>
>> And in PeerConnection: (xpidl)
>>
>>     /* Data channel */
>>     nsIDOMDataChannel createDataChannel([optional] in ACString label,
>>                                         /* DataChannelInit */
>> [optional] in jsval options);
>>     attribute RTCPeerConnectionCallbackVoid onConnection;
>>     attribute RTCPeerConnectionCallbackVoid onClosedConnection;
>>     attribute RTCPeerConnectionCallback onDataChannel;
>
> This is an EventHandler (not a callback) with an associated
> DataChannelEvent in the current specification. onConnection and
> onClosedConnection should also be EventHandlers for consistency with the
> rest of the spec.

Ok.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Thursday, 6 September 2012 14:40:06 UTC