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