On Thu, Apr 15, 2004 at 05:44:28PM +0200, Tom Ivar Helbekkmo wrote:
> Ivan <ega_at_math.chalmers.se> writes:
> > I still think that Coda is a step in the right direction, to make
> > the functionality independent of the [presence of] communication channel.
> 
> Absolutely.
> 
> > It can (and probably should) be extended to behave well when other
> > properties of the connection change, besides presence/absence.
> 
> I've gotten a bit further now: I've got a script triggered by the
> change in carrier status on my laptop's ethernet interface, that
> flushes the IP routing table and triggers a DHCP lease renewal.  Then,
> the acquisition of the DHCP address lease triggers another script,
> which stops the currently running Venus, and starts a new one.  The
> result is that a new, working, connection is quickly established.

Ok... STOP IT!!! This thread is filled with so much speculation and
misinformation that I don't even know where to start correcting.

- Coda servers depend on having a fixed IP address (and port).
- Coda clients don't have any such dependency, they can switch addresses
  and ports, and in fact my laptop does this all the time.

I have both 100Base-T in the office, and wireless with a dynamic (dhcp
assigned) IP. At home I use either the wireless with a static IP (going
through a masquerading firewall, or use a direct ppp dialup link with
a 56k modem pccard. And all this address/port switching happens in real
life and fairly often, several times times a day I switch between wired
and wireless, _without ever restarting venus_.

However, the switch is not necessarily transparent. i.e. in many cases
we in fact have to go through a disconnected state, simply to maintain
the required consistency guarantee. It also depends on how the switch
occurs on what the behaviour is. In some cases, we simply get an
RPC2_NAK and can immediately rebind to the server. In other cases we
actually get disconnected for a bit (i.e. new route might not yet be
usable) and we switch to disconnected mode and will reconnect within the
next 5-10 minutes when the automatic serverprobe discovers what we have
a usable connection to the servers.

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.

So we really can't carry over the existing state (all the callback
promises) because we don't really know whether the client has in fact
seen any of the recent invalidations. The end result would be a stale
entry in the client cache that will not even receive a callback when the
object is modified again. The server thinks the client was told, and the
client is happily giving the stale data to the user because the server
hasn't told it that the object has changed.

> The down side is that I lose my Coda token, and have to run clog.

Run 'cfs cs' (cfs checkservers) instead of restarting venus. It will
simply trigger a new serverprobe at that time instead of waiting for the
automatic probe in the background. You can't reliably restart venus when
there are applications that actively have open file references anyways.


As far as your firewall is concerned. There are 2 settings that are
useful.

First of all, typical NAT firewalls seem to forget about UDP
'connections' withing 3 minutes or so. However our keepalive probe
occurs only once every 12 minutes. I actually changed this to 150
seconds in the Coda-6.0.5 release because it seems like everyone and
their brother is connecting through firewalls these days.

Secondly, a lot of firewalls are pretty dumb as far as fragmented
packets are concerned. As only the first IP fragment contains the UDP
port numbers a trivial firewall that does not defragment and only
forwards tends to drop all but the first fragment. However this single
fragment is no use without the missing pieces. TCP doesn't suffer from
this because it provides it's own fragmentation (MTU/MRU).

Greg Troxel had similar problems when running Coda over IPSec and
identified the SFTP side effect and ValidateAttr RPCs as the main sources
of oversized packets. So way back in the early Coda-5.x versions the
SFTP sideeffects were clamped down to 1024 bytes of data and there is a
venus.conf option that limits the size of the ValidateAttrs packets.

Again in release 6.0.5, I changed the default setting from 50 to 21
which avoids any fragmentation on networks with an MTU larger than
1452 bytes. Setting it to about 15 should bring it in line with the
current SFTP packetsize, and going below that isn't really possible
without rewriting large parts of RPC2.

Jan