Harmless sequential downloading - WHY not?

[Ли�]

I know that it's against some holy BitTorrent rules, and sequential downloading can possibly mess the distribution of pieces, but why the harmless one should not be implemented? I'm just looking for a proper answer to the question 'why', that would not be equal to 'just because' (this one can be found everywhere accross the forum). Look:

I'm using solely one private tracker;

Each peer have got from 128 to 10000 kbps;

There are ~50 peers seeding torrents in average giving

not less than 0.5 mb/s for almost any torrent I choose.

My idea is as follows. The harm comes when some seed reaches the top of his seeding power while user A is attempting to download a piece he should not want, that is, a piece that is not 'rare'. At this moment A is reporting to the system he has the piece, but in reality he can not seed it. But this distraction is of any significance if only that most-wanted piece is needed *urgently*, that is, is being the last piece for someone, or would fit that 'unused bandwidth' for that someone.

This means: if there's only one leecher, the term 'harm' is of no existence; or, wider,

if a cumulative downloading force of all leachers is less than the cumulative force of seeding of all seeders and the delta provides enough speed for the sequential downloading, then it makes no harm. that is, *absolutely* no harm.

More to it. Even if all the leechers would download the file sequentially, and not quit until they've finished, there would be *absolutely* no harm. (as all clients would dowload parts all other previous leechers have--in sequence, the speed'd be maximal). In this situating a real harm would be possible solely if some of the peers would quit leaving some (last) pieces unsent, thus rendering them rare. But such a situation is only possible when the torrent is being downloaded during a long period of time--be it due to it's size or speed of the peers. But both of these values, and also the availability of the torrent, is measurable!

So, finally, an example. A torrent, 1.37gb avi file, has a bitrate of 1936kbps, or 242 KiB/s. At 700KiB/s, it would be downloaded in 32 minutes. of these 700, only 242 are needed for instant preview, the remaining 458 can be used as usual.

A user N starts downloading a torrent, and wants to watch a file instanly. He presses 'Preview' button in uTorrent, and at this moment uTorrent receives the signal that the users wants to preview a file. It checks the availability and finds that there are 10 active seeds and there are minimal amount of rare parts; it looks at the speed and finds that it was steady 700 KiB/s for the last 60 seconds, indicating that it's more than enough for previewing the file. uTorrent decides to allow user to watch the file, and user benefit instant preview with a minimal (or no) harm to the system. When player is turned off, sequential downloading ceases. This way, if only you are *actually watching* the movie, it's downloaded piece-by-piece.

Speed less than, say, 1.5x bitrate? Decline. Too low seed/peer ration? Decline. Really rare pieces? Get them first. Otherwise, why not?

P.S. Sorry for my English, I'm trying my best

[hermanm]

It does make you wonder when there is an overabundance of seeders, if sequential downloading does no harm. You have an overabundance of availability so there are no piece distribution issues.

[jewelisheaven]

... When your first thread is trashed you don't make a new one. You want to preview and make sure you've got the right media... prio_first_last

You want to use another client which already implements your idea with streaming, go ahead. I think Miro and DNA are the two most popular right now. http://torrentfreak.com/bittorrent-launches-streaming-service-071010/ DNA is from the people at BitTorrent,Inc. (who own and operate bittorrent.com, who are parent to utorrent.com, and who oversee bittorrent.org)

[DreadWingKnight]

I'm using solely one private tracker;

http://www.azureuswiki.com/index.php/User:The8472/Private_trackers - If your entire assumption and proposal revolves around being on a private tracker, just give up now.

there would be *absolutely* no harm. (as all clients would dowload parts all other previous leechers have--in sequence, the speed'd be maximal)

Until the seed(s) leaves before the downloaders are finished getting all of the pieces out because they're all sequentially downloading.

[Lord Alderaan]

The mechanics has to be applied in such a way that it wouldn't hurt the health of the torrent. This would mean it would only be available in some occasions and even then should only be available to a limited number of peers. It would be hard to write an universal mechanism that would make sure of these things.

So you want a system that is difficult to implement right, that not many people want, that is only available in limited situations and that even then still involves risk of damaging the swarm, let alone possibilities of abuse.

[Switeck]

When a lone seed is forced to REPEATEDLY upload the same beginning (and often ending!) section of a torrent to every freaking idiot peer that comes along, it might come as no surprise that the seed leaves in disgust after uploading 10x the size of the torrent...and availability still hasn't exceeded 50%.

We can thank BitComet (and clones) for already showing us just how BAD sequential downloading can be...it is NOT needed for uTorrent.

[Ли�]

Lord Alderaan, not many people want? I was told it's the second most requested feauture (the first being chat). Well, I think that a harmless system can be made and it won't be that useless. Remember that it is to work only for people who are watching and downloading a (movie) *simultaneously*, something that you rarely do even when downloading a movie from http and such.

Switeck, but the seed still puts those requesting rare pieces on the top of the queue? If so, i can think of a system that would do so little harm, that it would be of no importance. I'll draw a diagram and write a more coherent explanaion when I have time.

As for BitComet, well, i can't say anything save the fact that I have never seen blue-fading-do-white availability lines.

[DreadWingKnight]

I was told it's the second most requested feauture (the first being chat).

Second most REJECTED feature.

[hermanm]

> seed leaves in disgust after uploading 10x the size of the torrent

One tracker I'm one - one torrent is 170 seeders and 4 leechers. The seeders don't mind they upload the same bits over and over again - the motivation is upload credit not availability. The issue of availability disappeared a long time ago. So, there could be a threshold in one of the ratio calculations where sequential downloading is a non-issue. Maybe 100 seeds to 1 peer is a sufficient threshold?

[jewelisheaven]

Sequential downloading won't happen in uT. You want a streaming client... use another client. There are many to choose from.

[Switeck]

but the seed still puts those requesting rare pieces on the top of the queue? If so, i can think of a system that would do so little harm, that it would be of no importance.

No, seeds are forced to honor upload requests from peers, even if it's the same part over and over again. It is the peer that is SUPPOSED to make intelligent decisions about choosing rare parts first. In the event that the seed advertises only rare parts from elsewhere in the torrent, the sequential peers would typically not download from it at all unless one of those rare pieces happens to be one of the next in line that they want.

Initial Seeding has to really strain the BitTorrent protocol to work at all, and often works at a slower upload speed than regular seeding...simply because many peers reciprocate with other peers slowly if at all.