Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebRTC: Not Quite Magic

alexfreska.com

Post reply on HN
Print view View original

11–20 of 58 posts

Re: WebRTC: Not Quite Magic

#11

Post by sktrdie »

caio1982 wrote: post #8

While I think WebRTC is so fantastic it's nearly magical, I find it incredible how people using/creating it overlook networks' topologies problems that SIP and other VoIP folks already had to deal with (and went crazy doing so) a whole decade ago. NAT issues, STUN, all that is long known and yet I've never seen a fully working solution for peer-to-peer communication that won't be stopped by the simplest firewalls. Do…

I think that's the whole point of firewalls, to control incoming and outgoing connections. So peer-to-peer sometimes is simply impossible. TURN actually is just a proxy as far as I know so it's not p2p.

That's why BitTorrent asks to open specific ports in your router, because otherwise you simply can't do p2p.

Re: WebRTC: Not Quite Magic

#12

Post by AshleysBrain »

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use NAT, and either ignored peer-to-peer connections or went ahead and broke them anyway. This makes innovation with peer-to-peer tech more difficult and expensive, because now to get things working for everyone you need to configure additional relay servers and pay for the bandwidth of everyone who needs to use it. That could rule out some services being made free and could mean the extra cost being passed on to customers when it could have just run through their ISPs.

I think the solution is IPv6. Once every device on the Internet is uniquely addressable again, we can do away with these NAT hacks and two endpoints should be able to reliably connect to each other again, no matter where they are. Of course, that's assuming we don't get more short-sighted engineering that breaks things again...

Re: WebRTC: Not Quite Magic

#13

Post by alexfreska »

AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

Yeah IPv6 is valuable but it seems NAT is the smallest inconvenience since a p2p connection can usually still be made. Briefly giving it thought, I don't think IPv6 could rid the use of TURN servers or close the other 5% of anomalies. Am I wrong?

Re: WebRTC: Not Quite Magic

#14

Post by geocar »

AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

NAT has been around for twenty years now, so there's no excuse for having anything less than robust, any-direction-any-path in every new protocol. I'm honestly more than a bit disappointed that WebRTC has pushed this down into the application leaving every application to work it out for itself.

The smart thing to do would have been to make the signalling layer use IPv6 and insist on configured 6in4-configured gateways (or similar).

Re: WebRTC: Not Quite Magic

#15

Post by lallysingh »

higherpurpose wrote: post #6

I'm interested in the security of WebRTC. Is it end to end? Can it be easily MITMed? What are its main flaws from a security design point of view?

It's end-to-end, but you need a way to validate that you're talking to the peer that you think that you are - there's no certificate authority verifying client certs (in the normal case, I haven't explored traditional client-side certs for webrtc).

Re: WebRTC: Not Quite Magic

#16

Post by AshleysBrain »

geocar wrote: post #14
AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

NAT has been around for twenty years now, so there's no excuse for having anything less than robust, any-direction-any-path in every new protocol. I'm honestly more than a bit disappointed that WebRTC has pushed this down into the application leaving every application to work it out for itself. The smart thing to do would have been to make the signalling layer use IPv6 and insist on configured 6in4-configured gateway…

Maybe NAT has been around a long time but there is still a lot of broken NAT, e.g. symmetric NAT on corporate networks (where one user might appear to come from two different IPs from the outside). This is not WebRTC's fault, it makes any peer-to-peer connections over the Internet hard, and given IPv6 adoption stands at around 3% right now insisting on IPv6 support would probably have been sufficient to prevent widespread adoption.

Re: WebRTC: Not Quite Magic

#17

Post by AshleysBrain »

alexfreska wrote: post #13
AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

Yeah IPv6 is valuable but it seems NAT is the smallest inconvenience since a p2p connection can usually still be made. Briefly giving it thought, I don't think IPv6 could rid the use of TURN servers or close the other 5% of anomalies. Am I wrong?

NAT only exists to workaround IPv4 address exhaustion. I think it's more likely the 5% edge cases have firewalls that block anything that doesn't look like normal HTTP traffic.

Re: WebRTC: Not Quite Magic

#18

Post by rdtsc »

caio1982 wrote: post #8

While I think WebRTC is so fantastic it's nearly magical, I find it incredible how people using/creating it overlook networks' topologies problems that SIP and other VoIP folks already had to deal with (and went crazy doing so) a whole decade ago. NAT issues, STUN, all that is long known and yet I've never seen a fully working solution for peer-to-peer communication that won't be stopped by the simplest firewalls. Do…

Because of low barrier to entry people who didn't learn about jitter, network latencies, BSD sockets, etc.

That is the promise of WebRTC -- just a few lines of JS and you've got yourself Google- Hangouts.

One can argue this happens in web frameworks and other technologies that make it easy to get started with, which is a good thing.

But unfortunately a lot of these easy abstractions can't completely abstract away things like speed of light latencies, limitation of network bandwidth, funky NAT setups and so on.

So far there are very few peer peer technologies that work reliably and are successful.

Re: WebRTC: Not Quite Magic

#19

Post by geocar »

AshleysBrain wrote: post #16
geocar wrote: post #14

Earlier quoted context omitted.

NAT has been around for twenty years now, so there's no excuse for having anything less than robust, any-direction-any-path in every new protocol. I'm honestly more than a bit disappointed that WebRTC has pushed this down into the application leaving every application to work it out for itself. The smart thing to do would have been to make the signalling layer use IPv6 and insist on configured 6in4-configured gateway…

Maybe NAT has been around a long time but there is still a lot of broken NAT, e.g. symmetric NAT on corporate networks (where one user might appear to come from two different IPs from the outside). This is not WebRTC's fault, it makes any peer-to-peer connections over the Internet hard, and given IPv6 adoption stands at around 3% right now insisting on IPv6 support would probably have been sufficient to prevent wides…

I'm not convinced.

WebRTC is supported by huge corporations with massive resources. If they had decided to use IPv6 instead of SDP for addressing, I can't imagine there would be any difficulty in user adoption, and they could only improve service adoption.

Re: WebRTC: Not Quite Magic

#20

Post by simon_vetter »

AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

Work is in progress to make webrtc implementations work over ipv6 but it's not ready yet. Chrome 34 will implement it behind a feature flag (googIPv6:true) [1], and hopefully Firefox will follow suit.

When they do, most pain points caused by NATs will go away, and that's not webrtc specific. While you'll always encounter some (intentionally?) broken network which only allows 80/tcp and 443/tcp from time to time, there's not much you can do about it, and webrtc can't do much about it.

[1] http://code.google.com/p/webrtc/issues/detail?id=1406

Post reply on HN