A question on seeding and an observation

[z9999]

I've been trying to seed an old unseeded torrent I ran across that had about 7 peers stuck at around 45% for several weeks now. I finally completed one of the peers who promptly disappeared, leaving 6 peers having around 50% and me alone seeding. It appeared to me that something was wrong as I had been seeding for some time and very little sharing seemed to be occurring, and when I turned on 'log traffic' it appeared that I was sending the same piece to each peer meaning that no one would ever have anything different to share. I thought initial seeding might solve the problem so I enabled it, set the maximum connected peers to 1, started the torrent running and waited until the single peer had completed 1 piece. Also note that when I did this there were 5 peers active who I had by then seeded to 71.5% each, so everyone possessed exactly the same pieces. Now, thinking that one peer had a unique piece to share I increased the maximum connected peers to 2, thinking that he/she could retrieve pieces from both me and the 1st started peer. Surprisingly my client, uTorrent 1.6.1 build 489, began to send the exact same piece that the 1st connected peer had just completed. Peer number 1 had just completed a 2nd piece and I added a 3rd peer who immediately began to receive the same piece that peer 1 had just completed. This appears to be a very inefficient method of seeding as no assistance ever occurs unless someone completes and remains connected to seed.

I'm wondering if this is in any way related to my downloading which often I notice that I have to wait until nearly every other connected peer acquires a piece before I can receive any DL at all giving me nothing to seed except to newly connected peers who lack any DL, but promptly exceed me in % completed.

[DreadWingKnight]

Initial seeding works better in larger swarms or with more connected peers.

Many clients don't report things properly. If the clients that are exhibiting this behavior are bitcomet, it is consistent with previous reports.

Could you make your post more organized and readable please.

[z9999]

All peers are running Azureus 2504, or uTorrent 1600 or 1610. No one running BitComet.

Essentially all I was saying is that either normally seeding or initial seeding, I appear to be sending the exact same pieces to each peer.

For example if I am sending piece 194 to one peer I can see that another, or even several other peers are also receiving piece 194. I see no traffic between peers as they all possess the same pieces which they are receiving only from me.

If I only seed to one peer and then allow all peers and immediately pause I then see the pieces being shared.

[µtorrent-Guest]

your problem here might be that you only allow 1 peer to connect.

if you are connected to the other 2, you will tell only one of them that you have piece 194.

so the second peer will ask him about it once he got it, and he is connected to the other peer too.

your Idea was good, but by limiting the max connected peers to only 1, you circumvented the initial seeding mechanism again.

[z9999]

That's fine, but the problem persists when I allow all peers as well. It continues to dole out the same piece to all peers simultaneously, both using normal seeding or initial seeding.

[µtorrent-Guest]

in initial seeding shouldn't he do that if they are all connected to you. :-(

if you still have, try with the 483 version or use the actual 490 version.

Maybe some bug in 489???

just out of curiosity; how large is the piece size?

[z9999]

My take on initial seeding was that it is supposed to hand out different pieces to each peer, not the same piece. Otherwise the only person who can pass data would be the seed.

I'm not into trying various versions unless someone knows there is a bug in the current version and to present I have not heard that there is.

The torrent I'm seeding was made by someone else and is 200 pieces of 4 mB each, which in my opinion is too large but as it was not made by me that's what I have to work with. I have found that in my case at least the smaller the piece size the better my results are in both acquiring and distributing pieces.

I just noticed there was a new peer connected who had 85.0% completed, and I have currently seeded the peers I've been connected to all having 79.5%. If I pause seeding the new peer instantly disconnects and rapidly reconnects if I resume seeding, but appears not to be giving anything to the peers I have been long connected to. The new peer is running BitComet and somehow seems to be able to capture all my UL bandwidth.

[µtorrent-Guest]

a) that's why I said 489 isn't the current version.

and

if it's a BitComet thats a whole different story!

BC's are asshole clients that cheat like hell, you can't use initial seeding seriously with those bastards. It just won't work with them, just add his IP into ipfilter.dat and next time he disconnects he kills himself with that behaviour.

BTW initially you said there were no BitComet in the swarm...

[z9999]

There weren't any BitComets previously, just 2 Azureus and 3 uTorrents.

I just now installed the 490 build, but didn't see any info relating to what I'm experiencing.

Checking what is being sent, it looks like I'm still sending pieces that have already been shared rather than pieces no one has yet, so it looks like the only solution is to seed to just one peer who will share and then I can quickly seed all the missing pieces. I've been seeding this for over a week now, so it should have completed long ago.