"Rejecting peer because already have a peer with the same id" after node restart

[jackpal]

A bug report by email:

When one node has downloaded a file and removes the file.
After this, when this node reboots Taipei-Torrent and downloads same file again.
It prints "Rejecting peer because already have a peer with the same id" and will create a empty file that same size with original file.

[jackpal]

Discussion:

I'm guessing that what's happening is:

Node A is serving
Node B connects to A
Node B crashes
Node B tries to reconnect to A.
Node A rejects the reconnection because it hasn't expired the original connection from node B.

This is probably normal behavior, since it takes TCP/IP a while to notice that crashed connections are timed out. but we could review the code to see if there's any way for Node A to detect that the original node B has crashed. Ideally without trying to communicate with the original node B -- don't want to be an amplification vector for DDOS attacks.

As for the "empty file that is the same size as the original file" I assume that is on node B. I thought we didn't create files until we received data for them, but maybe I'm mis-remembering, or maybe things have changed since I wrote the code. I guess it's worth investigating as well.

[liangmingyuanneo]

No, I have also met this problem and found the reason probably. Because if I use the bittorrent as the tracker, when Taipei-Torrent client
use "startTrackerClient" function to quest from the tracker, the tracker will answer a string that contains many same peerIDs. So in my opinion, when the Taipei-Torrent client stops, it does not request the tracker to delete the peerID.