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

Re: DataChannel API and onopen

From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Date: Mon, 23 Apr 2012 22:14:20 +0200
Cc: Randell Jesup <randell-ietf@jesup.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Randall Stewart <rrs@lakerest.net>, Salvatore Loreto <salvatore.loreto@ericsson.com>
Message-Id: <9CCD3F06-67F0-468C-BEED-9362072DE581@lurchi.franken.de>
To: Tim Panton <thp@westhawk.co.uk>
On Apr 23, 2012, at 6:22 PM, Tim Panton wrote:

> 
> On 23 Apr 2012, at 17:01, Randell Jesup wrote:
> 
>> In going over the details for the DataChannel minor protocol and how it works over SCTP, we realized we'll need a 3-way handshake instead of a 2-way.  The reason is that an OPEN_RESPONSE sent ordered followed by a data message sent unordered would allow the data message to come in at the other end before the open response, and since we don't know the input-stream -> output-stream mapping until we get the OPEN_RESPONSE, we might not know what to do with it.  So we plan to add an ACK message to the protocol to provide the 3-way handshake.
>> 
> ....
> 
>> It seems to me that forcing in-order delivery until the handshake is complete is simpler for the user, and only rarely has any impact on the application.  The exception might be if you wanted to dump a bunch of sends that were reliable and out-of-order immediately on creation of the channel - and I don't see it being a major issue there - and you can still wait on onopen if you want.
>> 
>> Recap: #2 is slightly closer to how WebSockets works (though anything coded for WebSockets' onopen behavior would still work in #1), and #2 avoids potential additional buffering in the stack if the OPEN/OPEN_RESPONSE is lost.  (If it's not lost, there's really no extra buffering occurring, except maybe in the rare case where we need to increase the maximum number of simultaneous streams.)
>> 
>> Opinions?
> 
> 
> Is there any way that the handshake can fail ? If there is, then the apis are significantly different in the way that they report that failure. 
> (Since you don't mention a matching NACK I guess this isn't an issue).
There is a small chance that the handshake can fail. Mainly due to a shortage of resources (streams)...

Best regards
Michael
> 
> A downside of #2 is we need to define what order data gets sent in this case:
> 
>   temp = peer.createDataChannel(..)
>   temp.data_to_send = "I want to send a magic hello string";
>   temp.onopen = function() {
>        temp.send(temp.data_to_send);
>        };
>  temp.send("I want to send normal activity");
>  temp.close();
>  temp = null;
> 
> Tim.
> 
> 
> Tim Panton - Web/VoIP consultant and implementor
> www.westhawk.co.uk
> 
> 
> 
> 
> 
Received on Monday, 23 April 2012 20:14:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2012 20:14:52 GMT