So, how exactly does Reachability work? It seems to work similarly to the Unix ping command: anything that can be resolved by ping comes back as reachable, and anything that cannot comes back as unreachable. So a URL like foo is unreachable: consisting of letters, it is sent by ping to the Domain Name Server (DNS), which cannot resolve it. On the other hand, a bogus numerical address like 123 appears to dodge the DNS, so ping (and the Reachability) class don't reject it, even though ping fails to retrieve any packets (test messages) back from such addresses:
~: ping www.apple.com PING e3191.c.akamaiedge.net (96.16.93.15): 56 data bytes 64 bytes from 96.16.93.15: icmp_seq=0 ttl=53 time=8.789 ms 64 bytes from 96.16.93.15: icmp_seq=1 ttl=53 time=8.535 ms 64 bytes from 96.16.93.15: icmp_seq=2 ttl=53 time=8.526 ms ^C --- e3191.c.akamaiedge.net ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.526/8.617/8.789/0.122 ms ~: ping foo ping: cannot resolve foo: Unknown host ~: ping 123 PING 123 (0.0.0.123): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 ^C --- 123 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet lossNow, it's a bad idea to fiddle with DNS (and it requires root privilege on the server anyway), so how would one simulate a server becoming (un)reachable? That is, how can we test our asynchronous NetworkMonitor app? I'll leave this as an extra-credit riddle for you to solve.
No comments:
Post a Comment