Re: Data API symmetry

On 2012-04-25 18:26, Randell Jesup wrote:
> On 4/25/2012 10:04 AM, Adam Bergkvist wrote:
>> Hi
>> In a previous mail conversation we discussed the data channel setup
>> process; as a starting point we had the createDataChannel()@A ->
>> "datachannel event"@B. The question was if we also should support the
>> automatic label matching approach where each peer could call
>> createDataChannel("label") and if the labels were the same, the data
>> channels would be connected and the "open" event would trigger on each
>> side. The result of the discussion was that the two approaches were
>> tricky to combine since it wasn't straightforward to determine if a
>> "datachannel" event should be triggered at the other peer or if the
>> other peer may call createDataChannel() with a matching label in the
>> near future. In the recent discussions about the "open" event we have
>> talked about symmetry and our current API is a bit asymmetric in some
>> sense. Therefore I've done some coding where the current approach with a
>> createDataChannel() call and a "datachannel" event is compared to the
>> matching label approach, not combined with the first approach as in the
>> previous discussion, but on its own. This means that in the matching
>> label approach, a channel is not usable until a matching channel has
>> been created on the other side. I've come up with two cases (A and B
>> described below) and approaches #1 ("datachannel" event) and #2 (label
>> matching) are applied to both.
>> Case A demonstrates the two approaches when two data channels ("chat"
>> and "extra") are set up as soon as the PeerConnection reaches the ACTIVE
>> state ("open" event is triggered). I think this is a common use case
>> when an application wants a set of data channels from the start.
> This is quite true; it's going to be a common usecase for datachannels.

It's really convenient to "declare" the DataChannels you would like to 
use in this way and I think that would appeal to web developers. And 
since a channel consumes almost no resources it wouldn't be bad solution 
either even though you might not use all the channels all the time.

>> The symmetry of #2 is really advantageous in this case - the channels
>> can simply be created and assigned to their corresponding variables.
>> Both sides waits for the "open" event to get started. Approach #1 needs
>> to decide who will create the channels and the receiving side needs to
>> determine which dispatched channel that should go into which local
>> variable.
> This is a very good point.  With one-way channels, it didn't matter, but
> the bidirectional channel approach requires extra coordination.  Though
> the extra coordination is mostly just dealing with the possibility of
> label glare, which we had (IIRC) punted up to the application.
>> In case B, one data channel is set up as the PeerConnection object
>> reaches the ACTIVE state (as in case A), and an "extra" channel is set
>> up as a response to a user action (button click in this case).
>> Approach #1 has an advantage in case B since the API is based around one
>> side initializing the data channel creation process. In approach #2, the
>> JavaScript needs to signal that the other side should create a data
>> channel with a specific label. However, in #1 there's a risk that two
>> parallel data channels with the same label are created if both users
>> clicks the add button simultaneously. In #2, the simultaneous clicks
>> would actually set up the channel and the manual creation signaling from
>> the other side can be discarded by both sides.
> The problem with this approach is that you must signal (in some manner,
> including over a 'control' DataChannel) that you want the other side to
> create the channel.  This gets away a bit from the WebSockets model
> (though not enough to reject it I believe), and adds a number of error
> cases - timeout?  rejection of the request via the control channel?
> Failure of the control channel?  This part gets easier, but the overall
> system and work for the app gets more complex.

You're right that there are some extra error cases in the case with 
different applications on each side and creating new data channels on 
request. But in, what I would argue to be, the most common case, the 
channel matching code can be removed.

> I find the 'hidden state' aspect of this makes me uneasy.  The code
> knows the other side is trying to create channel 'blah', but we hide
> that info until the local side finds out through some other channel that
> we want to create it, then say "ok, sure, if *that's* what you wanted to
> do with the request".  I'd rather just figure out how to deal with label
> glare, and just make it easy for the application.
> Another usecase will be "I want to transfer a file to you", or "I want
> to show you the picture I took"; those are effectively asynchronous.
> The "I want to transfer a file to you" gets a little more complicated,
> but if it's "I want to transfer this directory to you with lots of
> little files", then it may have really slowed things down and
> complicated the process.

I don't understand what you mean here. Sending data is asynchronous as 
before. Are you talking about setting up a specific data channel and 
tearing it down every time you want to send a file?

>> Regarding the settings used when creating a new data channel, #2 does
>> introduce an extra risk of failure if the settings mismatches (not
>> possible in #1), but it's a programming error that will throw an
>> exception. In the example "Case B - #2" above, the settings for the
>> "extra" data channel is known to both sides since it's a symmetric
>> application, but in the case where the initiating side has modified or
>> created a new settings object, the settings needs to be transferred
>> along with the request to tell the other side to create a data channel
>> with a matching label.
>> Thanks for reading all the way here.
> And thanks for really thinking about this and how it will work in practice.

Thanks for reviewing it.

> I'd rather we re-examine the issue of label glare (which may be simpler
> with a symmetric API based on onopen).


Received on Thursday, 26 April 2012 14:54:30 UTC