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

Re: DataChannel API and onopen

From: Randell Jesup <randell-ietf@jesup.org>
Date: Tue, 24 Apr 2012 14:48:05 -0400
Message-ID: <4F96F565.4030305@jesup.org>
To: public-webrtc@w3.org
On 4/24/2012 4:48 AM, Stefan Hakansson LK wrote:
> On 04/23/2012 06:01 PM, Randell Jesup wrote:

>> We've figured out that we can allow send() before onopen (in either
>> direction) by forcing data to be in-order until the 3-way handshake is
>> complete. Obviously, if you're using in-order (reliable or unreliable)
>> this doesn't matter. It does cause and data sent to be buffered in the
>> stack(s) until it can be delivered, which typically would be no real
>> problem unless the OPEN (or OPEN_RESPONSE) was lost and had to be
>> re-transmitted.
>>
>> There are two really "simple and clean" solutions:
>> 1) both sides wait for onopen()
>> 2) neither side waits for onopen()
>> Note that in #2 we'd still have onopen() for ease of porting WebSockets
>> code to it DataChannels.
>
> I may be confused, but can't we have both? I.e., onopen() is fired on
> both sides, but it is up to the app to wait for it or not.  If the app
> does not wait, the data submitted before the connection is really open
> will be delivered in order (regardless of if the connection is set up to
> do this or not).

Right, this is exactly option #2 (note the "we'd still have onopen for 
ease of porting WebSockets code to [] DataChannels").  I have this 
working in Mozilla, but Adam makes a good argument for #1.  The 
difference in code is pretty trivial.

-- 
Randell Jesup
randell-ietf@jesup.org
Received on Tuesday, 24 April 2012 18:49:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 24 April 2012 18:49:18 GMT