Re: Data API symmetry

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.

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

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.

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

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

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Wednesday, 25 April 2012 16:26:51 UTC