When I go offline with my Mac OS X 10.6.8 machine, getmyip() yields 127.0.0.1, but doesn't raise an InternetConnectivityError. This has implications for components like the nodemanager and its advertise thread.
What happens is that when emulcomm's _is_valid_ip_address function is employed to check the local IP of a test socket, it happily returns localhost (after performing a couple of weird checks that have nothing to do with the validity of the address as such).
I think the desired function would be _is_ipv4_address_loopback_or_multicast (i.e. from IPv4 address ranges 127/8 or 224/4), and if it is, we take this as an indicator that we aren't connected to the Internet at the moment. Link-local (169.254/16) and this-host-on-this-network (0/8) would be further logical candidates. A larger list of potentially un-routeable adresses is available from RFC6890.
It might be worth the effort to write up a little IPv4 library to abstract out this (and other) functionality so it can be reused with greater ease.
A side effect of fixing this issue could be that user code needs to be amended to correctly run offline by catching the InternetConnectivityError (which isn't necessary at the moment). It's fine to continue then by just letting, e.g., the local IP in a socket operation be 127.0.0.1, but you would need to be explicit.
When I go offline with my Mac OS X 10.6.8 machine,
getmyip()yields127.0.0.1, but doesn't raise anInternetConnectivityError. This has implications for components like the nodemanager and its advertise thread. What happens is that when emulcomm's _is_valid_ip_address function is employed to check the local IP of a test socket, it happily returns localhost (after performing a couple of weird checks that have nothing to do with the validity of the address as such).I think the desired function would be
_is_ipv4_address_loopback_or_multicast(i.e. from IPv4 address ranges 127/8 or 224/4), and if it is, we take this as an indicator that we aren't connected to the Internet at the moment. Link-local (169.254/16) and this-host-on-this-network (0/8) would be further logical candidates. A larger list of potentially un-routeable adresses is available from RFC6890.It might be worth the effort to write up a little IPv4 library to abstract out this (and other) functionality so it can be reused with greater ease.
A side effect of fixing this issue could be that user code needs to be amended to correctly run offline by catching the InternetConnectivityError (which isn't necessary at the moment). It's fine to continue then by just letting, e.g., the local IP in a socket operation be 127.0.0.1, but you would need to be explicit.