On Fri, May 21, 2010 at 1:29 AM, Anne van Kesteren <[email protected]> wrote: > On Fri, 21 May 2010 10:20:00 +0200, Nicklas Sandgren > <[email protected]> wrote: >> >> As mentioned in the draft, the peer-to-peer API must rely on underlying >> protocols/mechanisms to establish the connections and to transport the >> streams. What are the thoughts regarding these protocols, and has there been >> any discussion around this topic? > > Last I checked the hope is that the protocol problem will "go away". So far > it seems that is unlikely. :-)
There has been some limited discussion about the peer-to-peer section as it relates to real-time peer to peer gaming applications: http://old.nabble.com/Real-time-networking-in-web-applications-and-games-td27994693.html And references a proposed lower level (UDP-based) WebSocket-like protocol: http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt The approach here was to punt as much of the flow control/retransmission policy to the application level, whether you're streaming video streams, game data or whatever. >> You could also debate how often peer-to-peer media streams will actually >> work. Aren't FWs and NATs going to give problems in many cases? Maybe it >> would be better to design for a situation where the media always go via a >> server. Additional benefits are that WS could be used for media transport, >> and that the media could be transcoded if the codec capabilities of the >> clients do not match. > > I'm not really sure how this is an alternative approach. It would just be > leaving peer-to-messaging out... Streaming video via WebSocket is something > we definitely want to enable in due course, irrespective of whether > peer-to-peer messaging comes to fruition. To answer the question of problem in p2p regarding FWs and NATs, the libjingle folks report that 92% of participants are able to connect directly: http://code.google.com/apis/talk/libjingle/important_concepts.html#connections with the remainder using simple message relay servers. In practice this represents a hugely significant bandwidth reduction for application hosts. Given the level of possible application sophistication promise in the next gen web, leaving out such a huge efficiency win would be a shame. An approach that allows data output from devices to be adjusted to a target bit rate and collected in meaningful chunks, but not directly connected to the transport mechanism could be a viable path. A device stream could be transported either via WebSocket or a p2p networking layer with equal ease, leaving the message marshaling up to the web app. Any feedback on the specific p2p packet layer protocol is always welcome. Regards, Mark
