4 ms·
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 pr
by 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 agoPretty 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 agoThat'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.