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.
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$ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFG+Sv9U/Z/dHFfxtcRAhr7AJ4yTBMXNW1WZAfbCEV/TfEVa+rDswCgjJ3N > dFEFlu4nK+pyFdd/ilTdKww= > =AmYY > -----END PGP SIGNATURE----- > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- __________________________________________________ GnuPG key: (0x48DBFA8A) Keyserver: pgpkeys.pca.dfn.de Fingerprint: 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A __________________________________________________
