episode 14: Peer-to-peer communication

32 views
Skip to first unread message

Michiel B. de Jong

unread,
Mar 19, 2013, 6:23:28 AM3/19/13
to unho...@googlegroups.com
here is episode 14 of the unhosted web apps "handbook", about
peer-to-peer communication:

https://unhosted.org/adventures/14/Peer-to-peer-communication.html

Derek Elkins

unread,
Mar 25, 2013, 12:25:00 AM3/25/13
to unho...@googlegroups.com, anyt...@michielbdejong.com
I actually heard about unhosted.org via my interest in DHTs.  I heard about PeerConnection about a week after the first Firefox nightly "supporting" it.  I'm vaguely intrigued at writing "server" (and peer-to-peer) software entirely in the browser.  At any rate, I made a very simple, prototypical signalling intermediary a month or so ago which is here https://github.com/derekelkins/browserhub with an example.  It's very finicky setting up a DataConnection in Firefox (at least as of a couple weeks ago) but the example in that project should work.

Michiel B. de Jong

unread,
Mar 25, 2013, 3:02:27 AM3/25/13
to unho...@googlegroups.com
On 2013-03-25 12:25, Derek Elkins wrote:
> I actually heard about unhosted.org via my interest in DHTs. I heard
> about PeerConnection about a week after the first Firefox nightly
> "supporting" it. I'm vaguely intrigued at writing "server" (and
> peer-to-peer) software entirely in the browser.

great! yes, you should also check out webp2p.org in that case.

> At any rate, I made a
> very simple, prototypical signalling intermediary a month or so ago
> which is here https://github.com/derekelkins/browserhub with an
> example. It's very finicky setting up a DataConnection in Firefox (at
> least as of a couple weeks ago) but the example in that project
> should
> work.

ah, excellent. that should help me get my own snippets working. :)

Jan-Christoph Borchardt

unread,
Mar 25, 2013, 4:06:01 AM3/25/13
to unho...@googlegroups.com
By the way, if you haven't seen this: http://conversat.io is a great demo of what WebRTC/PeerConnection enables.
It's a Google Hangout like app, can be used with up to 5 people I think. (Michiel, you could use that to replace Skype, Gtalk, Hangouts, phone etc)

Not open source though, but there are some posts on hacks.mozilla.org diving into similar stuff.

--

--- You received this message because you are subscribed to the Google Groups "Unhosted Web Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unhosted+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Jesús Leganés Combarro

unread,
Mar 27, 2013, 1:54:11 PM3/27/13
to unho...@googlegroups.com, anyt...@michielbdejong.com
Hi Mich, have you find any solution to the "serverless problem" you talk about on your post? Derek comment about let the browser listening for incoming request it's great, but unluckily seems it will not be feasable without a change on the specification as he proposes, have you think a better approach? Should be send that proposition to WebRTC mail list to be added to the standard?

Michiel B. de Jong

unread,
Mar 27, 2013, 2:28:47 PM3/27/13
to unho...@googlegroups.com
On 2013-03-27 18:54, Jesús Leganés Combarro wrote:
> Hi Mich, have you find any solution to the "serverless problem" you
> talk about on your post? Derek comment about let the browser
> listening
> for incoming request it's great, but unluckily seems it will not be
> feasable without a change on the specification as he proposes, have
> you think a better approach? Should be send that proposition to
> WebRTC
> mail list to be added to the standard?
>

it is fundamentally impossible to run the control channel from inside
the browser.

i mean, it's not theoretically impossible (you could use UDP on your
LAN as a first bootstrap), but it will then only work if there are
continuously enough neighbors always online anywhere you go, so in
practice, that's just not going to fly. you could use a DHT, but even if
for instance you use the bittorrent mainline DHT to store control
channel data, there is a dependency on bittorrent.com which you are
unlikely to get rid of.

That topic is not relevant to webrtc itself (it leaves friend discovery
out of scope on purpose), but it's the main topic of webp2p.org, so
definitely, discuss it there, or we can keep talking about it on this
thread. but the webrtc mailing list would not be the right place i
think.


Cheers!
Michiel

pir...@gmail.com

unread,
Mar 27, 2013, 4:08:03 PM3/27/13
to unho...@googlegroups.com
I know on a pure P2P network it would be needed to have a permanent
"critic mass" to be there so the network can self-maintain operative,
but my question goes for other place.

Currently, the biggest problem with WebRTC (or as someone told me,
"the Internet Holy Grayl" :-P ) is about the initial handshake, and
specifically how to connect to another peer without a server between
them. On my P2P app I'm using what I call "handshake servers" that in
fact they are pools where peers can announce and interchange their
SDPs, and after they got a minimal "critic mass", they disconnect and
start to use only the P2P network to find new peers. In fact, today I
have think about a way where you can connect to the P2P network only
knowing how to connect to one of the already-connected peers (working
as a temporal proxy to help you connect to other peers and get your
own critic mass), but you need a third party server anyway. That's the
point I want to remove.

Derek idea would be feasable if a PeerConnection object would be open
and left listening for incoming request with a "magic word" (the
channel label, for example?). In fact I though TURN/STUN servers would
be able to do this uploading the SDP data (you know where a peer is
and what's his SDP data to add to your PeerConnection object, but you
need to send him someway your SDP data so it can call you back), but
the API currently doesn't allow this (and also SDP info, althought
geospatial and temporal unique, it's short live).

I don't know if WebRTC should modify the API to add support for
something like this or they have done good leaving the signaling
channel up to the developer, but for server-less application is a
problem. The most promising technology I have seen so far is PuSH API
currently in development by Mozilla and Telefonica so a client would
register that it's open for connections and keep listening for
incoming PeerConnection requests, but seems is more focused as a
replacement of SMS messages (good) and will require that data is
originated on a server instead of also from clients like a real
Publish/Subscript protocol (bad :-( ). Maybe should I ask to them?

2013/3/27 Michiel B. de Jong <anyt...@michielbdejong.com>:
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "Unhosted Web Apps" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to unhosted+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux
Reply all
Reply to author
Forward
0 new messages