On Thursday 20 September 2007 20:27, you wrote: > I didn't write that I see a problem with that. The only thing is that > I have to send the request again, so this testDDA is out of order and > not related to the current request. But no problem, I will implement > it the 'perfect' way: my FcpSocket will track the authenticated > directories and issue testDDA before requests if needed.
Would it help to have a ClientToken on TestDDA? I also wonder about multiple parallel TestDDA's.. I suppose the best thing for the client would be to wait for some kind of ack? Also, if the filesystem is readonly, you *will* need to use FileHash instead of TestDDA. > > On 9/20/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > > On Thursday 20 September 2007 09:49, you wrote: > > > > By the way, you can "try" to send something without TestDDA ... and if > > > > the node returns a ProtocolError with the DDA-reserved code then assume > > > > it has to be done. > > > > > > I also thought about this approach (as volodya said, its not the best > > > one, but it fits into my design). For one who does not want to > > > reimplement the tracking of successfully authenticated directories, > > > the alternative is what thaw does (if I understand it correctly): > > > make a TestDDA request each time when a request is started. But I > > > don't want to do this, because if someone starts to get/put many > > > files, this would lead to many requests and the client/node have to > > > write/read alot of files -> big overhead. > > > > As nextgens said, all you have to do is respond to a ProtocolError (with e.g. > > code 25), by doing a TestDDA. Why is that a problem? -------------- 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/devl/attachments/20070920/b021c7e1/attachment.pgp>
