* Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-12 15:38:35]:
> On Thu, Apr 12, 2007 at 02:26:38PM +0200, Florent Daigni?re (NextGen$) wrote: > > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 > > 14:06:28]: > > > > > I looked over your source, but where is the point when the node READS > > > the file written by the client? It looks like the readFile is created > > > by the node? > > > > > > Did I misunderstand this? > > It's a variable naming missundersting: readFile is the file the node writes and the client reads. > > Yes, "known issue" ... in the final version of the protocol the client > > will choose the filename and the node will return if it can read from > > it or not (assuming the file isn't empty). > > Why would the filename be created by the client? > > I thought the protocol was that the node writes a file which the client > must read, then it tells the client to write a specific block of data to > a specific file which the client must create. That's how it's implemented at the moment but it sucks... If you want for instance to be able to use DDA (even read access only) on a directory the node hasn't write access to it won't work as the node won't be able to write the file the client is supposed to read. I have created and documented two new messages : TestFileAccessQuery and TestFileAccessReply; Those will probably be usefull to figure out if the node and the FCP client are on the same computer. I guess the solution will be to require the client to send us a hash of the content he wants us to insert... but it requires both the client and the node to compute the hash, and that obviously sucks :) NextGen$ -------------- 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/20070412/0e5ce215/attachment.pgp>
