Jump to content

Impact of DHT on network-performance


Klaus_1250

Recommended Posts

I haven't used µTorrent for about 6 hours, and with DHT enabled about 3 days ago, yet, I'm still seeing incoming UDP-packets to µTorrents TCP/UDP port about 1 every 3 seconds? When will it stop?

I'm behind a broadband connection, so, for me it doesn't have any impact. But what for people behind a dialup-connection or budget-DSL/Cable connection? Or what if I were to check µTorrents random port option? Would those packets keep coming in on all those different ports?

Link to comment
Share on other sites

I still receive SYNs for a port I haven't used in over a month (with a different client). One of the weekly video blog trackers I frequent appears to never expire its peer list. Another tracker I use expires its peer list before its suggested update interval. There are some really brain-dead trackers out there.

Link to comment
Share on other sites

I still receive SYNs for a port I haven't used in over a month (with a different client).

Seen the same thing. I really wonder which clients exhibit that awfull behaviour. Never thought I would say this, but I'm glad I get a node-move every few months.

Doesn't the random port fuction just set a new port on every startup rather than every piece of data sent?

Yes, it does. But that means that the port used for DHT also changes every startup. If I still get packets for DHT, three days after I used it, it would mean that if I used the random port option and restarted uTorrent everyday for three days, the third day I would be getting DHT-traffic on three ports :-s.

It really makes me wonder, but when do clients using DHT stop sending DHT-UDP packets to a specific host/port? Do they react to ICMP 3,1's or 3,3's to remove hosts/ports from DHT? Most of them seem not to, or worse, their firewall blocks ICMP's. How does DHT handle when both sides block ICMP's? (e.g. work in stealth mode, which is rather populair among personal firewalls).

I asked this very question on several other p2p-forums, but never got a technical reaction or explanation :-(

Link to comment
Share on other sites

Reminds me of a somewhat related incident a few years ago. Cox Cable decided to start using icmp echo packets to determine whether or not their DHCP server could reallocate your IP address to someone else. No response? Boom, no IP. That was fun to figure out. They abandoned that scheme.

Link to comment
Share on other sites

Bandwidth is low, yes. But if you are receiving those packets over a dozen ports (which may (?) happen if you randomly alocate ports each session), it would become noticable for low-bandwidth connections. Next to that, it is not efficient. Don't forget those packets need to travel through a dozen routers and firewalls.

Link to comment
Share on other sites

Not likely, the packets you would receive would be far fewer in number than when you were on the DHT network. Even on a 56k it shouldn't make a difference.

Also, because it uses UDP, the packet would much smaller. It'd also be ignored, no response would ever be sent (ICMP or otherwise), and after a bit of time the client that sent it would just mark you as failed and not try again unless it saw you re-integrate into the network, I imagine.

ICMPs don't have anything to do with this, blocked or not.

Anyway, the reason you get hits is because you get cached in their DHT node list since you were active at one point. Then when they reconnect or update or whatever, they'd try to send you a request or something to see if you still exist on the DHT network. The impact really is minimal.

Link to comment
Share on other sites

It'd also be ignored, no response would ever be sent (ICMP or otherwise), and after a bit of time the client that sent it would just mark you as failed and not try again unless it saw you re-integrate into the network, I imagine.

ICMPs don't have anything to do with this, blocked or not.

They have. I someone send an UDP-packets to a closed port, the network-stack will reply with an ICMP 3.1 (Destination Unreachable, Port Closed) or if you computer is off, an ICMP 3.1 (Destination Unreachable, Host Not Reachable).

Th problem with UDP-packets is, that they are not reliable. Therefore, hosts usually not send 1 UDP-message, but several if they don't get a reply (to the UDP-ping of DHT for example). An ICMP 3.3 or 3.1 would prevent this.

Link to comment
Share on other sites

http://www.sockets.com/ws2_stat.htm#TCPIP says about Winsock 2:

Does not report ICMP Errors: None of the Microsoft stacks report WinSock errors upon receipt of ICMP error messages. For example, when an application sends a UDP datagram (with a SOCK_DGRAM socket) to a system that doesn't have a socket bound to the destination port for the datagram, the system responds with an ICMP Destination Unreachable (Port Unreachable). This would be very useful information to the sending application (which should get a 10061, WSAECONNREFUSED), since it would indicate the intended recipient didn't receive the datagram. In Tim Moore's 11/26/97 report, he indicated that NT5 would fix this, but Win95 and Win98 would continue to have this problem.

Also the quote points to http://www.sockets.com/ws2_stat.htm#ICMP_UnReach which has a resolution for getting some ICMP errors to application level:

As Dave Gravereaux discovered, it is possible to receive many ICMP Error messages, including "Port Unreachables" by using a raw ICMP socket (e.g. socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) and calling bind() with reference to INADDR_ANY as the address. It cannot receive all ICMP datagrams, however (e.g. it doesn't see Echo Requests sent to the machine it's running on), and it tends to miss a lot of them when many are received in succession.

I doubt any of current torrent clients and trackers which implement UDP take these into account, thus likely to leave inactive peers in tracker/peer exchange/DHT lists.

Link to comment
Share on other sites

with just DHT running my download is about .1 kB.. not much to frown upon. :D

Depends on how you look at it. I receive 1 UDP packet per 2 seconds. Adding that up to a day, means about 4.5 to 5 MB down, plus about the same back up to the host as ICMP. That's 10MB, per day, in total. And I haven't used DHT for at least 24 hours.

How many DHT-users are there???

I don't mind DHT using bandwidth, I do mind that it doesn't seem to stop. Sending a UDP-ping every 2 second reminds me of early times on G2, which also had the tendancy to send massive amounts of UDP-ping-packets. Though they never lasted this long in these numbers.

Link to comment
Share on other sites

Yes, there will be upstream. I'm talking here about a situation where:

- µTorrent or µTorrent is not running.

- µTorrent port is forwarded (NAT).

If you send an UDP-packet (or TCP for that matter) to a host that is not up or for which the destination port is unreachable, the host/router (not µTorrent itself!) will respond to an UDP-packet with an ICMP type 3 packet. The only time a host/router will not respond is when it has a firewall in Stealth mode. (I never recommand this since it essentially slows down networking) Since I manually forwarded µTorrents port on the router (UPnP would not make a difference since µTorrent does not remove the portmapping), my router will always send out an ICMP-packet if µTorrent is not running.

I know UDP packets are smaller than TCP. The above calculation is based on a packet size of 120 bytes (for both UDP and ICMP). Actually, the average packet-size is a bit more, but I used 120 for convinience.

I also know it is inevitable, BUT, sending UDP-pings every two seconds for over 24 hours after any DHT-activity is just plain wrong. It can only point to that somewhere, something has a bug. Sources should time-out not more than 24 hours after activity. Also, there should be some back-off algorithm, reducing the number of UDP-pings over time. That is done on any p2p-network.

But, I don't know if this is something by design (I can't imagine) or a bug in some client. I noticed someone in the bug-database mentioning that there was a client that did not expire sources well causing somewhat small DDoS-issue's.

Link to comment
Share on other sites

Setting your software firewall to allow incoming data ONLY on the currently selected uT port & outgoing data from any port - may reduce some of the outgoing activity, for "previously" chosen uT ports. If you use a router - it might have similar firewall ability as well.

Link to comment
Share on other sites

with just DHT running my download is about .1 kB.. not much to frown upon. :D

Depends on how you look at it. I receive 1 UDP packet per 2 seconds. Adding that up to a day' date=' means about 4.5 to 5 MB down, plus about the same back up to the host as ICMP. That's 10MB, per day, in total. And I haven't used DHT for at least 24 hours.

How many DHT-users are there???

I don't mind DHT using bandwidth, I do mind that it doesn't seem to stop. Sending a UDP-ping every 2 second reminds me of early times on G2, which also had the tendancy to send massive amounts of UDP-ping-packets. Though they never lasted this long in these numbers.[/quote']

eh, I could care less, as long as it doesn't download that 10mb at one time, I'm happy.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...