Confused about how torrents download…
-
Quite often when I'm downloading a torrent, there will be one seeder with 100% of the file, and several others with a percentage of the file.
That makes perfect sense to me. HOWEVER, what does NOT make sense to me is that all the partial downloaders tend to have the same percentage of the file downloaded. For instance.. all the partial downloaders will have 20%, then they will all have 21%, then 22%, 23%, etc.It seems to be that the way torrents are supposed to work is that each downloader / leecher is getting DIFFERENT parts of the file instead of everybody getting the same parts in order.
Lets say that a file is 100 parts and there are 10 leechers. If each downloader / leecher got all the parts in the same order, then the original poster would have to seed that file long enough for all 100 parts to be downloaded. If each leecher each got a unique set of 10 parts, then the original seeder could disappear in the time it takes to grab just 10 parts. Each of the 10 leechers would have 10 unique parts… the original seeder goes offline.. and each leecher completes the file by getting the parts from the other leechers.
This is an over simplification, but it is supposed to be the way torrents work. There is no advantage to having multiple leechers grabbing the same parts, because if the person with 100% goes offline before someone else gets 100%.. then all the leechers are screwed!
===
Can someone explain to me why torrent client's don't "randomize" their send packets so that there is a much better chance of all the pieces being distributed? I go insane (well MORE insane) whenever I have an incomplete download and all the 100% people are gone.. and there is a dozen leechers all with the same incomplete file. -
In the scenario you've described, where one client is giving out pieces to >10 leechers, each client will only be broadcasting the same "here's what I have" for each handed out piece, thereby ensuring that sometime after the 50% mark each leecher in the swarm will end up possessing the exact same pieces.
This is because it's the seeding client that determines whom gets what. Some believe that's the job of the tracker, but the tracker never participates in the actual exchange of data. It's for the individual clients to determine what data is given out, by communicating to other clients what pieces they have. The broadness of your scenario's distribution will always be limited to how many different pieces one client can distribute over its 4-20 individual upload slots allowed for in the settings. A broader type of distribution almost always occurs in scenarios where there are >10 seeders.
-
In the scenario you've described, where one client is giving out pieces to >10 leechers, each client will only be broadcasting the same "here's what I have" for each handed out piece, thereby ensuring that sometime after the 50% mark each leecher in the swarm will end up possessing the exact same pieces.
This is because it's the seeding client that determines whom gets what. Some believe that's the job of the tracker, but the tracker never participates in the actual exchange of data. It's for the individual clients to determine what data is given out, by communicating to other clients what pieces they have. The broadness of your scenario's distribution will always be limited to how many different pieces one client can distribute over its 4-20 individual upload slots allowed for in the settings. A broader type of distribution almost always occurs in scenarios where there are >10 seeders.
Yes… it's the seeding client that determines who get's what. To be most efficient.. the seeding client should be giving different pieces to different leechers.. but that is not what is going on. The client's are doling out the same pieces to all the leechers in the same order.
-
Basically the one initial seeding client is giving out mostly* different pieces to the different downloading peers. Then the downloading peers share the pieces among them. That leads to every downloading peer getting all the pieces which the initial seeding peer gave to the others.
In this process, peers with high free bandwidth get most of the pieces and will redistribute them to the other peers, often multiple times, which makes all getting a piece sent out by the initial seeding peer fast(er).
- = if the initial seeding peer has set the "initial seeding" (aka "superseeding", "strict initial seeding") function, he'll send out first each piece only once and it requires the downloading peers to ensure it's distributed further. This setting usually slows down the upload if there are only a few peers, but if there are many (~10) and the uploader got a slow upload connection, it optimises the use of it.
-
Basically the one initial seeding client is giving out mostly* different pieces to the different downloading peers. Then the downloading peers share the pieces among them. That leads to every downloading peer getting all the pieces which the initial seeding peer gave to the others.
In this process, peers with high free bandwidth get most of the pieces and will redistribute them to the other peers, often multiple times, which makes all getting a piece sent out by the initial seeding peer fast(er).
- = if the initial seeding peer has set the "initial seeding" (aka "superseeding", "strict initial seeding") function, he'll send out first each piece only once and it requires the downloading peers to ensure it's distributed further. This setting usually slows down the upload if there are only a few peers, but if there are many (~10) and the uploader got a slow upload connection, it optimises the use of it.
Having the initial seeder only send out each piece only once could easily be a disaster!
-
Once the client has sent out each piece once, it will start with seeding them again, that avoids disaster
