Klaus_1250 Posted July 4, 2006 Report Posted July 4, 2006 As most know, the current Mainline DHT has the disadvantage that after turning it off, you keep getting tons of small packets for days (well over a week). It is not so much a problem, but an annoyance (unless you have a very small datalimit or crappy soft-/hardware). However, why is it that KAD (emule DHT) does not have the same issues? I can connect to a thousand nodes on KAD, then disconnect and the next day, I see zero KAD packets. If I do the same with Mainline DHT, the next day I still see at least one DHT packet every two seconds...
Ultima Posted July 4, 2006 Report Posted July 4, 2006 Maybe they inform peers that you disconnect in Kademlia, but not mainline DHT.
Klaus_1250 Posted July 5, 2006 Author Report Posted July 5, 2006 It does seem so in KAD and not Mainline. But at the same time, Mainline DHT clients also don't seem to implement any technologies to inform themselves that nodes are offline / not available? And that is curious. KAD/eMule is a network you usually connect to for prologned periods of time, while BT is more a snatch-seed-and-go network with shorter connection times on average. You'd expect the situation to be the opposite.
Ultima Posted July 6, 2006 Report Posted July 6, 2006 That's probably just the problem then, there'd be too many connects and disconnects for anyone to care about.
Klaus_1250 Posted July 7, 2006 Author Report Posted July 7, 2006 That would be an odd way of reasoning, too many connects and disconnects to care about. That would imply that there is a design error in the implementation itself. Again, for me it isn't a problem, I don't have a datalimit. But people who have, wireless ISP's, or ISP who change there customers IP often, will care. If some uses a a BT-client once a week for about 8 hours with DHT enabled, it will costs them 400MB + a month. There are still people out there who have to live on 500 MB - 1 GB of data a month and I doubt they realize how costly the mainline DHT is.
Ultima Posted July 7, 2006 Report Posted July 7, 2006 What I meant was that BitTorrent users tend to disconnect/reconnect much more often than eMule users, and that all the disconnect/reconnect messages would create more traffic than currently (without the constant informing of disconnects), not some kind of design error in the implementation.
Klaus_1250 Posted July 8, 2006 Author Report Posted July 8, 2006 OK, sorry, well, that's indeed a good point. But in that case, shouldn't sources/nodes/ip's in DHT time-out more quickly? Or at least stop sending packets if I send back an ICMP Host/Port Unreachable.
Ultima Posted July 8, 2006 Report Posted July 8, 2006 Maybe they should timeout more quickly, but that's probably up to the client to decide -- it might not've been defined in the specifications.
Firon Posted July 11, 2006 Report Posted July 11, 2006 eMule doesn't seem to cache Kad peers for that matter.
Klaus_1250 Posted September 29, 2006 Author Report Posted September 29, 2006 Sorry to kick up an old thread, but I might have some more insight what may help cause the excess DHT UDP packets. Apperently, there are at least two issues with several routers: * Very limited routing tables, e.g. only support 256 or 512 connections, which quickly fill up if they implement UDP statefull inspection (which is likely), leading to many lost inward UDP packets (replies). In the Netherlands, at least one hundred thousand people use adsl-routers (KPN Experia Box or Siemens SX551/552) which suffers from this issue.* Routers/Firewalls/Users not using Statefull Inspection for UDP packets.In both cases, even though UDP packets flow out, only a very limited or none will flow in, which probably lead to clients sending out (not sure how DHT/UDP is implemented) excess UDP packets. I think it should be doable to either implement a limit for UDP connections (which can be enabled/disabled) or use a small subroutine which recognizes when there are no incomming UDP packets or outward UDP packets stop getting replies (in case that is expected behaviour) or perhaps even use a single UDP port for incomming and outgoing UDP packets (too that is likely to be much work). Even though this is not an issue in uTorrent or DHT itself, I think the number of poor routers which uTorrent has to work behind justifies a fix.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.