Re: Data API symmetry

On 4/26/2012 10:54 AM, Adam Bergkvist wrote:
> On 2012-04-25 18:26, Randell Jesup wrote:
>> On 4/25/2012 10:04 AM, Adam Bergkvist wrote:

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

True.

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

Probably true, though it's hard to predict "most common cases" for this. 
  Certainly you simplify one case, and complicate another.

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

Yes.  Instead of handling file transfer as a single pipe with in-stream 
(or even out-of-stream) commands (ala ftp, etc), you'd run a separate 
DataChannel for each transfer.  This has an advantage of separating the 
error recovery - if you're transferring a series of files, you can avoid 
head-of-line blocking when one channel has an error.  Of course, an app 
doesn't have to do that - they can implement their own protocol on top 
of a single DataChannel if they like.  But they could use the label to 
provide a filename or description for each transfer.

For example, I envisioned that there might be "proxy browsing" uses of 
DataChannels (think Tor), where each request mapped to an HTTP GET at 
the other end.  You really need separate channels here, as each stream 
will come in at a different rate/time, and you want to be able to spawn 
a moderately large number of simultaneous requests (which is what 
browsers do).

    dc[blah] = pc.createDataChannel("GET http://cnn.com/",...);

It helps here that labels are effectively arbitrary strings; if they 
weren't the app would need to create a simple protocol layered on the 
DataChannel that more-or-less mirrors http.  However, using the label 
has a positive effect in that we don't need to wait for the first 
datagram (especially in the "onopen" case, which would mean 1 RTT added 
to each transaction, or forcing a more-complex solution that warms 
connections or uses a control connection (which is then subject to head 
blocking on loss)).

I'll agree totally that proxying is an uncommon usecase, and so it's ok 
if we complicate it some to make simple ones easier.


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 1 May 2012 15:32:07 UTC