Re: Bonjour Via Peer-Peer WIFI - Reachability Issue
Re: Bonjour Via Peer-Peer WIFI - Reachability Issue
- Subject: Re: Bonjour Via Peer-Peer WIFI - Reachability Issue
- From: "Quinn \"The Eskimo!\"" <email@hidden>
- Date: Wed, 12 Nov 2014 08:59:06 +0000
On 11 Nov 2014, at 21:54, Jens Alfke <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden