4 ms·

Things like CDN and DoS protection: you'll need to operate massive networks and machines distributed around the globe. Until someone creates a well-thought dec

Things like CDN and DoS protection: you'll need to operate massive networks and machines distributed around the globe. Until someone creates a well-thought decentralized CF alternative from the ground up, which solves bad actor, slow and unstable node problems, with clever incentives, et cetera et cetera, we'll be stuck with centralized solutions.

bawolff 4y ago
Decentralized solutions here don't really make sense. CFs entire value proposition is around being close enough to users you can shave something like 20ms off your latency. P2P is a lot of things, but latency optimized is definitely not it. Things like DHT involve lots of hops, you also can't control the quality of nodes.
- vineyardmike 4y ago
  This is a unique case where it could make sense... if the value proposition is having a server in every region/city, then a decentralized solution could work. A blockchain is slow and problematic but if you could incentivize "seeders" to be the entire file, you could get that regionalization. It'd never work because you'd need to handle the routing, and you can't practically do that safely. I'd never open my domain to be hosted by a variety of 3rd parties.
  - bawolff 4y ago
    The value proposition isn't just a server in every city, but a highly optimized reliable low latency server. I understand why you thought of blockchain when i said p2p has bad latency. Blockchain of course has latency that is beyond terrible, but that is not what i was thinking of. I was thinking of bit torrent. Bit torrent is amazingly fast for a bulk download once it gets going, but is really slow to get going. Even just figuring out which nodes have your files is unacceptably slow for this usecase with the current distributed technologies (DHT). CDN is all about serving small static files with very low latency. P2P simply involves too many layers of indirection to work for that use case. I also don't see a way around it without centralizing things. As far as security goes. Its actually not that bad and largely a solved problem using combinations of digital signatures and hashes. (Preventing DoS is a bit trickier although i think there are solutions for that albeit probably ones that prevent using geolocated nodes)
    - anacrolix 4y ago
      It has some small latency but only when resources are spread across many different infos. If you can constrain your resources to a single DHT traversal, it's pretty quick. I run several services that stream from BitTorrent on demand, using https://github.com/anacrolix/torrent https://github.com/anacrolix/torrent which are surprisingly quick to start. However it does choke up when you try to start many different resources at once, which multiplies horizontally the number of DHT traversals, and per-torrent related overhead to get started. It is solvable, but any solution that spreads resources out across many different targets in the DHT is slow. Basically anything that was inspired by BitTorrent, but isn't BitTorrent itself does this, because they get overly excited by deduplication of data.
      - bawolff 4y ago
        Pretty quick is not good enough for this use case. I imagine even a single dht traversal is an order of magnitude too slow. CDNs try and solve the "speed of light is too slow" problem. To make sense they have to respond to queries faster than a central server would (or a small number of geodistributed servers would). Otherwise the CDN does not bring value. DHT traversal is usually log(n) in number of nodes. It seems unlikely that will ever be fast enough to compete with just hosting your stuff in one central data center even if your data center is on the opposite side of the earth. This is a use case where 20ms can determine if the solution makes sense or not.
        anacrolix 4y ago
        That's fair. In this instance DHT traversal is equivalent to a really slow DNS lookup. I really don't think you can expect better than 2-3s in the BitTorrent implementation, and 5-10s on average.

bawolff 4y ago

Decentralized solutions here don't really make sense. CFs entire value proposition is around being close enough to users you can shave something like 20ms off your latency. P2P is a lot of things, but latency optimized is definitely not it. Things like DHT involve lots of hops, you also can't control the quality of nodes.

vineyardmike 4y ago
This is a unique case where it could make sense... if the value proposition is having a server in every region/city, then a decentralized solution could work. A blockchain is slow and problematic but if you could incentivize "seeders" to be the entire file, you could get that regionalization. It'd never work because you'd need to handle the routing, and you can't practically do that safely. I'd never open my domain to be hosted by a variety of 3rd parties.
- bawolff 4y ago
  The value proposition isn't just a server in every city, but a highly optimized reliable low latency server. I understand why you thought of blockchain when i said p2p has bad latency. Blockchain of course has latency that is beyond terrible, but that is not what i was thinking of. I was thinking of bit torrent. Bit torrent is amazingly fast for a bulk download once it gets going, but is really slow to get going. Even just figuring out which nodes have your files is unacceptably slow for this usecase with the current distributed technologies (DHT). CDN is all about serving small static files with very low latency. P2P simply involves too many layers of indirection to work for that use case. I also don't see a way around it without centralizing things. As far as security goes. Its actually not that bad and largely a solved problem using combinations of digital signatures and hashes. (Preventing DoS is a bit trickier although i think there are solutions for that albeit probably ones that prevent using geolocated nodes)
  - anacrolix 4y ago
    It has some small latency but only when resources are spread across many different infos. If you can constrain your resources to a single DHT traversal, it's pretty quick. I run several services that stream from BitTorrent on demand, using https://github.com/anacrolix/torrent https://github.com/anacrolix/torrent which are surprisingly quick to start. However it does choke up when you try to start many different resources at once, which multiplies horizontally the number of DHT traversals, and per-torrent related overhead to get started. It is solvable, but any solution that spreads resources out across many different targets in the DHT is slow. Basically anything that was inspired by BitTorrent, but isn't BitTorrent itself does this, because they get overly excited by deduplication of data.
    - bawolff 4y ago
      Pretty quick is not good enough for this use case. I imagine even a single dht traversal is an order of magnitude too slow. CDNs try and solve the "speed of light is too slow" problem. To make sense they have to respond to queries faster than a central server would (or a small number of geodistributed servers would). Otherwise the CDN does not bring value. DHT traversal is usually log(n) in number of nodes. It seems unlikely that will ever be fast enough to compete with just hosting your stuff in one central data center even if your data center is on the opposite side of the earth. This is a use case where 20ms can determine if the solution makes sense or not.
      - anacrolix 4y ago
        That's fair. In this instance DHT traversal is equivalent to a really slow DNS lookup. I really don't think you can expect better than 2-3s in the BitTorrent implementation, and 5-10s on average.