Re: Alternative data API

On 30 Jan 2012, at 08:59, Randell Jesup wrote:

> 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.
> 

I'll just re-iterate that in my view one of the downsides of STCP is that it is a stream. Many of the things that will travel over this
channel will be messages. If we go for STCP we will require the JS developers to implement a datagram protocol on top of it.
So any 'win' in baking in the reliable transport isn't as big as it looks at first sight.

Tim.


> -- 
> Randell Jesup
> randell-ietf@jesup.org
> 
> 

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk

Received on Monday, 30 January 2012 09:54:58 UTC