On Thu, Apr 15, 2004 at 08:01:03PM +0200, Ivan Popov wrote:
> On Thu, Apr 15, 2004 at 01:00:11PM -0400, Jan Harkes wrote:
> > The problem is that the servers are stateful and they identify a client
> > by (IP-address,port)-tuple. So when a client switches IP or port, the
> > server simply sees him as a completely new client. But even if we
> > tracked client by some unique cookie, the server doesn't know wheter any
> > callbacks it sent to the old address have been lost as a result of the
> > routing switchover.
> 
> Hmm, just a thought, there could be a rather common special case
> "no callbacks have been sent" or let us keep a sequence number
> on callbacks, which the client could tell the server...?
> Give them a reasonable chance to avoid revalidation and it will
> make a big difference, especially on flaky lines.

But we don't identify clients based on any unique cookie that will be
identical even when the network address changes. So new IP/port tuple ->
new client as far as the server is concerned and we can't take along any
existing callback promises.

Besides, we already have something similar, which actually works even
when the server thinks a new client is connecting. It is called the
Volume Callback. There is a volume daemon that goes through the list of
cached volumes once in a while (10 minutes?) and if no callbacks have
been broken it will get the current Volume Version Vector. This is
changed whenever anything within the volume is modified.

When the client reconnects, the first thing it does is send it's list of
cached volumes & volume version vectors (ViceGetVS rpc or something).
When the server still has identical version vectors, the client skips
revalidating individual objects within those volumes and simply waits
for the volume callback break before revalidating the files. This mostly
works for volumes tend to not get updated all that often.

Jan