4 ms·
Does this create a new DHT entry per tweet or per user ? I think the DHT itself can quickly become overloaded/slow - DHT does impose some b/w overhead for each
by yazriel 11y ago
Does this create a new DHT entry per tweet or per user ?
I think the DHT itself can quickly become overloaded/slow - DHT does impose some b/w overhead for each node
- sktrdie 11y agoOne DHT entry per tweet. I do agree that it does create overload on the DHT. Initially in fact I was looking at implementing it as such: https://github.com/bittorrent/bittorrent.org/issues/19#issue-110508430 https://github.com/bittorrent/bittorrent.org/issues/19#issue... Problem is that you don't get the "hosting" effect that you get with the DHT so you always need a peer seeding your feed or else it won't be reachable. Anyway, I hope others take on the challenge of implementing alternatives looking at different methods.
- yazriel 11y agoActually - i have been playing around with building a feed on top of a single torrent - so it would be one torrent per user - and subscribers to the torrent would (hopefully ;)) get a feed of updates Could this interest u ?
- brokenmachine 11y agoI have always thought that it would be great if the original uploader of a torrent could (securely) modify the torrent so it could have multiple versions, ie if they found one file was corrupt they could update just that file, or add more files (say it was a TV series, they could just keep updating the original torrent with the new episodes). And when you connected to the DHT it could ensure you had the latest version. Of course it would add complexity and I'm not sure how torrent indexing sites would cope but it could be cool. Signed torrents with versioning.
- juanpabloaj 11y agoyou have some example about this?
- yazriel 11y agoyep.. seems to work in alpha.. No changes required to other DHT node. Which is cool. And i was specifically aiming for a low/scalable bandwidth overhead Each new "announce" propagation is kinda slow.. 1-10min to spread through the DHT..