- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Mon, 30 Jan 2012 00:59:10 -0800
- To: public-webrtc@w3.org
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 randell-ietf@jesup.org
Received on Monday, 30 January 2012 08:59:52 UTC