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

[Mark Frohnmayer]

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