Re: Data API Proposal aligned to WebSocket

On 2/22/2012 9:11 PM, caryfitz wrote:
> On Wed, 22 Feb 2012 17:50:58 -0500, Randell Jesup wrote:
>> Yeah, I'm still of two minds on the unidirectional/bidirectional
>> thing. It's certainly a simpler API if it's bidirectional (one object
>> type instead of two), even if many uses don't use the opposite
>> direction. It does potentially slow down channel creation, as you
>> probably need a 1.5 RTT setup instead of .5 or 1.0 RTT (depending on
>> if you wanted an "onopened"), and you have to handle stream-id
>> 'glare'. It requires more 'networking' code to handle all this. I
>> prefer unidirectional - the mapping to streams is much simpler, but I
>> realize the typical "network-style" API is at odds with what a typical
>> JS programmer would expect, so that's an argument for this type of
>> API.
>>
>> Not a big deal, though.
>
> WRT round trips on setup, we are stuck with whatever the underlying
> transport protocol does, in this case, SCTP.

Actually, SCTP is purely unidirectional and "open-less" for streams. 
You just sctp_sendmsg() with a stream id - 0 RTT :-).  We're layering a 
dataChannel abstraction (with opens and closes and unified attributes) 
on top of SCTP streams already.

For uni-directional, we'll need a "open" metadata message from a->b, and 
an "opened" metadata message from b->a (if we have onopened or use a 
readyState).  (0.5 or 1.0 RTT).  For bidirectional, we'll need an open 
message a->b, and opened message b->a, and we may need a second opened 
message from a->b for glare handling - I think I have a solution that 
doesn't need it, if so we're still at 0.5 or 1.0 RTT.  We don't need the 
second opened message since 'a' already has a dataChannel object for the 
channel and is ready to receive data.

Bidirectional adds a level of complexity to the close part of the wire 
protocol as well (since we want to re-use stream numbers).

I'll hash the wire-level details out in rtcweb, but I think it's all good.

> In general, it seems easier and more natural to leave the semantics of
> SCTP alone and make the fullest use of the protocol that we can, without
> creating issues for javascript. I don't see any issues with bi-directional.

Ironically, that was why I wanted unidirectional - a simpler layer 
between SCTP and the application.  But as mentioned, the API is simpler 
in bidirectional (no send vs. receive objects).

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Thursday, 23 February 2012 14:36:58 UTC