From 2165ef3af8d503557c174ca004f242e8aa418cdf Mon Sep 17 00:00:00 2001 From: Derek Atkins Date: Mon, 26 Mar 2001 17:51:34 +0000 Subject: [PATCH 1/1] make-fileserver-deal-correctly-with-client-which-changed-addresses-but-was-offline-when-a-callback-to-it-was-revoked-20010326 "First, some background: The AFS Fileserver tries really hard to keep track of all the "interfaces" of a client. Generally this is for a multi-homed client, so that the server realizes that you are the same client when you come from multiple addresses. However, this also winds up applying to a mobile host whose IP address changes over time. When the Fileserver sees a "new" address, it asks the client for its Uuid and, if that Uuid already exists, it adds this new address to the list of interfaces for the existing host. However, it keeps a callback connection open to the original address. Here's the problem: Assume the client has callbacks registered with the server and then disappears from the network. While the client is off the net, someone else makes a change that causes that callback to be broken. The fileserver can't reach the client, so the break gets added to the delayed callback list. The logic is such that no client requests will be processed by a host while there are outstanding delayed callbacks to that client. Now, if the client comes back on the same IP Address, everything works fine. The fileserver uses the cached callback connection and the callbacks are cleared successfully. However, if the client returns to the network under a different address, this new address is added to the existing host structure and then the delayed callbacks are attempted. Unfortunately it is using the (invalid) cached connection to the old IP Address, so the delayed break fails. Therefore, this client is locked out of the fileserver until: 1) the fileserver reboots, 2) the client returns to the original IP Address, or 3) All the callbacks timeout on their own. This patch will fix this problem. When the client makes a request and the fileserver tries to break the delayed callbacks, if the breaking fails then the fileserver will attempt to find a 'working' interface by probing all the host interfaces for one that responds with the correct Uuid. If that succeeds then it resets the cached callback connection and then breaks the delayed callbacks, thereby regaining the connection to the client and proceeding with the proper cleanup before the original request is completed." --- src/viced/afsfileprocs.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/viced/afsfileprocs.c b/src/viced/afsfileprocs.c index d92e55b..b3e232b 100644 --- a/src/viced/afsfileprocs.c +++ b/src/viced/afsfileprocs.c @@ -314,7 +314,18 @@ retry: else if (thost->hostFlags & VENUSDOWN) { if (BreakDelayedCallBacks_r(thost)) { ViceLog(0,("BreakDelayedCallbacks FAILED for host %08x which IS UP. Possible network or routing failure.\n",thost->host)); - code = -1; + if ( MultiProbeAlternateAddress_r (thost) ) { + ViceLog(0, ("MultiProbe failed to find new address for host %x.%d\n", + thost->host, thost->port)); + code = -1; + } else { + ViceLog(0, ("MultiProbe found new address for host %x.%d\n", + thost->host, thost->port)); + if (BreakDelayedCallBacks_r(thost)) { + ViceLog(0,("BreakDelayedCallbacks FAILED AGAIN for host %08x which IS UP. Possible network or routing failure.\n",thost->host)); + code = -1; + } + } } } else { code = 0; -- 1.9.4