On Tuesday 25 September 2007 17:04, bbackde at googlemail.com wrote: > 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...
Well the only other possibility would be UploadFrom=direct+disk whereby the client uploads the file as it sees it, and the node simultaneously reads it from disk and compares as it receives it, storing it separately to the degree to which it differs (note that the node will therefore be reading it from kernel buffers i.e. RAM so we don't need two passes). This is guaranteed to work, but it does take up a connection for a while. Also IMHO persistent uploads from DVD shouldn't use direct disk access. Arguably even slow network drives should be copied to a local drive and then inserted from there. (Network drives don't have to be slow.. although e.g. SMBFS can be very 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 > __________________________________________________ > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070925/aa1d290e/attachment.pgp>
