No Frost doesn't do this for all files. And the point is that the node have to compute the filehash also! We tried this with files on a network drive (read-only) and from DVD and it becomes incredible slow...
On 9/25/07, cbreak <cbreak at gmx.net> wrote: > bbackde at googlemail.com wrote: > >> Also, if the filesystem is readonly, you *will* need to use FileHash > >> instead > >> of TestDDA. > > Doesn't frost already create hashes of the files it uploads for internal > purposes? It can either use this hash to authenticate it, or calculate a > second hash for authentication purposes in the same read. In the special > case frost there will be no read overhead, and only a tiny storage and > calculation overhead. > > cbreak > > > 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. > > > > ------------------------------------------------ > > > > 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 > > - 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 > > (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.) > > > > - handle the client answer for the request as usual... > > > > ClientGET: > > ----------- > > - client sends ClientGET to node, with new parameter indicating to use > > the new testdda impl > > (node now needs to know if client is allowed to WRITE to the > > directory where the file resides) > > - node checks if the current socket is already authenticated to WRITE > > to the directory > > - if YES, do the ClientGET > > - if NO (proceed as in current TestDDA implementation): > > - node asks client to write a new file with random content to this directory > > - after client response, node tries to read this file > > - proceed as usual... > > > > > _______________________________________________ > 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 __________________________________________________
