- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Tue, 24 Apr 2012 14:48:05 -0400
- 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 UTC