Rich Grise <(E-Mail Removed)> wrote:
> So I need to know what signal to have my quasi-daemon wait for.
There is no standard signal that is used to tell applications that the
address they are bound to has changed, and you usually won't need to
know this unless you are
1) A client application that has a long-established connection. In this
case, it is much better to program reconnection/timeout logic in
your application, with keepalive set to on. This helps make your
program resilient to other classes of network errors.
You could use such a method to good effect in your application
actually. The redirection server would maintain a TCP connection
to the dynamic server, with a heartbeat, and when it detects that
the connection has broken, it will do its reconfiguration. This
also has the benefit of being able not-redirect when it detects
your webserver is down.
2) A server application that is bound to a specific interface.
Most server network applications bind themselves to INADDR_ANY,
meaning they will accept connections coming in on any interface
(when I say interface here, I'm talking about the IP address, not
the device (such as eth0)).
Servers shouldn't be configured via DHCP though (in theory), or
at least, they shouldn't be configured with a _changing_ addresss.
But we don't like in a perfect world, and static addresses are a
luxury for most people, esp. when you're on an ISPs plan.
When an address changes, two things of note will happen.
1) Any existing connections will get lost. The client and server will
eventually detect that the connection is no more (timeout), and
will do whatever it is it does in that failure mode, whether it be
exit or reconnect.
2) If a server (the end doing accept() ) is bound to a specific IP
address, then it will cease to accept connections. AFAIK, it
will not receive any error notification. I think this is where your
problem comes into play. You want to find out when such an event
occurs. Correct?
There are three approaches I can think of off the top of my head. The
first, and most classical approach would be for the server to register a
handler for SIGHUP, which will reread it's configuration file (if any),
and reinitialise listening network sockets (meaning you must close them
first). You would need to set up your dhcp client to send your program
the HUP signal when this happens.
If you're operating a forked server, one simple approach would
be to exec over yourself. I beleive sendmail does this (or at least, it
did at one stage, from what I've been told.
Another, most portable method, would be to poll for changes. So in your
accept loop, you would do something like the following pseudocode.
recreate listening socket
bind listening socket to new address
record current address bound to
while true
select on listening socket, timeout after 30s
if address has changed
close listening socket
recreate listening socket
bind listening socket to new address
record current address bound to
...
You'll notice that there is part there that can be factorised into a
function or two. The disadvantage of this method is that you have to
poll every so often (in this example, every 30 seconds). Depending on
how fast your DNS entry gets updated after an update (and it usually
takes a fair while), this will do well, esp in a scripting language
which is nice and portable.
Note that your problem is even simpler, as you've already uploaded a
file with the new IP address inside it, so all your program needs to do
is detect when the file has changed (timestamp).
************************************************** *******************
Actually, its even easier than that, as your application is a CGI
app, so is started afresh for every request, so the IP you pull out
of your config file is really the latest one!
************************************************** *******************
But if you wanted something that was lightning fast (and I say this just
for reference, as its unlikely to concern your problem), then you would
need some platform-dependent way of being notified of certain events.
In the case of network reconfiguration (such as an interface being
configured with a new address), then under Linux you could use a
rtnetlink socket to watch for routing table updates. However, this is
probably far more work than you really ought to be spending.
A simpler way under linux would be to popen "/sbin/ip monitor address",
and do reconfiguration checks on output, taking care to make the file
handle line-buffered. This will require that the iproute tools be
available. Normal users can do this too (reading netlink doesn't require
root priviledge).
> Or would that be a full-on daemon, if I like run it in the background?
It's not a deamon at all, its a CGI application.
So in summary:
1) Either: maintain a TCP connection with heartbeat, and reconfigure
on consistent heartbeat failure.
OR
2) Poll for change in your control file (although your application
has the correct information when it starts anyway).
OR
3) Monitor for change using some platform-specific method.
4) I write too much. But hey, in defence its useful for the Googlers,
and it helps me to think of what I'm teaching my students. And its
kind of fun too.
5) I still write too much. ;^)
--
Cameron Kerr
(E-Mail Removed) :
http://nzgeeks.org/cameron/
Empowered by Perl!
Similar Threads
Linear Mode
