Matthew Miller wrote:
But "is the network up" a generally useful question?
I can picture several situations where "this system is online" or "this
system is offline" can cause more harm than it solves problems.
"Is *the* network up?" "No."
Now software will refuse to connect to 127.0.0.1, ::1 or any
other locally configured network address, for that matter - even
though these addresses are local and can be reached locally without
any network being connected.
cf.
https://bugzilla.redhat.com/show_bug.cgi?id=443385
Firefox refuses to connect to
http://127.0.0.1/ when "offline"
"Is address 1.2.3.4 or dead:beef::1 reachable?" "Yes/No."
This would be a better question locally running software could
ask.
The answer could be determined by just looking at the local routing
tables (aka "ip route" and "ip -6 route" output).
I find that "can I
reach the network resource I need" is the more important one, and the "is
the network up" issue basically a detail.I mean, who cares if the network
is up if the gateway is down? This is why external monitoring (big brother
or the like) is more practical.
"Is resource //FOO on server 12.34.56.78 port 12345 available?"
"Yes/No"
That is the real question you want to know and can be easily
determined by the software which wants to access //FOO on
12.34.56.78:12345 in the first place.
Having a common system service maintaining resource availability state
by actually communicating with other nodes in the network only to
determine resource reachability is probably not very desirable. It
requires communication with all potentially interesting network nodes,
knowledge of many different protocols, etc. That is a lot of effort just
for determining availability which the services themselves will be in a
much better position to determine.
Exploiting the local routing table for a more fine-grained
online/offline status should be quite easy in comparison.
--
Hans Ulrich Niedermann