Mitch Collinsworth wrote:
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?
Yes, but that's happening now every 10 minutes. We don't want to call afs_CheckServers() more frequently than that. I just did it to test the concept.
Will they be immediately marked up when the next probe is sent?
Yes, that's what afs_CheckServers() does. That's where those "fileserver blah.de.blah lost/found it's cookie" messages come from.
Will this sequence of events cause more grief that this or will it be mostly painless due to the increased probing frequency?
If done right, only NATed boxes would send out increased traffic, and those packets need never make it all the way to the server. I suggest making a separate natkeep-like thread so as not to screw up the afs_checkserver thread. (Or perhaps it could be part of afs_checkserver; 'd'have to look at it again.)
It's been on my list (which never shrinks). Ideally you don't need a configure option, just run-time configuration.
I was thinking some people might not care to have the code in their client daemons at all if they know they don't intend to run it. Run-time config would be necessary either way. In particular, the user need to be able to specify:
* 'on' or 'off'
* the interval between refreshes (shorter than the UDP timeout),
* the initial Time To Live (ttl) for the packets
* ???
Q: Should these be controllable the same way 'fs checks -interval NN' works? (Just what 'fs' needs -- more subcommands.)
I'm happy to argue merits with people about it if there are people who think I'm nuts.
Didn't mean to imply that. I meant that I've found myself initially enthusiastic about what turned out to be bad ideas before, and I wouldn't be surprised if those who understand better than I do how AFS and networking in general work have reservations about this suggestion.
I'd have to look at code before I can make any code suggestions.
Guess I'll have to write some. :-)
No, seriously, studying afs_CheckServers() to see how it results in packets being generated has been a daunting experience. I thought figuring out which servers to toss UDP packets toward would be the hard part. Turns out that's easy. Getting from there to packets going out the back of the box is not at all obvious. I'll have to study the code a few more times before I'm ready to attempt a real natkeep-like implementation within OpenAFS.
(And we'll need a name for this, too. Is "natkeep" okay?)
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?
They are broken now. (Well, okay, NAT is broken by design, but the user doesn't appreciate the distinction.) Let's get the client NAT-proof, or at least NAT-resistant, then tackle the mobile problem.
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.
A straight-forward way to discover whether you're NATted is to send the in and out addresses and ports as the data in a packet to a service which returns the same info from the service's perspective. If the ports don't match up, you're NATted. I don't know of such a service, but it should be a breeze to put up. Would that be an AFS specific thing, or is it generally useful to IP clients?
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...
At least initially, I'd say 'off' is the better default; turn it on as experience indicates it's appropriate. Whether the client, sysadmin, or user makes the call probably depends on how much work you want to put into making each of those three smarter.
--
+--------------------------------------------------------------+
/ [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl /
/ Is a book on voyeurism a peeping tome? /
+--------------------------------------------------------------+
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
