(Apr 12, 2018, 13:16 pm)dueda Wrote: (Apr 12, 2018, 01:30 am)Sid Wrote: It is designed to minimize the amount of data a seed needs to upload.
> Good; but how? Minimize bytes sent can be done only by making sure each piece will be seeded only one time - at least during initial seed.
Imagine you are (normal) seeding a torrent containing just 3 pieces, and I start downloading and then Moe starts downloading.
When I connect to you I tell you I have no pieces and you tell me you have pieces 1, 2 and 3. I randomly select one of the rarest pieces in the swarm and request piece 2. You start uploading to me.
When Moe connects to you and to me he tells us both he has no pieces, you tell him you have 1, 2 and 3 and I tell him I have none (as I haven't finished downloading piece 2 yet).
Moe randomly selects one of the rarest pieces in the swarm and request it (from you, as you are the peer which has it). He might select piece 1 but he also might select piece 2. So lets imagine he selects piece 2. He requests it from you and you start uploading it to him.
When Moe and I finish downloading piece 2 we notify each other (and you) that we now have piece 2. Then we randomly select one of the rarest pieces in the swarm (at this point there are 3 copies of piece 2 and 1 copy each of pieces 1 and 3) and request it and carry on.
The key point is that you have uploaded 2 copies of piece 2.
Now reset and imagine the same opening scenario but this time you are super seeding.
When I connect to you and tell you I have no pieces you lie to me and tell me that you only have piece 1. I randomly select one of the rarest pieces in the swarm--the only piece is 1 so I Â request piece 1. You start uploading to me.
When Moe connects you lie to him and tell him you only have piece 2. He randomly select one of the rarest pieces in the swarm--the only piece is 2 so he requests piece 2. You start uploading to him.
When I finish downloading piece 1 I tell you and Moe (and Moe sees the "new" piece and requests piece 1 from me. I start uploading it to him).
When Moe finishes downloading piece 1 he tells you and me that he now has piece 1. When you see that Moe has piece 1, which you know you uploaded to me, you can deduce that I have uploaded it to Moe. So you announce to me that you "now" have piece 3. And I request it.
i.e. by lying to peers about which pieces you have (when you are the only peer which has those pieces) you can ensure that you only upload each piece once.
Inevitable consequences of waiting for me to upload a piece I have download from you to Moe before telling me that you have another piece are
1. When there is only 1 peer in the swarm uploading will stall after the first piece has been uploaded.
2. When there are multiple seeds in the swarm the results will be unpredictable because it's no longer valid to assume that a new piece appearing on one peer came from a different peer that you had uploaded that piece to.
3. When a swarm has only a few peers you will upload a piece, wait a bit for the piece to be reupload, upload, wait a bit for the piece to be reuploaded, etc. i.e. your upload rate will zigzag up and down dramatically and will be lower than your total available bandwidth. It will smooth out over time as more peers join but it is disconcerting at first if you don't understand what is going on.
(Apr 12, 2018, 13:16 pm)dueda Wrote: > This could be done on a sequential or random piece selection, but makes the preview, first-and-last-piece download mode, impossible.
Yes and no. Firstly bear in mind that super seeding was designed, and implemented in clients, many years before streaming became a thing. So those limitations were not even thought of let alone considered a problem.
Secondly bear in mind that it is intended to benefit uploaders. Specifically uploaders with data caps. That it has some downsides for downloaders isn't really relevant.
But super seeding (or "initial seeding" as it was later and less-misleadingly-but-still-not-entirely-accurately termed) is only used when there is only one seed in a swarm. So when you consider that torrents live for YEARS, the fact that people might not be able to preview them until several HOURS after they are uploaded for the very first time is an insignificant limitation.
(Apr 12, 2018, 00:18 am)dueda Wrote: >I wrongly mixed piece and peer priorization. What I notice was a decrease in speed, from 6KB/s to 4.5KBs when enabling superseeding.
>This can scare some downloaders; in fact, it seems to change the active peer set, at least for some time.
You're looking too closely, and overthinking.
As an exercise. Start seeding a torrent in your client (normal seeding or super seeding it doesn't matter) and watch the speed graph. It will zigzag up and down continually, and it will start at 0 and then over time rise to a peak, possibly plateau for a bit and then gradually return to 0.
ALL of that variability is natural. And it all happens when you don't change a single thing.
So if you change something, and see a change, you cannot tell whether the change is because of what you changed or because torrent speeds change dramatically from second to second even when you don't change anything.
Flipped around, you "see" what you expect to see because whenever you change something speeds will drop (but then they will rise; or they will rise and then they will drop). But they would do that even if you didn't change anything.
The same thing happens with downloaders. Most of them won't even be looking, so they won't even notice a drop from 6KBs to 4.5KBs. And if they did notice they wouldn't know why it had happened, or care. [And since you should not be switching to super seeding halfway, as that defeats the entire purpose, but using it from the beginning it wouldn't happen anyway.]
