Quote:
Originally posted by arne_bab
Filesize makes a difference for me as User. I'm not patient when waiting for a small file, but when I wait for big files, I have no problems with being in a queue, because I know I'll get the file at some time (and it will take 3 hours anyway, so why bother with 15 minutes in queue?). For the first, quick download is more important, while for the second it's reliability.
|
Do you realize that, in this last sentence, you are contradicting your own position in the first paragraph, because you admit delays when downloading large files?
I see no difference between distribution of files of various sizes and distribution of files with equal sizes (such as file fragments). The effect I was describing is similar to splitting large files and distributing them separately with equal access to the candidate upload queues. However large files in queues take too much time on uploaders sites, and uploader cannot guarantee equal access to all downloaders.
Swarming, if PFSP is enabled, allows implementing this equality policy, and differences of file sizes become much less relevant than with PFSP disabled (where it makes sense to make distinctions between uploader's upstream bandwidth for large files, but at a too expensive cost for the distribution of small files.
What just needs to be guaranteed is that large files swarmed from multiple sources that got only some fragments, will converge rapidly to create the whole file for all clients.
This is possible provided that the uploader queue keeps at least 1 upload slot per fragmented file. If everybody (at least Limewire agents) adheres to this policy, all uploaders will be able to redistribute their copy of the fragments, and will collaborate to help the initial uploader (that may be the first and single source for that file, placing it at risks to monitoring, as long as the mesh contains too few alternate locations with complete files). Rapidly the intial single source will be helped and will no longer to alone to distribute the needed fragments.
I do think this is the whole interest of PFSP: faster distribution of new files, which will become popular and accessible much faster without depending to much on the first source. For very popular files that get lots of incoming transfer requests, we could even imagine to reduce the fragment size depending on the number of known alternate sources. That this file will be large or medium will not make a big difference. But for some small files below 1MB, this could be an improvement so that uploaders will be less likely placed at risk of failure.
This is already a problem still today: I got some partial files for which I can no more find any other copy and the initial source is offline, however the file was already large and it took lot of time to download that large fragment from the initial source. But as nobody helped that source, there was no other copy available for the end of file. Result: the time and bandwidth to upload this fragment in uploader was lost, and my own time and bandwidth was also lost too as I can't recover a complete copy.
My own measure for large files (videos or collections of graphics or CD images) show that this event occurs quite often, for 2/3 of attempted transfers, and for which there will never be any other source (the initial uploader may have spent much time to upload the begining of files to many candidate downloaders, without having finally uploaded at least one copy of the end-of-file fragment). If that uploader decides to stop there after uploading that file for 3 or 4 days, all this bandwidth will be lost. That's where we need a better strategy to make sure that after 2 or 3 hours of uploads, for a file that could have been uploaded directly to a single downloader, this file will have at least 1 or 2 complete mirrors on many hosts collaborating each other to terminate their partial copies.