New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Centralisation caused by peerjs-server #2

Open
robinpaulson opened this Issue May 30, 2014 · 11 comments

Comments

Projects
None yet
3 participants
@robinpaulson

robinpaulson commented May 30, 2014

I see the project uses peerjs for peer to peer communication, it's a great tool, but i wonder about the centralisation issues peerjs-server creates. If the project is aiming for a true distributed hash table, I think peerjs-server prevents that. Is there any aim to replace it with something else at any point?

@tsujio

This comment has been minimized.

Show comment
Hide comment
@tsujio

tsujio May 30, 2014

Owner

I agree with your opinion that peerjs-server prevents decentralization. I want to exclude it from the system.

But one of the points which make it difficult is that in WebRTC each peer has multiple addresses/ports as ICE Candidates. Moreover, ICE Candidates can change or increase dynamically. So something which forwards ICE Candidates to other peers like peerjs-server is needed at this time.

I am finding a good solution.

Owner

tsujio commented May 30, 2014

I agree with your opinion that peerjs-server prevents decentralization. I want to exclude it from the system.

But one of the points which make it difficult is that in WebRTC each peer has multiple addresses/ports as ICE Candidates. Moreover, ICE Candidates can change or increase dynamically. So something which forwards ICE Candidates to other peers like peerjs-server is needed at this time.

I am finding a good solution.

@tsujio

This comment has been minimized.

Show comment
Hide comment
@tsujio

tsujio May 30, 2014

Owner

The description I mentioned above is not the true nature of the problem.

The most significant problem is that in WebRTC we cannot start communication until exchanging SDP messages, but we need to communicate in order to exchange SDP messages.

peerjs-server helps us to exchange SDP messages to start communication.

Owner

tsujio commented May 30, 2014

The description I mentioned above is not the true nature of the problem.

The most significant problem is that in WebRTC we cannot start communication until exchanging SDP messages, but we need to communicate in order to exchange SDP messages.

peerjs-server helps us to exchange SDP messages to start communication.

@robinpaulson

This comment has been minimized.

Show comment
Hide comment
@robinpaulson

robinpaulson May 30, 2014

As you suggest it's rather a chicken-and-egg situation, making the first connections very difficult. I've done a fair bit of research over the last few days, the problem of locating a peer seems unsolvable using only pure JS, at some point one needs probably one or more STUN servers, at least until IP6 is dominant and there are no problems with NAT traversal. The folks working on https://github.com/feross/webtorrent claim they can solve it, but i've not seen anything concrete yet.

robinpaulson commented May 30, 2014

As you suggest it's rather a chicken-and-egg situation, making the first connections very difficult. I've done a fair bit of research over the last few days, the problem of locating a peer seems unsolvable using only pure JS, at some point one needs probably one or more STUN servers, at least until IP6 is dominant and there are no problems with NAT traversal. The folks working on https://github.com/feross/webtorrent claim they can solve it, but i've not seen anything concrete yet.

@tsujio

This comment has been minimized.

Show comment
Hide comment
@tsujio

tsujio May 31, 2014

Owner

NAT traversal is also a problem.

If we could start communication only by knowing remote address like IP network, DHT over WebRTC would be a true distributed system.

Owner

tsujio commented May 31, 2014

NAT traversal is also a problem.

If we could start communication only by knowing remote address like IP network, DHT over WebRTC would be a true distributed system.

@jure

This comment has been minimized.

Show comment
Hide comment
@jure

jure Jun 18, 2014

Contributor

The signaling part of WebRTC can't be avoided and for practical purposes, that means a server. But I think a very good middle ground would be to use PeerJS's server for the initial node, and use the Chord network for all other connections.

  1. Peer 1 connects to Peer 2 via PeerJS server (and then disconnects from PeerJS server)
  2. Peer 1 uses Peer 2 and the Chord network to find other peers and connect to them as needed, without involving the signaling server again.

You still need STUN/TURN for NAT traversal, but I think those are way less costly to run compared to a signaling server which serves N * WebSocket connections. The dependency on PeerJS server also limits your scalability to a degree, at least at first, because providing that many WebSockets is not that easy/cheap.

This team is trying to do something similar: boplish/core#10

P.S.: I've ported webrtc-chord to a browserified npm package, for easier use in my projects: jure@0990c95 I want to take this opportunity and thank you for your wonderful work! Thank you!

Contributor

jure commented Jun 18, 2014

The signaling part of WebRTC can't be avoided and for practical purposes, that means a server. But I think a very good middle ground would be to use PeerJS's server for the initial node, and use the Chord network for all other connections.

  1. Peer 1 connects to Peer 2 via PeerJS server (and then disconnects from PeerJS server)
  2. Peer 1 uses Peer 2 and the Chord network to find other peers and connect to them as needed, without involving the signaling server again.

You still need STUN/TURN for NAT traversal, but I think those are way less costly to run compared to a signaling server which serves N * WebSocket connections. The dependency on PeerJS server also limits your scalability to a degree, at least at first, because providing that many WebSockets is not that easy/cheap.

This team is trying to do something similar: boplish/core#10

P.S.: I've ported webrtc-chord to a browserified npm package, for easier use in my projects: jure@0990c95 I want to take this opportunity and thank you for your wonderful work! Thank you!

@robinpaulson

This comment has been minimized.

Show comment
Hide comment
@robinpaulson

robinpaulson Jun 19, 2014

Unfortunately, this is still not decentralised (and that after all is the aim here) - there's not a middle-ground to this, the network is either truly decentralised, that is no peer is more important than any other, or it's not. Running a STUN/TURN server is technically beyond a lot of people, requires two public IP addresses, and can't be done in the browser.

robinpaulson commented Jun 19, 2014

Unfortunately, this is still not decentralised (and that after all is the aim here) - there's not a middle-ground to this, the network is either truly decentralised, that is no peer is more important than any other, or it's not. Running a STUN/TURN server is technically beyond a lot of people, requires two public IP addresses, and can't be done in the browser.

@jure

This comment has been minimized.

Show comment
Hide comment
@jure

jure Jun 19, 2014

Contributor

There are public STUN/TURN servers available, a lot of people just use stun.l.google.com:19302 for STUN. For example, http://numb.viagenie.ca/ can provide TURN for free and there are many other alternatives.

To avoid the requirement for a signaling server, you can do something like http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/ where you paste the offer generated by peer 1 to the other peer, and then copy the answer back to peer 1. You personally act as the signaling server then. I know this is not what you have in mind.

Another option would be to use a different kind of server, for example send offer/answer using Gmail via https://github.com/whiteout-io/smtpclient/blob/master/src/smtpclient.js. You need TCPSocket support for that though, and it doesn't look like this will be available outside of Chrome Apps, etc.

If you want to escape NAT traversal requirement however, you need to change WebRTC itself.

I'm open to other ideas though, but I can't see anything practical while still using WebRTC.

Contributor

jure commented Jun 19, 2014

There are public STUN/TURN servers available, a lot of people just use stun.l.google.com:19302 for STUN. For example, http://numb.viagenie.ca/ can provide TURN for free and there are many other alternatives.

To avoid the requirement for a signaling server, you can do something like http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/ where you paste the offer generated by peer 1 to the other peer, and then copy the answer back to peer 1. You personally act as the signaling server then. I know this is not what you have in mind.

Another option would be to use a different kind of server, for example send offer/answer using Gmail via https://github.com/whiteout-io/smtpclient/blob/master/src/smtpclient.js. You need TCPSocket support for that though, and it doesn't look like this will be available outside of Chrome Apps, etc.

If you want to escape NAT traversal requirement however, you need to change WebRTC itself.

I'm open to other ideas though, but I can't see anything practical while still using WebRTC.

@robinpaulson

This comment has been minimized.

Show comment
Hide comment
@robinpaulson

robinpaulson Jun 19, 2014

Hmm, all interesting, but as you and others imply, they all require some centralisation at some point in the chain - e.g. the first link requires chat/phone/email, all of which run through someone else's services. They may not be STUN, but they are only run by a minority of nodes on the internet.

You mention you can't see anything "practical" in this are, do you see anything "impractical"?

robinpaulson commented Jun 19, 2014

Hmm, all interesting, but as you and others imply, they all require some centralisation at some point in the chain - e.g. the first link requires chat/phone/email, all of which run through someone else's services. They may not be STUN, but they are only run by a minority of nodes on the internet.

You mention you can't see anything "practical" in this are, do you see anything "impractical"?

@jure

This comment has been minimized.

Show comment
Hide comment
@jure

jure Jun 19, 2014

Contributor

If all of your nodes have a public ip address and are not behind a NAT and their IPs are known, perhaps there is a way to use a patched client (I'm sure mainstream WebRTC clients prevent this) to accept predefined SDP offers/answers. I'd have to look at the actual implementation of WebRTC's SDP in Chromium to see if that's feasible: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/app/webrtc/webrtcsdp.cc&q=%20sdp%20webrtc&sq=package:chromium&type=cs&l=28

Contributor

jure commented Jun 19, 2014

If all of your nodes have a public ip address and are not behind a NAT and their IPs are known, perhaps there is a way to use a patched client (I'm sure mainstream WebRTC clients prevent this) to accept predefined SDP offers/answers. I'd have to look at the actual implementation of WebRTC's SDP in Chromium to see if that's feasible: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/app/webrtc/webrtcsdp.cc&q=%20sdp%20webrtc&sq=package:chromium&type=cs&l=28

@tsujio

This comment has been minimized.

Show comment
Hide comment
@tsujio

tsujio Jun 19, 2014

Owner

Hi, @jure.

Thank you for using my webrtc-chord and your BOPlish project is very interesting. I am also interested in open pub/sub platform (I am developing tsujio/webrtc-bbs, an anonymous BBS using WebRTC).

By the way, the centralization problem of WebRTC-based P2P systems is difficult to avoid. But other non-WebRTC-based P2P systems also require something which performs as a server and users discover bootstrap node from it. To realize a true distributed system, network routers may need to implement new discover protocols.

Owner

tsujio commented Jun 19, 2014

Hi, @jure.

Thank you for using my webrtc-chord and your BOPlish project is very interesting. I am also interested in open pub/sub platform (I am developing tsujio/webrtc-bbs, an anonymous BBS using WebRTC).

By the way, the centralization problem of WebRTC-based P2P systems is difficult to avoid. But other non-WebRTC-based P2P systems also require something which performs as a server and users discover bootstrap node from it. To realize a true distributed system, network routers may need to implement new discover protocols.

@jure

This comment has been minimized.

Show comment
Hide comment
@jure

jure Jun 19, 2014

Contributor

Just to clear up any misunderstandings, BOPlish is not my project, it's being worked on by @makkes and @chris--. And I agree about centralization being practically unavoidable. I still think that using the existing WebRTC network as the signaling "server" would be a good idea, to try and partially decentralize formation of WebRTC connections. Limit the actual signaling server's task to only bootstrapping, and other SDP offer/answer exchanges happen over WebRTC.

Contributor

jure commented Jun 19, 2014

Just to clear up any misunderstandings, BOPlish is not my project, it's being worked on by @makkes and @chris--. And I agree about centralization being practically unavoidable. I still think that using the existing WebRTC network as the signaling "server" would be a good idea, to try and partially decentralize formation of WebRTC connections. Limit the actual signaling server's task to only bootstrapping, and other SDP offer/answer exchanges happen over WebRTC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment