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: Tue, 24 Apr 2012 12:19:20 +0200
Cc: public-webrtc@w3.org
Message-Id: <AC7367D4-6BF9-494D-86BE-B06FE2C977A7@lurchi.franken.de>
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
On Apr 24, 2012, at 10:49 AM, Stefan Hakansson LK wrote:

> On 04/23/2012 06:01 PM, 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.
>> 
>> We now have to decide what to do about the JS-level API; which to recap
>> currently requires waiting for onopen on the opener's side, and allows
>> the answerer to send() immediately on getting ondatachannel.
>> 
>> 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
That is possible.

Best regards
Michael
> (regardless of if the connection is set up to do this or not). And we need to specify the order things get sent in special case (e.g. if the app does one send immediately plus registers another send to be done at "onopen").
> 
> Stefan
> 
> 
Received on Tuesday, 24 April 2012 10:19:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 24 April 2012 10:19:53 GMT