Quote:
Originally posted by verdyp
[B]Actually Limewire uploads files by fragments of max 100KB (with a 10 bytes overlay). This allows faster propagation of the download mesh with partial file sharing is enabled in the downloader, that performs successive requests on its connection to upload new fragments and advertize its locations, and to give feedback to the uploader that it now shares some fragments of the uploaded file.
If there's something that may be impoved is to allow interleaving of download requests: for example, after uploading 1MB to the downloader (10 fragments), its connection would be rescheduled (in the active queue), to allow concurrent uploads to perform their swarmed requests, allowing serving more clients.
|
Please don't do it like that!
Someone out there already does and you can imagine how I hated downloading a file by a 100kB Junk, the being put behind some Modem-User.
I think feeling is far too important for this.
This is about making it possible to download small files, while many big filles are in the queue, but a downloader of a big file would also hate not really being able to download continuously, at least I would. THe difference between theh Small and te big file is: Small File downloaders come, grab the file and are content, Big file downloaders grab your Upload slot for some time. but if small-file-downloaders could get in between, the big-file-downloaders would sit in queue most of the time, that's why I'd give those small-file-downloaders an extra upload slot. It doesn't stop other downloads (which would make reconnection necessary) and allows them to spread quickly and effectively.
Also this wouldn't gain anything, when siimply five big-files were in the upload-queue (or the queue would grow indefinitely). Since swarming I often get 10 to 20 uploads to other downloaders while I download a big file, so there would be o space for a small file in between (especially because I prefer to have an upload done, and not to have it linger endlessly in Queue, because the first assures me, that the file is completely avaible on the Gnet.
Quote:
|
Smarter management of upload queues would allow non-infinite delay for transfers from hosts with limited upstream bandwidth, so that very large files will still continue to be uploaded when allowing also to deliver smaller files. My opinion is that filesize should not be taken too much into consideration, but rather the diversity (because now swarmed transfers work perfectly and with the same performance on slow and broadband connections).
|
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.
Quote:
|
There's less risk to upload a single large file to many hosts (that will then collaborate to interchange their file fragments), than to let a single host download a very large file and then disconnect immediately once the transfer finishes. This would make the mesh much more resistant to single points of failures (a host that disconnects just after its transfer terminates). It would really increase the variety of available contents on the Gnet, and larger sets of alternate locations for large files.
|
Complete agreement, as long as we upload different fragments to different hosts, while still allowing them to preview the file.
I had the Idea to always alternatingly upload junks from the beginning and either the first or second third of the file (randomly selected junks from the second or third third, but for one host only for the third third and for another only for the second third, till all those have been uploaded, though I realize, that the host must request that range itself, so it is up to the downloader to download sensibly).