On 11 Nov 2014, at 21:54, Jens Alfke <j...@mooseyard.com> wrote:
> Can you elaborate on that? It's the part I don't understand. As I said above,
> I thought that a "no" meant the IP routing tables were telling me "you can't
> get there from here." In what cases would there be a false negative?
Well, it seems you already have an example, that is, peer-to-peer Wi-Fi.
In a highly dynamic network environment, reachability is incredibly hard to get
right. For example, in the peer-to-peer Wi-Fi case, reachability is not a
simple routing table query because the act of connecting to the service brings
up the interface over which that connection will run [1]. This is also true
for peer-to-peer Bluetooth, VPN On Demand, used to be true for WWAN on iOS, and
so on.
It could be argued that reachability should always get this right and thus any
false negatives are simply bugs in reachability. There's two problems with
that argument:
o That's not the documented semantics of reachability. Apple has consistently
told folks not to preflight [2]. Here's a quote from the "Networking Overview"
doc.
Important: The SCNetworkReachability API is not intended for use as
a preflight mechanism for determining network connectivity . You
determine network connectivity by attempting to connect. If the
connection fails, consult the SCNetworkReachability API to help
diagnose the cause of the failure.
<https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/Introduction/Introduction.html#//apple_ref/doc/uid/TP40010220>
o Bugs are a fact of life; all our software operates in the presence of bugs
all the time. However, by using reachability to preflight your network
requests you're taking a relatively minor bug and turning it into something
that prevents the user from getting work done.
Notwithstanding the above, if reachability is giving an obviously wrong answer
in some specific situation, you should definitely file a bug about it.
> One of the reasons I don't want to try first is that the attempt might take a
> long time to fail due to DNS timeouts or whatever.
You're treating this like an either-or problem, which it is not. You can
simultaneously start the connection and the reachability query. After a short
timeout, consult the current reachability state and, if things are looking bad,
pass a warning up to your clients. They can then make the high-level decision
as to whether to unilaterally cancel the connection, display the warning to the
user, or whatever.
* * *
Taking a step back, the traditional networking idea of "connecting" is really
showing its age. It's a bad fit for a lot of the things we're need to do in
the modern world.
Imagine you're implementing an app like iTunes's Wi-Fi sync. Right now you
have to write a tonne of code to monitor the state of the network and maintain
your sync connection. It would be much better if the system did that: you
would give it a service name (a Bonjour name or a DNS name) and the system
would try to maintain that connection, sending you simple "we have connected"
and "we have disconnected" events as the connection comes and goes.
Maybe one day (-:
Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
[1] Incidentally, this is why the traditional BSD resolve-then-connect approach
is so broken; you have to give the system the highest-level information you
have available--a Bonjour name if you start with a Bonjour name, a DNS name if
you start with a DNS name--so it can make high-level decisions about the best
way to connect.
[2] ... in recent years. There's been a lot of misinformation promulgated
about reachability, some of it from Apple. If you find Apple docs that don't
toe the party line here, please file a bug against them and email me the bug
number.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (Macnetworkprog@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
