Jump to content

Mainline DHT and UDP


Klaus_1250

Recommended Posts

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 months later...

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.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...