A seed isn't "marked" as such

[mcaspi]

A remote uT peer is connected via TCP to a local seed, becomes a seed and disconnects. One of it's "Auto Shutdown" is set. The local seed tries to make a connection with the remote seed after more than 30 seconds from disconnection but it won't work because the remote client's Auto Shutdown was activated. With a uTP connection this "seed check" is working because it is done immediately after disconnection. In my opinion, the first connection attempt in such case (TCP disconnection) should be made in less than 30 seconds.

[ciaobaby]

Client version and build?

Also, once a uTorrent client goes into seeding it does NOT maintain a connection to other seeding peers and vice versa, a seeding client will not maintain a connection to peers that have become seeds.

[mcaspi]

Latest stable. The problem, in my opinion, is not the disconnection but the lack of "marking" seeds. See the title of this topic.

[ciaobaby]

Okay, explain what you mean by 'marking'.

But if you mean it does not increment the count inside the paranthesis, again that is to be expected because that number is made up from the tracker reports and the client's cached peers counts. So if the 'new' seed has not as yet 'announced' itself to any trackers and your client obviously does not have it cached as a 'seed', the count will not change.

Alternatively, the new seed may have simply "hit and run", or has announced but the tracker update interval may be anywhere between a few minutes to an hour or more depending on the tracker.

So your 'bug' is more likely to be something that the [local] client has absolutely no control over.

[mcaspi]

marking=setting a peer as seed.

ciaobaby, trackers are not involved here. In order to see this issue you have to watch the Logger tab when a peer becomes a seed. If you do this you'll see that peers that were uTP connected usually become seeds and peers that were TCP connected usually won't become seeds, in my opinion, if their Auto Shutdown feature is set, due to this timing issue.

[ciaobaby]

But trackers ARE involved along with DHT and PEx as that how any BitTorrent client 'knows' how many peers and seeds there are in the swarm for any particular job.

if their Auto Shutdown feature is set, due to this timing issue.

But you do not know if the other client even HAS an "auto shutdown" feature, not every client has. It could be ANYTHING.

But the simple fact remains that uTorrent WILL drop the connection, no matter what the transport protocol is as soon as a peer becomes a seed. That is the ONLY thing you are seeing happen and the rest is purely supposition. If that particular peer is no longer sending piece requests WHY would seeding peers care about it?

If you do this you'll see that peers that were uTP connected usually become seeds and peers that were TCP connected usually won't become seeds,

What version and build are you using?

Added

And what parameters are you logging?

[mcaspi]

Version 3.3.2 Build 30180. Logging: disconnects, outgoing connections, incoming connections.

[mcaspi]

Here is the log:

[11:00:45] X.Y.72.191:55170(22): [bitTorrent 6.4 (98.9)]: Disconnect: Connection closed

[11:01:32] X.Y.72.191:51129(22): Connecting: source: I

[11:01:53] X.Y.72.191:51129(22): Disconnect: Peer error: offline (timed out)

[mcaspi]

ciaobaby, assume that this seed now, has it's Auto Shutdown feature set. Will my uT be able to "mark" it as seed (clue: no)? If it was a uTP disconnection the answer is yes because uTP disconnection is different. So why should these two cases give different results?

[ciaobaby]

The log entries simply show that the a peer using port 55170 disconnected and a peer on the same IP using a DIFFERENT port was/is offline a minute or so later. Not sure how you deduced that is a client timing issue or a seed not announcing it's new status.

Have you done a WhoIs lookup to see if that IP is from a proxy or a VPN provider?

[mcaspi]

Seed disconnected at 11:00:45 so around 11:01:15 it won't response to incoming connections due to the Auto Shutdown. My client attempts to connect starting from 11:01:32 according to the log so it will not be able to "mark" that client as seed.

This issue might have been already considered by the developers and there might be a reason for this long delay after disconnection but again, it won't work in this case but if it was a uTP connection, it will usually work.

[ciaobaby]

But it may not even BE the same peer, simply sharing an IP does not mean the same client, and to change ports in ~47 seconds and report it to a tracker so your client can try connecting, is stretching probability a bit far.

Your logs show coincidental occurrences of two [possibly different] clients possibly on a proxy or a VPN, one WAS connected to your client, while the other may have been peering a job that your client is requesting pieces for.

Where is your evidence that these log entries are even for the same job?

[mcaspi]

1. It's the same peer. I see this behavior on TCP connections.

2. It's the same torrent(22).

[ciaobaby]

Okay, so have you verified where that IP is from as yet?

[mcaspi]

No because I see this on every TCP disconnection.

[ciaobaby]

So you are basically guessing at the "why" then.