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? > > 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$ -------------- 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/20070925/10f9344f/attachment.pgp>
