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

Cloudflare Calls

blog.cloudflare.com

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Cloudflare Calls

#101

Post by solardev »

rixthefox wrote: post #7

They really do want to be the center of everything it seems. I wish they would stop trying to be the Cisco of Networking in the sense of trying to convince a lot of people to let them handle critical network functions for a ton of networks. All it will take is one major outage for everyone to see this is a bad idea. Why trust a cloud provider who could go down and take half the Internet with it? Why centralize it tha…

Isn't that what AWS, Google, Azure, etc. have done forever? Cloudflare is easier to use, and IMO, just plain better.

It's actually kinda nice to have half the internet go down at once. People can just stop work, wait a few minutes, and it magically comes back up. Making downtime somebody else's problem is a huge advantage...

Re: Cloudflare Calls

#102

Post by ethbr0 »

robertlagrant wrote: post #20
nine_k wrote: post #15

Earlier quoted context omitted.

It reminds me the days of Google flourishing in early 2000s: they added more and more wonderful stuff (such as mail, or maps) while improving their flagship offering, search, more and more. A lot of people were their sincere fans.

Sort of agree, except Cloudflare's new products all seem to scale nicely off their core competencies, so they can offer them more cheaply and (hopefully) more reliably. Maps and mail were more like "ways of getting to know you really really well".

That's why I've been really impressed with their strategic execution: they seem to have a pretty laser focus on "Given what we already have now, and how much it costs to operate, what can we do that Amazon/Google/Microsoft can't easily duplicate at a competitive price point?"

With a healthy dash of "What are people actually trying to accomplish?"

The weakness at hyperscale is that all products feel like some mistranslation of the generalized form of an HR request: almost for everyone, but perfect for no one. Probably because nothing less than a TAM of "everyone" moves their revenue needle.

Re: Cloudflare Calls

#103

Post by kwindla »

I'd love to know more about

> Calls uses anycast for every connection, so every packet is always routed to the closest Cloudflare location.

Is this true for the UDP media (and data channels) traffic, or just for the initial signaling and connection setup?

If the UDP traffic is all anycast, that's truly impressive engineering work. Bravo!

Re: Cloudflare Calls

#104

Post by mmastrac »

kwindla wrote: post #103

I'd love to know more about > Calls uses anycast for every connection, so every packet is always routed to the closest Cloudflare location. Is this true for the UDP media (and data channels) traffic, or just for the initial signaling and connection setup? If the UDP traffic is all anycast, that's truly impressive engineering work. Bravo!

Is anycast "just" (!) broadcasting different routes for different parts of the internet for the same IP address? I cannot imagine this is trivial to get right at all.

Re: Cloudflare Calls

#105

Post by treis »

lnsp wrote: post #18
Xeoncross wrote: post #13

> "With a traditional WebRTC implementation, both the patient and therapist’s devices would talk directly with each other, leading to exposure of potentially sensitive data such as the IP address... When using Calls, you are still using WebRTC, but the individual participants are connecting to the Cloudflare network. If four people are on a video call powered by Cloudflare Calls, each of the four participants' device…

As far as I understood it: the premise of added security is based on the fact that the other WebRTC peers only see Cloudflare's IP instead of your own. Also nobody knows who you are exactly talking to except Cloudflare. I would still expect that the media channels itself still remain encrypted when even when multiplexed by Cloudflare's network. edit, yes it's encrypted: > Finally, all video and audio traffic that pas…

It doesn't say that Cloudflare can't or doesn't access the encrypted data. It seems to be written in a way that everyone would assume they can't but AFAICT it doesn't explicitly say it. Which makes me think they phrased it like this for a reason but I definitely could be wrong.

Re: Cloudflare Calls

#106

Post by jnwatson »

teddyh wrote: post #12
dewey wrote: post #8

Earlier quoted context omitted.

I'm really getting tired of this kind of take. You never really see that if AWS adds a product, or GCP adds a product or any other products from bigger CDNs. What do you suggest? Cloudflare should stop releasing products? Regulation that you are only allowed to handle x% of the total internet traffic?

> You never really see that if AWS adds a product, or GCP adds a product or any other products from bigger CDNs. Accusations of hypocrisy is not an argument. Instead of accusing me (and all other detractors) of not criticizing others enough, please elaborate why this isn’t what I described. Cloudflare (and others) keep releasing products which makes their central role more central and less vulnerable to competition.…

From that line of argument, we should really get folks off Linux. And nginx.

Re: Cloudflare Calls

#107

Post by onetimeusename »

rixthefox wrote: post #7

They really do want to be the center of everything it seems. I wish they would stop trying to be the Cisco of Networking in the sense of trying to convince a lot of people to let them handle critical network functions for a ton of networks. All it will take is one major outage for everyone to see this is a bad idea. Why trust a cloud provider who could go down and take half the Internet with it? Why centralize it tha…

what you say makes sense and even I doubt that cloudflare will remain committed to being content neutral even if they want to be, a different issue. Government can get corporations to do what they want.

However, people continue to use cloudflare because it is easy, solves problems people don't like dealing with, and does the job. I don't know what the alternative pitch is to businesses so that cloudflare isn't so central to the internet.

Re: Cloudflare Calls

#109

Post by dirheist »

onetimeusename wrote: post #107
rixthefox wrote: post #7

They really do want to be the center of everything it seems. I wish they would stop trying to be the Cisco of Networking in the sense of trying to convince a lot of people to let them handle critical network functions for a ton of networks. All it will take is one major outage for everyone to see this is a bad idea. Why trust a cloud provider who could go down and take half the Internet with it? Why centralize it tha…

what you say makes sense and even I doubt that cloudflare will remain committed to being content neutral even if they want to be, a different issue. Government can get corporations to do what they want. However, people continue to use cloudflare because it is easy, solves problems people don't like dealing with, and does the job. I don't know what the alternative pitch is to businesses so that cloudflare isn't so cen…

Yeah, also for cloudflares core business proposition (ddos mitigation and DNS forwarding/filtering) you need to be massive and to have multiple PoP's in order to assess whether or not a certain IP requesting a certain URL and sending over a certain length of packets should be accepted or whether a challenge should be served. You can't know any of these things unless you have an extensive network and clients.

Re: Cloudflare Calls

#110

Post by davidz »

kwindla wrote: post #103

I'd love to know more about > Calls uses anycast for every connection, so every packet is always routed to the closest Cloudflare location. Is this true for the UDP media (and data channels) traffic, or just for the initial signaling and connection setup? If the UDP traffic is all anycast, that's truly impressive engineering work. Bravo!

Speculating here, but I would read this as "anycast" as a concept, where each user is connected to the closest location. versus anycast as in the IP protocol. The complexity far outweighs benefits with routing each UDP packet to different servers within the same session.
Post reply on HN