Re: DataChannel API and onopen

On Apr 24, 2012, at 8:41 PM, Randell Jesup wrote:

> 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.
Any data message from A to B can be considered an implicit ACK. Of course I'm assuming the A sends
messages to B if it opens a channel.
> 
> 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.
I think doing the same at both sides is a good idea. I agree with Randell.

Best regards
Michael
> 
> 
> -- 
> Randell Jesup
> randell-ietf@jesup.org
>

Received on Tuesday, 24 April 2012 19:18:21 UTC