[whatwg] <device> element, streams and peer-to-peer connections

On Fri, May 21, 2010 at 1:29 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Fri, 21 May 2010 10:20:00 +0200, Nicklas Sandgren
> <nicklas.sandgren at ericsson.com> 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

Received on Thursday, 27 May 2010 15:34:39 UTC