Re: A small proposal to cleanup DataChannel construction.

On Wed, Apr 23, 2014 at 2:09 PM, Robin Raymond <robin@hookflash.com> wrote:

>
> WebRTC 1.0 which only uses data channel defines the init properties as
> follows:
>
> dictionary RTCDataChannelInit {
>   boolean ordered<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-ordered>= true;
>   unsigned short? maxRetransmitTime<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-maxRetransmitTime>= null;
>   unsigned short? maxRetransmits<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-maxRetransmits>= null;
>   DOMString protocol<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-protocol>= "";
>   boolean negotiated<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-negotiated>= false;
>   unsigned short? id<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-id>= null;
> };
>
> I suggest we "borrow" the parameter definition 'as is' unless there's
> reason to not do it.
>
> ​
I agree.  Isn't that what we've done already?​



>
> One area of concern are these two params:
>
>  negotiated of type boolean, defaulting to false The default value of
> false tells the user agent to announce the channel in-band and instruct the
> other peer to dispatch a corresponding RTCDataChannel<http://www.w3.org/TR/webrtc/#idl-def-RTCDataChannel> object.
> If set to true, it is up to the application to negotiate the channel and
> create aRTCDataChannel<http://www.w3.org/TR/webrtc/#idl-def-RTCDataChannel> object
> with the same id <http://www.w3.org/TR/webrtc/#dom-datachannel-id> at the
> other peer.
>
>  id of type unsigned short, nullable, defaulting to null Overrides the
> default selection of id for this channel.
>
>
> Do we need/want this feature? I guess one issue is that if both parties
> create "id" with 30 but set negotiated to false, does that mean they get
> the same channel despite the possibility of "ondatachannel" event firing
> because of a creation race condition?
>

​Yes, we do, for the same reasons we wanted it for 1.0, and because we want
1.0 parity.

And the answer is the same as for 1.0:  There is 1 bidirectional data
channel per id.  ​If you both pick 30, then that's fine, each side only
sees one channel.  I don't remember what the spec says about ondatachannel
firing.  I'm hoping it says that if you've picked id 30 then it would never
fire with id 30.  But it might say otherwise, and we should probably do the
same as what it says.  Either way isn't that big of a problem, because
presumably if you're picking your own id and using negotiated=false, then
you're using the power tools and know what you're getting into.  I think
most people will either use the defaults or use negotiated=true.


>
> Likewise if a client uses id of "50" and creates a data channel, and
> re-uses the same id of "50" and creates another data channel, do the
> objects points to the same data channel or is that an error? What if a
> pending "ondatachannel" was going to event but we created "50" first? This
> id thing creates a bit of ambiguity in my mind for behavior and it needs
> clear definition.
>
>
​I believe it's an error to pick a used id.  If you pick 30 twice or you
pick 30 and the system randomly picks 30, you get an error.  ​ But we
should check to make sure we do the same as the 1.0 spec.  Again, if you're
mixing picking ids and letting the system, you're using the power tools and
should know what you're getting into.
​



> -Robin
>
>   Bernard Aboba <Bernard.Aboba@microsoft.com>
>  April 22, 2014 at 6:00 PM
> Within the current proposal, the RTCDataChannelParameters dictionary would
> look like this:
>
> dictionary RTCDataChannelParameters {
> DOMString id = "";
> DOMString type = ""; // Do we still need this?
> boolean outOfOrderAllowed = false;
> unsigned short maxRetransmitTime = null;
> unsigned short maxRetransmitNum = null;
> DOMString protocol = "";
> boolean preset = false;
> unsigned short stream = null;
> };
>
> With dictionary inheritance, it might look like this:
>
> dictionary RTCDataChannelParameters {
> DOMString id = "";
> DOMString type = ""; // Do we still need this?
> };
>
> dictionary RTCSctpDataChannelParameters : RTCDataChannelParameters {
> boolean outOfOrderAllowed = false;
> unsigned short maxRetransmitTime = null;
> unsigned short maxRetransmitNum = null;
> DOMString protocol = "";
> boolean preset = false;
> unsigned short stream = null;
> };
>
> The rest of it looks like this:
>
> [Constructor(RTCDataTransport transport, RTCDataChannelParameters
> parameters)]
> interface RTCDataChannel : EventTarget {
> readonly attribute RTCDataTransport transport;
> readonly attribute RTCDataChannelParameters parameters;
> void send (Object data);
> attribute EventHandler ondata;
> };
>
> [Constructor(RTCDtlsTransport)]
> interface RTCSctpTransport : RTCDataTransport {
> attribute RTCDtlsTransport transport;
> static RTCSctpCapabilities getCapabilities ();
> void start (RTCSctpCapabilities remoteCaps);
> void stop ();
> attribute EventHandler ondatachannel;
> };
>
> dictionary RTCSctpCapabilities {
> unsigned int maxMessageSize = null;
> };
>
>