* Matthew Toseland <toad at amphibian.dyndns.org> [2007-09-25 20:22:24]:
> On Tuesday 25 September 2007 17:07, bbackde at googlemail.com wrote: > > My point is not to change the principles of the TestDDA > > implementation. The proposal describes a different way of > > implementation that fits for stateless clients. The current > > implementation requires that you send out-of-order testdda requests if > > the node sends an error, and then the client have to resend the > > original request. The proposal ties the testdda to the initiating > > request, and the node remembers the request until the testdda is > > finished. > > The basic principle here seems sound. Making clients' life a bit easier is > generally a good thing. Nextgens? Send a patch or fill in a ticket on the BTS. We discussed it 6 months ago (http://archives.freenetproject.org/message/20070414.083225.647d5e15.en.html) suggestions would have been welcome then but aren't anymore . I ended up implementing what we agreed on and have no plan to spend any time on that in the near future. By the way if you really want to make a basic, simple client I suggest you compute the FileHash and send it everytime. NextGen$ > > > > On 9/25/07, Florent Daigni?re <nextgens at freenetproject.org> wrote: > > > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-09-25 > > > 17:29:47]: > > > > > > > > Also, if the filesystem is readonly, you *will* need to use FileHash > instead > > > > > of TestDDA. > > > > > > > > This comment let me start thinking about the TestDDA design. Because > > > > if the directory is read-only, the client have to handle the node > > > > error (node cannot write the file) and the client must restart the > > > > request. This is complicated and maybe confusing. The following > > > > proposal tries to deal with this. I hope it is well thought. > > > > > > > > > > Well, I think that the current one is well thought... See below > > > limitations of your approach : > > > > > > > ------------------------------------------------ > > > > > > > > Proposal for a alternative implementation for TestDDA > > > > > > > > Reason for a new proposal: > > > > The current TestDDA implementation requires the client to implement > > > > more things than really > > > > needed. This proposal makes it easier for clients because its a simple > > > > question-and-answer > > > > game with the node. The node sends the right 'questions' to the > > > > client, because he knows what > > > > to ask. This allows easy-to-implement stateless clients. > > > > > > > > If needed, I could explain the advantages for clients in more detail. > > > > But I think if you compare the existing implementation of TestDDA with > > > > this proposal you > > > > encounter that this proposal is a more consistent implementation. Btw > > > > this handles multiple concurrent > > > > TestDDA requests (each request is tied to a ClientGET or ClientPUT). > > > > > > > > One does not fits all, so I think both implementations are useful for > > > > the one or the other client. > > > > This proposal is for clients that want to send a request, and handle > > > > all following messages > > > > in a different part of the code. They do not remember the original > > > > send request, so its hard > > > > for them to resend the request on failure. > > > > > > > > The following proposal is fully node driven, making the handling > > > > easier for clients (e.g. the > > > > decision if a filehash must be send is done by the node, because only > > > > he knows if he can write the > > > > required file to the target directory or if this is already denied > > > > (read-only directory). > > > > > > > > Note: this new impl must be enabled using a new parameter on > > > > ClientPUT/ClientGET. The is no need > > > > to change existing clients. > > > > > > > > For each follow-on message the identifier that the client sent with > > > > the first request is used, > > > > because this messages belong to the same client request. > > > > > > > > ClientPUT: > > > > ----------- > > > > - client sends ClientPUT to node, with new parameter indicating to use > > > > the new testdda impl > > > > (node now needs to know if client is allowed to READ from the > > > > directory where the file resides) > > > > - node checks if the current socket is already authenticated to READ > > > > from the directory > > > > > > It's not because you're allowed to read /etc/passwd and you sent the > > > node its filehash that you should be allowed to read everything in > > > /etc... (Maybe I'm missunderstanding what you're proposing) > > > > > > > - if YES, do the ClientPUT > > > > - if NO (proceed as in current TestDDA implementation): > > > > - node tries to create a new file with random content in the directory > > > > - if OK, send message to client asking to read this new file and > > > > return the content for verification > > > > - if NOT OK, send message to client asking for a filehash of this file > > > > > > Nothing prevents clients from sending FileHash every time... > > > > > > > (OR maybe for a hash of a part of the file! much lesser resource > > > > consumption. consider big files on > > > > network shares or on DVDs! But this may by more insecure.) > > > > > > We have already discussed asking for hashes of parts of files; We can't > > > do that. I can predict most of your /etc/shadow ; shall I be allowed to > > > upload it ? If I dunno about the part you're asking can't I ask again > > > 'til you ask me for a part I know ? > > > > > > NextGen$ > _______________________________________________ > 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/20070926/8094322b/attachment.pgp>
