Availability per file in the Torrent

[quakze]

As torrent could be a bundle of many different files, availability per file in the Torrent will help in knowing which is the most wanted file(s) and to know the status of the file(s) we are downloading

[cassie]

availability per file in the Torrent will help in knowing which is the most wanted file(s) and to know the status of the file(s) we are downloading

What would be the purpose of having such a feature?

[quakze]

What would be the purpose of having such a feature?

for instance, If there is a torrent with collection of films(or tutorials), I could prioritise the one which is highly available than which is not available for instant downloading.

This is just the hint of usage, rest will learn as use the feature.

Thanks

Quakze

[greywizard]

Your client does that automatically for you in a dynamic mode.

When it can't download a certain piece it seeks another one. It doesn't wait forever to download some piece that will never come. That is, unless there are no other pieces available at all.

But torrent swarms are most often dynamic virtual networks that change even as fast as every second, for large swarms!

And along with that the piece availability map changes as well (e.g. when some peers/seeds join or leave the swarm for whatever reason).

Furthermore, you as a person must take into consideration that different pieces which represent a file, even though available at other peers, may not be available to you for certain amounts of time because your client is being choked at that moment, due to the inherent limitations of uploading slots of each client. This is a constant throughout the entire download, of course, for an arbitrary ever-changing set of the remaining not-yet-downloaded pieces.

In that case, in that "idle" time, your client does at least 2 useful things: it seeks/downloads other available pieces and keeps tabs on the choking status of the pieces it already requested.

Therefore, good luck in trying to persuade anyone that you are faster or better then your computer in making dynamic decisions based on piece availability. ;)

[quakze]

Thanks for the detail response.

I am a happy user of BitComet, so I am not complaining about any thing. I understand your point, But my point is different.

Let say the torrent size is 100GB, containing 100 files and seeder is not continuously seeding. Now If I want to download all, and don't want to waste time waiting for the whole download to complete automatically. Then what are my options:

I have to choose and prioritize, with out knowing which file availability is high.

So if availability feature is available then I can pick better one, Right ?

Thanks

Quakze

Edited April 16, 2010 by quakze (see edit history)

[greywizard]

I'm not so sure that you entirely understood my point.

As far as any BitTorrent client is concerned the file set of a torrent is not made up of files. All the files are concatenated virtually then the resulting data chunk is split into equally sized pieces. These are the trading units of BitTorrent protocol. When clients transfer pieces one to each other they do not take into account to which file the piece belongs.

There are other entirely different criteria on which decisions are made in this respect. The model of BitTorrent operation is the "rarest-first" method. This ensures that the pieces that are the most rare in the swarm are the ones which will be downloaded first so as to ensure an efficient piece propagation pattern.

The "rarest-first" algorithm and the choking algorithm are the two core technologies of BitTorrent. File prioritization, as introduced by BitComet somewhat "forces" the natural flow of the BitTorrent protocol's algorithm at the expense of download speed.

Furthermore, BitTorrent swarms are highly dynamical especially when it comes to the piece availability map. As I've explained above, the algorithm will try to make sure that no piece is more available then other. Apart from that, even if one file is at any point having a higher availability percent as related to the number of copies for each of its pieces, that is bound to be only temporary since the algorithm always seeks to level out these differences.

And even if for the sake of the argument, the availability of the file was to remain the same, for all the time of your download, there is nothing to guarantee that the peers holding those pieces won't leave the swarm (e.g. going to sleep) and modify again the piece map of the swarm.

Also there is nothing to guarantee that the peers holding the pieces won't choke you, and therefore your client will just waist time trying to download specifically the file you chose.

As I said, torrent swarms are highly dynamic things and what now seems more available than other files, won't necessary be the same in, say, 30 minutes.

[quakze]

Thanks for the quick response.

If all the leechers downloading some specific file in the torrent (refer the above example), which is new. So now off course the availability of that file will be high and remain approximately constant.

The idea is interesting, But only the question is, can You feel the same way.

I had come across many situations like this, where I could not do any thing but only to wait until the full Torrent download is complete.

I have done my part of contribution, now it is your choice ?

Thanks

Quakze

[greywizard]

This is more complicated than you think.

Your client can't really make an accurate piece map, except for the peers that it's connected to at the present time not all the peers of the swarm. Therefore, the files which would appear most available to you, won't necessarily be the most available files in the whole swarm.

Furthermore, your client connects and disconnects from other peers very often (even as fast as several peers per second). Therefore that file availability statistic would be an ever changing Fata Morgana. I understand what you want, I just don't think it's doable at present time.

This is my two cents worth. However I'm not part of the dev team.

You may take your case up to them into the Feature Request section. If they feel it's possible... well, good luck.

[kluelos]

Have to say, I don't think much of this as an example. A torrent simply has no business being 100 GB in size, and it's really irresponsible for anyone to do so. That being so, the example pretty much falls apart as not realistic and an extreme edge-case. You certainly aren't going to persuade anyone with that example.

[quakze]

Re: kluelos

Now what you say for this example ?

Please check the link below

http://yfrog.com/5mbitcometgj

From the above picture it is clear that some place it is dark blue and some place light blue indicating the availability of the torrent in whole. Here the point is clear that file availability remains approximately constant.

For a brilliant people a hint is enough !

[kluelos]

Nothing about that picture's clear, sorry. I can't make it out at any resolution.

But I will repeat that anyone creating a torrent 100 GB in size needs schooling in what they're trying to do, on a fundamental level. As to what you're trying to establish, I'm afraid your English isn't good enough, and your points are about as unclear as the picture is. I have to guess at most of what you're saying, and I can't make sense of it.