Re: [9fans] QTCTL?

[Sape Mullender <sape@plan9.bell-labs.com>]

> 2. All 9P messages would still be client->server->client.
> This fits with #1, but also excludes solutions that introduce
> new server->client->server messages after a successful Tcache.

And there is the quandrary.  Allowing server->client->server messages
(aka callbacks) complicate 9P beyond anything acceptable.  On the other
hand, these call-backs make the following possible:

1. Client obtains a lease to a file (say valid for exclusive access in the
   next five minutes)

2. Server needs the file for read or exclusive access by another client
   after one minute and wants the lease returned early.  It initiates
   a callback.

3. Clients flushes all data back to the server (i.e., it performs a series
   of writes

4. Clients responds to the callback

5. Server give s alease to another client.

This is the sequence of actions that maintains consistency for all parties
obeying the protocol.  Not obeying (e.g. ignoring callbacks, not writing back
dirty data) will slow the system down (server must wait for lease to expire)
or will just harm the client not obeying.  Leases are a really good idea, but
for the complexity of callbacks.

If we can have this functionality without callback, that would be really nice.

One could have only client-server-client calls like this:

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.

So Tcache serves two purposes: it gives up an old lease if one existed
and immediately asks for a new one if one is needed.

This might give all the functionality we need without using callbacks.
(Of course, the client still needs a proc waiting for that Rlease while
doing its reads and writes).

	Sape