Re: DataChannel API and onopen

On 4/24/2012 10:23 AM, Adam Bergkvist wrote:
> On 2012-04-23 18:01, Randell Jesup wrote:
>>
>> 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.


>> 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?
>
> In approach #2, we move away from behaving like a WebSocket. More
> precisely, a DataChannel could still be used instead of a WebSocket but
> a WebSocket couldn't replace a DataChannel since a call to send() before
> the "open" event would result in a InvalidStateError.

That's a useful point; it's not *all* about moving everyone to WebRTC 
data channels (though it's tempting).  And some code may need to run on 
systems without WebRTC support.

> I've drawn some simple signaling diagrams below to help myself to
> overview this. Let me know if they are over-simplified or perhaps even
> wrong.

They're pretty good.

> What we currently have with a 2-way handshake with comes with some
> problems.
>
> 2-way handshake
> A -- OPEN -> B (datachannel@B)
> A <- OPEN_RESP -- B (open@A)
>
> Considering a 3-way handshake, approaches #1 and #2 would basically fire
> the "open" events at the same time, but the difference would be that in
> #1 it wouldn't be OK to call send() before the "open" event.

Correct.

> 3-way handshake
> A -- OPEN -> B (datachannel)@B)
> A <- OPEN_RESP -- B (open@A)
> A -- ACK -> B (open@B)
>
> Couldn't we keep our current API behavior by delaying the "datachannel"
> event on the B-side as described below? The order that the events are
> trigger are reversed compared to the 2-way handshake above, but is that
> a problem?
>
> 3-way handshake
> A -- OPEN -> B
> A <- OPEN_RESP -- B (open@A)
> A -- ACK -> B (datachannel@B)

Yes, this will work.  It means that data will be delayed by 1 full RTT 
compared to option #2 (same as option #1).  The data transfer behavior 
is almost identical to option #1; the only difference would be if the 
ACK is lost, we would have to buffer data packets in the DataChannel 
object that was waiting for ACK to announce itself.  This is a problem, 
though one we can decide to live with.

One other reason I didn't propose a #3 like this was that the current 
design (I realized) wasn't orthogonal - one side has to wait, the other 
doesn't.  So for the sender it's like WebSockets, but for the receiver 
(after the channel is open) it isn't (no onopen).  This may be ok, in 
that normally a browser isn't the receiver of a WebSocket connection, so 
there's less existing code, but I could see that replaceability being 
useful if you need to write code to emulate DataChannels over WebSockets 
via a server.

If we want the "port the code to WebSockets easily", then we should go 
with onopen at both sides (option #1).  If we don't care about 
port-to-WebSockets, and just care about from-WebSockets, or feel the 
simpler API is a big enough win, then option #2.  I think the buffering 
requirement along with the asymmetry of your option #3 makes it less 
appealing.


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 24 April 2012 18:42:22 UTC