> 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.
------------------------------------------------
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...
On 9/20/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> On Thursday 20 September 2007 20:27, you wrote:
> > I didn't write that I see a problem with that. The only thing is that
> > I have to send the request again, so this testDDA is out of order and
> > not related to the current request. But no problem, I will implement
> > it the 'perfect' way: my FcpSocket will track the authenticated
> > directories and issue testDDA before requests if needed.
>
> Would it help to have a ClientToken on TestDDA? I also wonder about multiple
> parallel TestDDA's.. I suppose the best thing for the client would be to wait
> for some kind of ack?
>
> Also, if the filesystem is readonly, you *will* need to use FileHash instead
> of TestDDA.
> >
> > On 9/20/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> > > On Thursday 20 September 2007 09:49, you wrote:
> > > > > By the way, you can "try" to send something without TestDDA ... and if
> > > > > the node returns a ProtocolError with the DDA-reserved code then
> assume
> > > > > it has to be done.
> > > >
> > > > I also thought about this approach (as volodya said, its not the best
> > > > one, but it fits into my design). For one who does not want to
> > > > reimplement the tracking of successfully authenticated directories,
> > > > the alternative is what thaw does (if I understand it correctly):
> > > > make a TestDDA request each time when a request is started. But I
> > > > don't want to do this, because if someone starts to get/put many
> > > > files, this would lead to many requests and the client/node have to
> > > > write/read alot of files -> big overhead.
> > >
> > > As nextgens said, all you have to do is respond to a ProtocolError (with
> e.g.
> > > code 25), by doing a TestDDA. Why is that a problem?
>
>
--
__________________________________________________
GnuPG key: (0x48DBFA8A)
Keyserver: pgpkeys.pca.dfn.de
Fingerprint:
477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A
__________________________________________________
