[OpenAFS-devel] Stop me before I NAT again...

[Mitch Collinsworth]

On Tue, 30 Sep 2003, Derrick J Brashear wrote:

> On Mon, 29 Sep 2003, Todd M. Lewis wrote:
>
> > After setting PROBE_INTERVAL to 25 seconds via "fs checks -interval 25",
> > this makes my client check the up servers as well as the down servers
> > every 25 seconds, which keeps my NAT mappings fresh.  It also hits my
> > fileservers 20+ times as often, which is probably not a Good Thing.  In
> > fact, I would expect this technique to be about as popular among the
> > OpenAFS keepers as the sys_call_table hack is with Alan Cox.  Still,
>
> Why? In general it's not a bad idea, but you don't want to make it the
> default or suddenly every client is generating a lot of unneeded traffic.
> no problem there.

Question: what will this do if the client has an intermittent network
connection.  For example if I'm using a laptop on a wireless network
and step into the elevator (where I lose my connection when the doors
close), ride up 6 floors and then step out of the elevator (whereupon
I regain my connection).  Will the probes that are sent during my brief
"disconnect" cause fileservers to be marked down?  Will they be
immediately marked up when the next probe is sent?  Will this sequence
of events cause more grief that this or will it be mostly painless due
to the increased probing frequency?  [Yes, we've already made the joking
observation that we need to add a WAP in each elevator!]


> > it's just a proof of concept.  Of course I would _never_ run this sort
> > of thing from home except as a test (wink wink)!
> >
> > So, here's the question: would an afs_CheckServers()-like function that
> > did a natkeep-like thing with a configurable ttl -- all optional and
> > properly integrated into configure of course -- for the purposes of
> > running OpenAFS clients from behind NAT boxes be welcome, or should I
> > slither back to my evil dark slime pit?  If the former, I would welcome
> > suggestions about how best to use the existing osi_XXX() networking
> > calls for this purpose. (They must be there for a reason; calling
> > socket/connect/sendto may not be The Way, especially in a kernel module...)
>
> It's been on my list (which never shrinks). Ideally you don't need a
> configure option, just run-time configuration. I'm happy to argue merits
> with people about it if there are people who think I'm nuts. I'd have to
> look at code before I can make any code suggestions.

In general this sounds like a great idea.  I'm not certain about the
run-time configuration idea though.  Again, what about mobile clients
that may pop up behind a NAT one time and on their own IP the next?
I think we need to decide that either a) it's ok to make this change
global for all clients, or b) it's not ok, only NAT-bound clients should
do this, and therefore the client should somehow auto-discover if it's
NAT-bound dynamically and adjust its behavior accordingly.  Then it will
be safe to let users install the client w/o a sysadmin having to watch
over their shoulder to make sure they don't screw up.  Or worse, if the
wrong installation options being chosen means the clients can DOS the cell
then it's only a matter of time before someone does this malitiously
rather than accidentally...

-Mitch