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... > >
