? Peers Still Connecting After Program Exit

[Guest]

Hi,

Is there a way to get peers to stop connecting after quitting the program? After the program is closed (no more server on that port), other clients continue to try to connect—which of course is pointless since the client is no longer running.

Is there a way to stop this? Doesn't/shouldn't the client broadcast some sort of "goodbye" when it exits to the tracker/DHT/whatever so that other clients know not to connect to it anymore and remove it from the peer list?

[DreadWingKnight]

It takes time for that "goodbye" to make it all the way out.

[Ultima]

No, no way to stop this. Peers cache IPs -- unless you tell all peers to stop caching IPs, you'll need to live with this. Disabling DHT (if you have it enabled) should alleviate matters at least slightly.

Saying goodbye assumes you know everyone in the swarm -- you don't. Besides which, it's a ton of protocol overhead just to say goodbye to potentially thousands of users, or to receive tons of goodbyes from the tons of peers disconnecting from the swarm at any given second.

[Guest]

Makes sense. But what happens when someone tries to connect to you after you've quit? Do they try again or do they remove you from their list?

So to clarify: When you connect to the tracker, it adds you to a list of connected peers and you retrieve a list of others in the swarm and add it to your own cache. Others find out about you and add you to their cache when they update the tracker. If you disconnect, they may still have you in their list, so they will try to connect. Correct?

But when you properly quit the program, isn't some sort of goodbye sent to the tracker so that it removes you from its list? That way, when others update from the tracker, you should be removed.

[Ultima]

Yes, a stop event is sent to the tracker on stop, but trackers don't tell peers when to remove other peers from their cache either. Trackers don't normally provide peers with the full peer list either, so it can't be determined whether a peer actually left the swarm, or if the tracker simply omitted the peer from the sent list.

Whether your IP gets removed from the peer cache is client-dependent. A "smart" client should probably try a few times, increasing the attempt interval every time it fails to connect, and after it reaches a certain threshold, it simply remove the peer from the cache. I'm guessing most clients already do this, but because of the nature of BitTorrent, the number/rate of connection attempts is magnified.

[Guest]

Bleh. I guess I can't blame Bram for not having forseen everything when he first invented the protocol; certainly not the scale and magnitude that it all is now.

It's just annoying because I can see people trying to connect on the µTorrent port even a day later. :|

[Firon]

Why is it even a concern?

[Guest]

It adds clutter when trying to do troubleshooting or diagnosis. For example, recently I was trying to figure out why an app's updater wasn't working, and the peers trying to connect (even though I had quit µTorrent many hours earlier) cluttered up the display, so I had to sift through the activity to find the relevant connections.

Besides, do you like having strangers constantly pinging you when you're not using it? Spam, telemarketers, etc. aren't concerns either, you can ignore them, until they come en masse when not wanted. Plus they put unnecessary wear and tear and heat on my poor little router. Fortunately my modem has a suspend button, so that'll help in some situations.