-
Mac Newbold authored
First, fix up the isup generation code. When a node/OS doesn't send its own isups, but is pingable, we need to fork and ping it, and send ISUP when it pings. The code was there, but was broken. This fixes it. The one time that it may cause errant messages is in modes other than MINIMAL. When we get BOOTING, we check if it needs isup generated. If we have to ping it, when it pings we send ISUP. This means that if we are really in NORMAL mode, we might send ISUP before the node sends REBOOTED (or TBSETUP in NORMALv1), and it would look funny. But that case will be really rare, since everything that sends REBOOTED or TBSETUP has no reason not to send ISUP itself. Second, after mailbombing myself a couple of times, Kirk and I decided I'd better put some throttling in the notification code that stated uses. So now it throttles itself and digests the messages if they're sent too close together. The first message it gets will get sent immediately. If the next one is long enough after that, it sends it immediately too. If a message comes too soon after sending one, we queue it up, and send it later after enough time has passed. Currently it is set to wait 5 seconds between messages, so it will send up to 12 per second, and wait no more than 5 seconds before sending a message that is queued up. (Something similar to this may be a nice thing in the rest of our stuff, but it was made a lot easier by the fact that stated already had a polling loop in it. Without that, you'd have to use alarms or some other weird thing, which would be painful.)
349db7bf