On Tue, Jan 30, 2007 at 08:05:42PM +0100, bbackde at googlemail.com wrote: > Frost uses DDA for all files, this saves some resources (transfer over > socket to Frost). Is DDA to expensive in the node, should clients not > use DDA for small files?
Well... DDA does use some resources (a file, a file handle, having to remember to delete it etc; several sys calls)... I would suggest using direct for message fetches. For stuff that you want persistently on disk anyway, i.e. file downloads, DDA is great; especially if you can queue a request to the global queue, to download into the node's downloads/ dir (or Frost's downloads dir?). > > A TestDDA functionality in the node would be great. > > Client to node: > > TestDDA > FileToWrite=c:\dir\file-123.tmp > WriteContent =<unique token> > FileToRead=c:\dir\file.456.tmp > ReadContent=<unique token> > EndMessage For security reasons the actual written data must be generated by the node. So drop WriteContent. > > Node to client: > > TestDDAResponse > FileWritten=true > FileRead=true > ReadContent=<same unique read token> Shouldn't that be WriteContent? It's the content that the node wrote to the file... > EndMessage Okay, with the usual conditions - if the file already exists, the node returns an error message. How to deal with errors, in fact? TestDDAResponse FileRead=true FileWritten=false WriteFailureReason=Permission denied WriteFailureCode=1 End Meaning that the read test succeeded but the write test failed because the node does not have permission to write the file. > > This way the client can check if the file was really written (check > unique token in file) and if the node was able to read the other > unique token from the specified file. If something fails the client > could still use DDA for PUTs (read allowed) or for GETs (write > allowed). > > Just an idea.... It's a good idea. I've filed a bug for it. If you want to implement it yourself then assign it to yourself, otherwise I will get around to it... eventually... https://bugs.freenetproject.org/view.php?id=1086 > > On 1/30/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > > On Wed, Jan 17, 2007 at 09:16:56AM +0100, bbackde at googlemail.com wrote: > > > I know there are many reasons why this could fail, but it would help > > > for the most users. > > > > Yeah, it's something the node should provide IMHO. > > > > How? The client feeds the node a filename, the node generates a short > > random hexadecimal string and writes it to the filename, then passes it > > back to the client? > > > > What about exploiting the "downloads" directory? This is something we > > know is accessible to the node, even if it isn't accessible to all > > clients? Maybe there should be an FCP command to return the location of > > the downloads directory, or even to create a subdirectory within it for > > a specific client? > > > > > > On 1/17/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> > > > wrote: > > > > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-17 > > > > 08:28:41]: > > > > > > > > > Could the node provide a functionality to check DDA access to a given > > > > > file? Currently Frost writes a file and tells the node to create the > > > > > URI of this file. If the node can access the file then DDA is > > > > > possible. But to check if the node can write to the file a GET would > > > > > be needed, and this could take some time. > > > > > I want a FCP2 command to let check the node read/write access to a > > > > > given file to check if DDA is really possible. > > > > > > > > > > Thanks! > > > > > > > > Well, beeing able to access the file doesn't mean you are on the same > > > > computer! > > > > > > > > It could be a mounted network filesystem or even worst ; a copy of the > > > > files you are testing located in the same path. > > > > > > > > NextGen$ > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > > > > > iD8DBQFFrdHxU/Z/dHFfxtcRAkvwAJ9E4pXrlHNXLk+ts3B15cdo/qhDpACfdbQs > > > > o7tTz+m4dzIf9dXqNlOEDFQ= > > > > =Bt2J > > > > -----END PGP SIGNATURE----- > > > > > > > > > > > > _______________________________________________ > > > > Devl mailing list > > > > Devl at freenetproject.org > > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > > > > _______________________________________________ > > > Devl mailing list > > > Devl at freenetproject.org > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > iD8DBQFFv33qA9rUluQ9pFARAiLeAJ9m4Rcng4Fq7AIwCrg8BiIlPeNfnwCgjhjJ > > wsU2IPXx5++DbYYgZSPcc98= > > =4uC5 > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070201/af9e3e25/attachment.pgp>
