On Tue, Mar 20, 2007 at 02:26:15PM -0400, Greg Troxel wrote:
> Jan Harkes <jaharkes_at_cs.cmu.edu> writes:
> > On Tue, Mar 20, 2007 at 10:33:11AM +0100, Enrico Weigelt wrote:
> >> how can I get write access to my coda files in disconnected mode ?
> >> 
> >> If I authenticated while online and then disconnected, it seems to
> >> work somehow, but the client must not have been rebooted for that.
> >
> > This is an argument that has been ongoing for a while. Only a server can
> > really validate if a user has write permission, the client caches some
> > of this information to avoid having to pass every request to the server
> > and to survive during disconnections.
> 
> I think it's useful to really think about the requirements and use
> cases for a system like coda, and to question whether the current
> approach really serves the needs.
> 
> Regardless of single/multiuser, I think disconnection should be as
> transparent as possible.  Of course some things won't be in the cache,
> either files or acls.
> 
> In my use case, I would like:
> 
>   tokens are not needed for local operations
> 
>   mapping of unix uid to authenticated user is retained unless I do
>   cunlog explicitly, even across system reboots and venus restarts

Technically all decisions in venus should be based on the local uid and
tokens are not really necessary. The only 'trick' is that if a user does
not have a tokens his identity is currently mapped to an internal
system_anyuser identity (in Realm::GetUser in venus/user.cc).

Removing this remapping for unauthenticated users should in principle
fix both of these issues.

>   a brief reconnect/disconnect does not really change anything, unless
>   we find out from the server that an acl has changed, in which case
>   sure we can follow the new rules

I still haven't really figured out the demotion rules but from what I
can see in the source we currently only demote system:anyuser rights
after a reconnection. The access rights for a specific user are only
dropped when a token is invalidated by the server as a result of
connecting with an expired token. Or when the user obtains a new token,
venus doesn't know if the new token would have the same permissions.
Both of these cases seem valid to me.

...

Got it, DemoteAcRights(ANYUSER_ID) does not just drop the anyuser rights
but all rights. A successful result from validateattrs re-establishes
them. It shouldn't be too hard to turn that around, I guess we really
only have to drop the rights for objects that didn't pass validation.

> A larger plan for a richer "what's changed" summary from servers on
> client reconnection would help; right now the client seems to assume
> that files might be different and revalidates on access if connected.
> In addition to sending a "here is the list of cache invalidations
> since we last spoke", a similar list of acl invalidations could be
> sent.

There already is a proof of concept implementation of this and I'm
slowly getting it ready for inclusion. The goal here is to optionally
not establish the callback connection and let the client be in a
continous semi-disconnected state where it periodically polls the server
for updates.

Currently we have to ping the servers to make sure any masquerading
firewalls don't forget about us, if we ping too often we waste
bandwidth, if we are too slow we end up having to reconnect and
revalidate (which is even worse). Also a server has to keep a lot of
state to track all those active callbacks and when clients disconnect
frequently because they are restarted, moving between different
networks, or when firewall mappings change, the callbacks to dead
clients can cause long delays when a client wants to update a file.

Callbacks provide better consistency for reads, but with 6.9.0 we
already delay writes by always reintegrating, so maybe adding another
slight delay until those writes are visible won't be that bad. Another
tradeoff is that if a client only has a single object in a volume
cached, there is no way to avoid getting notified about updates to all
uncached and thus uninteresting objects as well.

Jan