Re: Alternative data API

On 1/29/2012 11:28 PM, Stefan Hakansson LK wrote:
> On 01/30/2012 02:32 AM, Justin Uberti wrote:
>>     I assume that you're talking about multi-user with a central server,
>>     otherwise there would be a separate PeerConnection to each user.
>>     With the "Alternative Data API" muxing of DOMString data is
>>     straightforward (to do in the application); blobs and ArrayBuffers
>>     is another story. There ChannelMessaging should be possible to use
>>     to create channels, but I've not looked into the details (and am
>>     unsure about the maturity of ChannelMessaging).
>> It's multi-user that is not full mesh, but it might not involve a
>> central server (e.g. a directed p2p graph).
>> If all the elements in the graph are aware of the application protocol,
>> this would certainly work, even with ArrayBuffers. The app could create
>> its own packet format, and use that to create its own multiplexing
>> mechanism, and even its own reliability and priority mechanism (it would
>> of course have to depend on the PeerConnection's congestion control
>> mechanism).
>> This might allow us to make the in-browser code substantially simpler,
>> as it would just be a secure pipe for generic datagrams at this point.
>> All the advanced stuff would be done through JS libraries.
>> I think this is a important point for the WG to consider. Would folks
>> rather have a simpler, less capable API that we can ship sooner?
>> I admit that doing SCTP or PseudoTCP in Javascript sounds interesting.
> I must admit I never thought that far. My idea was more to have a 
> simple API (much aligned to WebSockets) for a start, and then add 
> functionality if needed (with e.g. the options argument); but having 
> SCTP as the underlying transport.
> I think that also with the simple start API you can get a lot of 
> functionality by combining it with other tools in the web platform 
> (and the app can perhaps prioritize between its own data).
> But I think your question (i.e. doing protocol in JS) is valid indeed.

It's interesting, but to me this is backing into what we rejected early 
on - encouraging/forcing app writers develop their own reliability 
protocols on top of a DTLS/UDP datagram transport.  Whether these are 
"shared" JS libraries or plain JS code in the app, there still will be 
the problems that apps have with JS libraries - correctness, bugs, 
updates (and maybe speed).  People normally snapshot a version of the 
shared JS lib, and may fork it; in either case they often never or 
rarely update it.  You may (probably will) get several competing 
implementations with compatibility issues.  And that assumes a single 
"gold-standard" JS reliability app pops up with a high-quality impl; if 
that doesn't happen, it's a *real* mess.  The only positive I see is 
that bugs in the protocol are more likely to be contained, and not the 
source of security bugs.

I think you're much more likely to get stuff reliable and complete (and 
*properly* used by app developers) by incorporating into the browser a 
known solid SCTP impl, and regularly updating it (we could probably do 
so for each Firefox "release train" every 6 weeks).  We know app 
developers (especially in gaming) will want these functions ASAP.

Obviously there are tradeoffs, but I don't think incorporating SCTP is 
going to slow things down *that* much.

Randell Jesup

Received on Monday, 30 January 2012 08:59:52 UTC