Re: [core-dev] Downloading in 100k chunks

Gregorio Roper <[email protected]> Wed, 30 Jun 2004 17:17:19 +0200
Newsgroups gmane.network.gnutella.limewire.core.devel
Message-ID <[email protected]>
You are right. There has to be a lower limit for the chunk size which could be the 100k 
LimeWire is using at the moment.
You could also use 100k or 1% of the amount that has yet to be downloaded, which would 
probably help circumventing the problem of very low parellelism when a download is near 
complete.
It would be interesting to know what implications a larger chunk size would have on the 
download mesh.

mfg
gregorio

Sumeet Thadani wrote:

> It's time to revisit this stuff. Currently about 100% of our downloads 
> HTTP1.1, since we used having a hash as the heuristic for distinguishing 
> HTTP1.1 uploaders from HTTP 1.0 uploaders.
> 
> Given that MIN_SPLIT_SIZE ==  CHUNK_SIZE we are seeing no stealing 
> happening at all. For the stealing to occur, MIN_SPLIT_SIZE needs to be 
> less than CHUNK_SIZE. Note that this is not a bad thing -- read on to 
> see why.
> 
> Increasing the chunk size has the advantage that on 
> high-latency/low-bandwidth connections we would speed up the download by 
> sending less headers (note that this was much worse with HTTP 1.0 
> downloads -- since if the chunk size was too small we would have to 
> re-establish the TCP connection for each chunk).
> Having a very large chunk is also not the best idea -- stealing from a 
> HTTP 1.1 uploader is tricky, because there is no way to tell the server 
> to stop the uploading (meaning change your mind about the range you 
> want) after you have made the request. Once the request is made, you 
> have to download the range requested before you make the next request or 
> close the connection if another worker steals a part of that chunk from 
> you. So you have to predeterine what ranges you want before you make the 
> request, and if the range is too big, and one downloader is going slow 
> you can steal from it but at the expense of having the close that 
> connection, So It's a delicate balance.
> 
> Using a heuristic like 1% may not be optimal --  for a small file, 1% 
> can be much smaller than the current chunk size, and may cause far more 
> http headers to be exchanged than necessary.
> 
> Comments?
> 
> Thanks,
> 
> Sumeet
> 
> Gregorio Roper wrote:
> 
>> Is it still necessary to download all files in 100k chunks? It seems a 
>> little inefficient sending all these HTTP-requests/responses back and 
>> forth and it definitely slows the download down if you are working 
>> with a high latency connection.
>> Maybe using a dynamic chunk size of 1% of the file size would be a 
>> good idea.
>>
>> mfg
>> gregorio
>> _______________________________________________
>> core-dev mailing list
>> [email protected]
>> http://www.limewire.org/mailman/listinfo/core-dev
>>
>> .
>>
> 
> 
> _______________________________________________
> core-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/core-dev
> 
> 
_______________________________________________
core-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/core-dev