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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
