4 ms·

WebRTC is widely misunderstood. It is not a p2p-enabling technology. It requires a mechanism for passing messages between nodes prior to establishing a session

WebRTC is widely misunderstood. It is not a p2p-enabling technology. It requires a mechanism for passing messages between nodes prior to establishing a session (this is called "signaling" in the literature). So it's another turtle layer: it's a scheme for communicating between nodes provided they can already communicate. So why does it exist? Answer: to reduce the cost to provide a service where bulk data flows are p2p. It does this by trying to get said flows over UDP with NAT traversal directly between the host networks for communicating nodes. The canonical example is internet telephony. But it does this on the assumption that there will be a long tail of node pairs for which a hairpin route through a server will be needed. It doesn't remove the need for servers, only the resources needed for those servers. Everyone who says they have built a true p2p system with WebRTC is confused[1]. [1] You can build such a thing with WebRTC, but only if the nodes are not browser hosted and have public IPs. If you think that's useful then you're also confused.

Sean-Der 3y ago
What protocols/networks do you consider P2P? Every P2P technology I have used requires some bootstrapping. I have done WebRTC with zero signaling, but browser only one side[0]. I wish the w3c/ietf would care, but that’s the issue with corporate/profit driven standards! [0] https://github.com/pion/offline-browser-communication https://github.com/pion/offline-browser-communication
- Uptrenda 3y ago
  Bootstrapping is an interesting problem. If there's a large P2P network (think like Gnutella) there's papers that have proposed using port scanning of residential IP ranges to find peers that belong to the network. It's an interesting approach because there's no centralized bootstrapping servers. But, port scanning is inefficient and such an approach may only be viable if a network is large (I may be wrong here.) Still, I think it's cool how little work has been done on these problems. I am still really into p2p networks. For my own project I observed that all of the main networks in some way still depend on trusted introduction points. Just many of them and combined. So I think using infrastructure that's federated and open is a good design (in my case: public MQTT servers is what my own software is based on.)
- convolvatron 3y ago
  I think it's worth remembering that the original intent of the internet was entirely p2p and this bootstrapping issue wasn't a problem. In fact, there was a whole set of protocols developed around global multicast that allowed for discovery to build exactly these structures. So you can't blame the ietf for not thinking of this problem - you can blame them for not being able to respond well when the market went and mucked up their architecture by putting nat everywhere.
halfmatthalfcat 3y ago
You can do offline signaling. Quoting MDN: > It's any sort of channel of communication to exchange information before setting up a connection, whether by email, postcard, or a carrier pigeon. It's up to you. All you need are SDPs and ICE Candidates. People choose a centralized signaling server because it's the easiest but WebRTC does not dictate it be that way. Echoing the other commenter, there really is no other way to establish a connection without some knowledge of the other peer, be it gained online or offline.
- keepamovin 3y ago
  I experimented with implementing this manual signaling where the delay between back and forth could be dozens of seconds or even minutes. I found that you need to call restartIce, which is not typically called in SimplePeer and is not normally exposed. So as it currently stands, SimplePeer regular version that you can get from the package manager will not support signaling over dozens of minutes. It just won't work. But it can be made to work if you just call restart ICE, which keeps everything alive. I discovered this through my own research and experiments. And you can see the code below. And also, you can fork this repo and read the instructions to get a working version as well. I think the original idea was basically you can, like, be in your shell and you can run this repo and then you can be chatting with people who come to your GitHub repository. And, the signaling is done over comments and there’s sort of like a comment robot that facilitates that to make it easy. https://github.com/o0101/janus/ https://github.com/o0101/janus/ RestartIce: https://github.com/o0101/janus/blob/9b092218b7623ca198c3caefb840ba75ae86bc78/local-webrtc-backend/page.html#L284 https://github.com/o0101/janus/blob/9b092218b7623ca198c3caef...
- ravenstine 3y ago
  Exactly. This is trivial to carry out and can be done "by hand" between two browsers. I don't know what the OP is talking about. They are speaking as if the commonly chosen mode of bootstrapping a connection is fundamental to the entire communication cycle. It's flat out not true. When the connection has been established, peers are connected directly, but by their definition, this doesn't matter because a trusted peer was used to form the initial connection. Ridiculous. By that logic, it wouldn't be a P2P connection if IPs were initially exchanged by snail mail or carrier pigeon, or if DNS were used.
javajosh 3y ago
It's okay to make a distinction between transient and steady-state communications. If the steady-state is p2p then that's good enough for me. BTW I've never built one but I've read that WebRTC can connect browsers on a local LAN if they can see each other's IP address. (This is actually an experiment I'd one day like to do.)
- fulafel 3y ago
  Communicating between a group of computers on a LAN using IP doesn't have any limitations vs doing the same on the internet, so there's no reason it wouldn't work. (But yes I've tried it and it worked)
derefr 3y ago
Yes, nodes behind NAT must be able to already communicate through some kind of intermediary — at least initially (for STUN), but maybe the whole time (for TURN.) But this intermediary has very low requirements. It doesn't need to be mutually trusted by both parties, and it doesn't need any compute of its own for handling encryption/etc, just the ability to re-wrap opaque IP-packet payloads back and forth between ports. Any random low-power network switch could implement full-speed TURN. And anyone could also run a STUN or TURN server on a $2/mo VPS. And, beyond that, STUN/TURN servers also don't need to be protocol-specific; you can reuse a STUN/TURN server someone put up to help some other protocol. They're a global resource — even STUN/TURN servers established for non-WebRTC routing, can be reused for WebRTC routing, and vice-versa. This means that in-browser WebRTC protocols that rely on ICE, are both: • affordable to "enable" connectivity on (because any network or protocol likely has some backing foundation, which can easily afford enough ultra-cheap STUN/TURN nodes to ensure the network's operation; but even if they don't, the network can be designed to use existing STUN/TURN nodes established by p2p advocates like the EFF, acting as a free rider on those nodes; and even if you don't do that, either party, with at least $2 of motivation to communicate, can get a VPS [in a non-CGNATed country] and run their own STUN/TURN nodes on it.) • uncensorable in the weak sense (in that there's no central entity within the p2p network which can choose to deny you access to connectivity on the network.) (Mind you, your ISP might drop all your STUN/TURN -looking traffic; or you might not be able to acquire a non-CGNATed VPS IP address anywhere in your whole country... but this is not a problem for "p2p protocols" to solve; as, at that point, you're not on "the Internet" per se, but on a weird LAN that is willing to route IP packets to some whitelisted subset of the Internet. Solving for network-level censorship isn't the domain of "p2p protocols", but rather the domain of anti-censorship technologies, like Tor's hidden bridge nodes.) --- But I assume you don't really care about the practicality here, and are speaking more in the context of being an IPv6 public-routability maximalist. (Which, hey, I'm one of those too. Non-globally-routable addresses are silly.) Thus this: > You can build such a thing with WebRTC, but only if the nodes are not browser hosted and have public IPs. If you think that's useful then you're also confused. I do get why you say this — the naive counterargument is that phones on cellular networks are non-browser-hosted and have public IPs, and that therefore native mobile apps can act as both WebRTC and STUN/TURN servers. But of course, the cellular networks that aren't CGNATed, are all IPv6 networks. So this is no help to anyone whose ISP has only assigned them an IPv4 address behind a NAT. But there's an (IMHO much better) rebuttal, in the form of an emerging technology-trend, which you may not have considered: Desktop-as-a-Service (DaaS) nodes. If you run a browser on a cloud VM, then you get a browser with a public-routable IPv4 address, where that browser can then participate in a WebRTC network as a "supernode." Sure, if you're doing this with the goal of enabling STUN/TURN, then this is silly: you may as well just get the $2 VPS and run just the STUN/TURN servers on it. But my point is that many corporate employees just connect to some DaaS using thin-client hardware by default, and do everything on that DaaS (incl. using a browser); and so, as long as your protocol is likely to be used by any corporate workers, then your protocol does get its necessary supernodes — in the form of the browsers running on these workers' VMs — "for free."
amadeuspagel 3y ago
> So why does it exist? Answer: to reduce the cost to provide a service where bulk data flows are p2p. Also to lower latency.
- toast0 3y ago
  FWIW, lower latency is not guaranteed when going direct vs through a relay. There are way too many variables in routing. You've got to try it all ways and see. Ideally, you should try to measure the one way delay on each path and choose the 'best' path in each direction, but WebRTC tries to converge on the 'same' path for both directions (either relay both ways or direct both ways).
gfodor 3y ago
Sounds like you understand WebRTC yet take issue with describing it as a p2p-enabling technology. It is literally technology which enabled peer to peer connectivity in the browser. Without it, browsers would not be able to directly connect to one another over the Internet. These kinds of definition-focused posts on HN are always so tiresome.

Sean-Der 3y ago

What protocols/networks do you consider P2P? Every P2P technology I have used requires some bootstrapping. I have done WebRTC with zero signaling, but browser only one side[0]. I wish the w3c/ietf would care, but that’s the issue with corporate/profit driven standards! [0] https://github.com/pion/offline-browser-communication https://github.com/pion/offline-browser-communication

Uptrenda 3y ago
Bootstrapping is an interesting problem. If there's a large P2P network (think like Gnutella) there's papers that have proposed using port scanning of residential IP ranges to find peers that belong to the network. It's an interesting approach because there's no centralized bootstrapping servers. But, port scanning is inefficient and such an approach may only be viable if a network is large (I may be wrong here.) Still, I think it's cool how little work has been done on these problems. I am still really into p2p networks. For my own project I observed that all of the main networks in some way still depend on trusted introduction points. Just many of them and combined. So I think using infrastructure that's federated and open is a good design (in my case: public MQTT servers is what my own software is based on.)
convolvatron 3y ago
I think it's worth remembering that the original intent of the internet was entirely p2p and this bootstrapping issue wasn't a problem. In fact, there was a whole set of protocols developed around global multicast that allowed for discovery to build exactly these structures. So you can't blame the ietf for not thinking of this problem - you can blame them for not being able to respond well when the market went and mucked up their architecture by putting nat everywhere.

halfmatthalfcat 3y ago

You can do offline signaling. Quoting MDN: > It's any sort of channel of communication to exchange information before setting up a connection, whether by email, postcard, or a carrier pigeon. It's up to you. All you need are SDPs and ICE Candidates. People choose a centralized signaling server because it's the easiest but WebRTC does not dictate it be that way. Echoing the other commenter, there really is no other way to establish a connection without some knowledge of the other peer, be it gained online or offline.

keepamovin 3y ago
I experimented with implementing this manual signaling where the delay between back and forth could be dozens of seconds or even minutes. I found that you need to call restartIce, which is not typically called in SimplePeer and is not normally exposed. So as it currently stands, SimplePeer regular version that you can get from the package manager will not support signaling over dozens of minutes. It just won't work. But it can be made to work if you just call restart ICE, which keeps everything alive. I discovered this through my own research and experiments. And you can see the code below. And also, you can fork this repo and read the instructions to get a working version as well. I think the original idea was basically you can, like, be in your shell and you can run this repo and then you can be chatting with people who come to your GitHub repository. And, the signaling is done over comments and there’s sort of like a comment robot that facilitates that to make it easy. https://github.com/o0101/janus/ https://github.com/o0101/janus/ RestartIce: https://github.com/o0101/janus/blob/9b092218b7623ca198c3caefb840ba75ae86bc78/local-webrtc-backend/page.html#L284 https://github.com/o0101/janus/blob/9b092218b7623ca198c3caef...
ravenstine 3y ago
Exactly. This is trivial to carry out and can be done "by hand" between two browsers. I don't know what the OP is talking about. They are speaking as if the commonly chosen mode of bootstrapping a connection is fundamental to the entire communication cycle. It's flat out not true. When the connection has been established, peers are connected directly, but by their definition, this doesn't matter because a trusted peer was used to form the initial connection. Ridiculous. By that logic, it wouldn't be a P2P connection if IPs were initially exchanged by snail mail or carrier pigeon, or if DNS were used.

javajosh 3y ago

It's okay to make a distinction between transient and steady-state communications. If the steady-state is p2p then that's good enough for me. BTW I've never built one but I've read that WebRTC can connect browsers on a local LAN if they can see each other's IP address. (This is actually an experiment I'd one day like to do.)

fulafel 3y ago
Communicating between a group of computers on a LAN using IP doesn't have any limitations vs doing the same on the internet, so there's no reason it wouldn't work. (But yes I've tried it and it worked)

derefr 3y ago

Yes, nodes behind NAT must be able to already communicate through some kind of intermediary — at least initially (for STUN), but maybe the whole time (for TURN.) But this intermediary has very low requirements. It doesn't need to be mutually trusted by both parties, and it doesn't need any compute of its own for handling encryption/etc, just the ability to re-wrap opaque IP-packet payloads back and forth between ports. Any random low-power network switch could implement full-speed TURN. And anyone could also run a STUN or TURN server on a $2/mo VPS. And, beyond that, STUN/TURN servers also don't need to be protocol-specific; you can reuse a STUN/TURN server someone put up to help some other protocol. They're a global resource — even STUN/TURN servers established for non-WebRTC routing, can be reused for WebRTC routing, and vice-versa. This means that in-browser WebRTC protocols that rely on ICE, are both: • affordable to "enable" connectivity on (because any network or protocol likely has some backing foundation, which can easily afford enough ultra-cheap STUN/TURN nodes to ensure the network's operation; but even if they don't, the network can be designed to use existing STUN/TURN nodes established by p2p advocates like the EFF, acting as a free rider on those nodes; and even if you don't do that, either party, with at least $2 of motivation to communicate, can get a VPS [in a non-CGNATed country] and run their own STUN/TURN nodes on it.) • uncensorable in the weak sense (in that there's no central entity within the p2p network which can choose to deny you access to connectivity on the network.) (Mind you, your ISP might drop all your STUN/TURN -looking traffic; or you might not be able to acquire a non-CGNATed VPS IP address anywhere in your whole country... but this is not a problem for "p2p protocols" to solve; as, at that point, you're not on "the Internet" per se, but on a weird LAN that is willing to route IP packets to some whitelisted subset of the Internet. Solving for network-level censorship isn't the domain of "p2p protocols", but rather the domain of anti-censorship technologies, like Tor's hidden bridge nodes.) --- But I assume you don't really care about the practicality here, and are speaking more in the context of being an IPv6 public-routability maximalist. (Which, hey, I'm one of those too. Non-globally-routable addresses are silly.) Thus this: > You can build such a thing with WebRTC, but only if the nodes are not browser hosted and have public IPs. If you think that's useful then you're also confused. I do get why you say this — the naive counterargument is that phones on cellular networks are non-browser-hosted and have public IPs, and that therefore native mobile apps can act as both WebRTC and STUN/TURN servers. But of course, the cellular networks that aren't CGNATed, are all IPv6 networks. So this is no help to anyone whose ISP has only assigned them an IPv4 address behind a NAT. But there's an (IMHO much better) rebuttal, in the form of an emerging technology-trend, which you may not have considered: Desktop-as-a-Service (DaaS) nodes. If you run a browser on a cloud VM, then you get a browser with a public-routable IPv4 address, where that browser can then participate in a WebRTC network as a "supernode." Sure, if you're doing this with the goal of enabling STUN/TURN, then this is silly: you may as well just get the $2 VPS and run just the STUN/TURN servers on it. But my point is that many corporate employees just connect to some DaaS using thin-client hardware by default, and do everything on that DaaS (incl. using a browser); and so, as long as your protocol is likely to be used by any corporate workers, then your protocol does get its necessary supernodes — in the form of the browsers running on these workers' VMs — "for free."

amadeuspagel 3y ago

> So why does it exist? Answer: to reduce the cost to provide a service where bulk data flows are p2p. Also to lower latency.

toast0 3y ago
FWIW, lower latency is not guaranteed when going direct vs through a relay. There are way too many variables in routing. You've got to try it all ways and see. Ideally, you should try to measure the one way delay on each path and choose the 'best' path in each direction, but WebRTC tries to converge on the 'same' path for both directions (either relay both ways or direct both ways).

gfodor 3y ago

Sounds like you understand WebRTC yet take issue with describing it as a p2p-enabling technology. It is literally technology which enabled peer to peer connectivity in the browser. Without it, browsers would not be able to directly connect to one another over the Internet. These kinds of definition-focused posts on HN are always so tiresome.