From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <66617ff87621f7f51e91bc31dad097c4@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] QTCTL?
Date: Thu,  1 Nov 2007 13:12:02 -0400
From: Sape Mullender <sape@plan9.bell-labs.com>
In-Reply-To: <20071101170234.13E9E1E8C55@holo.morphisms.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: e3f3eb3e-ead2-11e9-9d60-3106f5b1d025

> It's also why this doesn't work:
> 
>> Tcache	asks whether the server is prepared to cache
>> Rcache	makes lease available with parameters, Rerror says no.
>> 
>> Tlease	says, ok start my lease now (almost immediately follows Rache)
>> Rlease	lease expired or lease needs to be given back early
>> 
>> Tcache	done with old lease (may immediately ask for a new lease)
>> etc.
> 
> because the Rlease/Tcache sequence is a s->c->s
> message.  If a client doesn't respond with the Tcache
> to formally give up the lease, the server has no choice
> but to wait.

Correct.  And if the server *does* wait in that case, single-copy
semantics are maintained.  My assumption is that clients will, in
general, be well-behaved and use Tcache to allow the server to reuse
the file earlier than indicated in the lease.

Any maliciousness on the part of clients in this scheme would result
in (possibly one-time only) temporary denial of service to users
sharing a file; such users are not usually maliciously inclined.


Indeed, the Rlease/Tcache sequence forms a s->c->s interaction
and the second half (c->s) is a necessary one for synchronizing
the client's release of the file to the next client's access to
that file.

This discussion reminds me of the distributed file system discussion
raging in the eighties.  I'm showing my age (and nothing has changed,
but much has been forgotten).

	Sape