Re: ClientGet questions

Matthew Toseland wrote:
> On Thursday 27 September 2007 12:16, you wrote:
>   
>> Hello,
>>
>> I am playing a bit around with the client protocol (2.0)
>> currently and a have few questions.
>>
>> One is regarding 'ClientGet'. To download a file to disk I have
>> to pass the filepath and its size in the request. This is leaving me
>> with one or the other headscratch. How am I supposed to know
>> in advance what type of file I am requesting and what its size
>> is?
>>     
>
> You only have to pass a maximum size. If the file is bigger than this then the 
> node will fail the download. There is no reason to pass a maximum size if you 
> want to download the file regardless of how big it is.
>   
ok
> You do need to pass the path to save it to, if you want to save it directly to 
> disk. You can use ReturnType=direct to store it in temporary space inside the 
> node and then stream it back over the FCP connection, but this is much less 
> efficient on disk space for large downloads as we end up storing several 
> copies at once. It is however simpler for small fetches.
>   
>> One of the (bit hackish) solutions I came up with  sending a 'ClientGet'
>> with a size of -1 or 0, hoping the request fails, to get the missing 
>> peaces from 
>> 'GetFailed'  (code 21), but have no idea if this is intendet use or how 
>> reliable it is.
>>     
>
> 0 is too small. If you're just interested in the mime type, try something a 
> bit bigger - say 32k (the basic units of size in freenet are 1k for SSKs and 
> 32k for CHKs).
>   
ok
>> Another headscratch is: how am I supposed to know in advance if a filepath
>> I pass today can be written tommorow? In the meantime some other file 
>> with the same
>> name may find its way into the folder, the folder might disappear... or 
>> whatever.
>> So I wonder why the filepath (and TestDDA) is not requested somewhere 
>> near 'DataFound',
>> when it is actually needed.
>>     
>
> To save disk space. Downloading to temporary space is *really* expensive on 
> disk space: we have to store a separate copy of the entire file, which may be 
> huge, then stream it across, then the client writes its own copy, then we 
> delete our copy. On top of all the temporary files we use assembling it.
>   

ok, I see. No other way to handle this.

When I am at it... if you don't mind. A question regarding TestDDARequest.

Somehow I am worried that tested directories might pile up in memory
(could potentially be a huge number over time running) and was hoping a
TestDDARequest with 'WantReadDirectory=false' and 
'WantWriteDirectory=false'
could cause the node to forget a directory and free resources. How is this
handled?



Thanks, Juergen