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 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
