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. 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). > > 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. > > Anyone any hints? > > > > Thanks, Juergen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20070929/3dca35c9/attachment.pgp>
