All wanting AND downloading the exact same piece from the only seed.Īd-hoc distribution is far faster than the only seed, sending out the same piece to all leechers at the same time. One seeder ( 100 active connections).ġ00 leechers. Seems strange but if you think about it.Įg. That is probably another part of the problem. Is the method for calculating the rarest piece identical for all users in the swarm ? For reasons that I don't know.ĭo all versions have S.O.P ? is it enabled by default ?
#Vuze bittorrent sites utorrent
Not good for utorrent users who want to download from the seed.Įither is the initial speed they get from the only seed, as I stated it can take a really long time before the utorrent client starts downloading at full speed. Utorrent will still connect up to the ONLY seed, Then disconnect without downloading Piece not uploaded ( reset piece assignment to ""unassigned"" for (x) piece )Īfter (y)time ( piece(x) = not 100% transferred = True)īut that is a just work around, hence why I posted the issue here. (x)Seeds are in swarm (who you can't always trust to seed back fast enough, if at all ) The only way round this in Vuze, is to have superseeding mode end only when ,
The efficiency and actual aim of super-seeding is compromised, because at the end of sequential piece assignment, normal ad-hoc transfer begins. It uploads 1-end sequentially to the swarm, then switches to normal seeding to fill in pieces.Īdditionally, Vuse's superseed performance is, because of this method, sub-standard for the concept.Īgree 100%. Vuse's superseed mode is a sequential upload system. Why not request the rarest pieces ? instead of the most available pieces, from the only seed ?Įnd user cpu performance is a big part of utorrent's success, yet it's network transfer performance makes me mad as an initial seeder. Utorrent clients ( instances) request the same pieces over and over again from a vuze seeder. by filtering out and blocking utorrent users who persistently connect and disconnect without downloading a piece.īUT blocking is not desired, that's just dealing with the side effects. This issue could possibly be fixed at the vuze end.
*Other non-utorrent clients, connect and download at full speed within seconds. ( I know that sounds silly, technically ridiculous, but it really does happen that way ) It's as if the client just realises that the vuze peer might be useful to leech from. They start off downloading at a few kbps, only after a few minutes will the utorrent clients suddenly start downloading at full speed, They take a really long time start downloading at full speed. When utorrent users do connect ( and stay connected ) to a superseed using vuze , So the remaining +60% is being seeded normally ( ad hoc / duplicate data)Īlso. Then super seeding automatically ends (Works, as is Desired by protocol ) , With a popular torrent, i have ""super seeded"" less than 40% of the data. This makes a mockery of super seeding mode. creating pieces assigned to super seeding that will never be seeded in that said mode. More utorrent clients connect and then disconnect. Now Vuze will regard the assigned piece as part of seeding in Super Seeding mode, the next leecher to connect will be assigned the next piece.ģ. ( not all of them do this, but a lot of them (majority), i cant see a clear pattern if it even exists)ĢD. They are assigned a piece that I will seed to them.ĢC. The connected utorrent users, download the few bytes (approx) needed to be put in the queue.ĢB.
#Vuze bittorrent sites torrent
Start seeding new torrent ( super seeding mode ) in vuze.ĢA. This issue is fully reproducible: ( does not apply to any specific utorrent build or encryption protocol / who made the connection (nat ! port protocol etc. You must not have enough available bandwidth, (during X event ) please don't bore me or be condescending about my setup. vuze is setup right, connection, ports,encryption ect. Utorrent seems to ,not be playing nice when I superseed initial uploads.
0 kommentar(er)
