W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

Minimizing the protocol (Re: Data API)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 28 Feb 2012 16:49:08 +0100
Message-ID: <4F4CF774.8060007@alvestrand.no>
To: public-webrtc@w3.org
Random thought on trying to get away without defining a setup 
protocol..... what if:

- the existence of the data connection is negotiated in the SDP, not its 
channels.
- channels have labels only on the *creator* side - on the recipient 
side, they get a "label" identical to the channel number. Numeric labels 
on the creator side are forbidden. Result: Label glare is impossible.
- SDP initial offerer gets to create all the odd numbered channels, 
initial answerer gets to create all the even numbered ones. Result: 
Channel number glare is impossible.
- at creation time, the creator sends a zero-byte datagram through the 
channel, with the reliability and retry properties he wants for all 
datagrams on that channel. This results in the "open" signal on the 
other side, and locks in those properties on the return channel (same 
channel number).

No setup protocol needed....?

On 02/28/2012 11:10 AM, Adam Bergkvist wrote:
> On 02/27/2012 10:18 PM, Randell Jesup wrote:
>> On 2/27/2012 12:59 PM, Cullen Jennings wrote:
>>> On the topic of label collision ...
>>> For the apps I want to write, if both sides create something with 
>>> same label name at same time, I want just one stream created with 
>>> that label with no extra work for me as an app programer. If I 
>>> wanted two different streams, I would have created int he labels in 
>>> a way that did not collide.
>>>
>>> On setting per messages attributes such as reliable vs non reliable
>>> I like that API that Adam proposed where you can really on set 
>>> attributes on a DataChannel and all the messages in the channel get 
>>> that.
>>
>> Oh, one more thing: if we use the "silently connect them" on glare, what
>> do we do when the dataChannel attributes for reliability/etc don't
>> match?  Generate a different error?  (The proposal for bidirectional was
>> to create the reverse channel with the same characteristics as the
>> forward channel.)
>
> This is a good point. We've identified other cases where DataChannel 
> setup by label matching introduces a risk of the setup to fail as well 
> (these cases are mentioned in the original WebSocket alignment thread, 
> but we could summarize them here if necessary). I would really prefer 
> to consistently trigger "datachannel" on every successful 
> createDataChannel() call.
>
> /Adam
>
>
Received on Tuesday, 28 February 2012 15:49:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC