To simplify this for all, the only things the SystemConfiguration Framework can tell you are what network interfaces your device is connected to and details about that connection. It cannot really tell you about the hops and path if any between that connection and some destination somewhere else. That information might in some situations be extra valuable like a VPN or PPP connection layer that says you've got an IP address on a network that you are trying to create a connection to another device on the same network. That might be a really strong hint of success or failure. But even then, it's only really valuable information to diagnose conditions when a connection fails within a designated timeout period. The only really definitive result is no interface connected.
It's very much like catching a bus that has no reserved seating. Even with a timetable the bus is limited by unknowable traffic and road conditions. In an all IPv6 world that might be a bit better. But that's far away. Sent from my iPhone > On 2015/06/09, at 13:39, David Schinazi <[email protected]> wrote: > > Rick, > > To pile on, you should always try to connect and if that fails use > reachability to get notified when you should try again. > > This topic will be discussed during the WWDC "Your App and Next Generation > Networks" session Friday at 11am, I'd recommend attending or watching the > video. > > https://developer.apple.com/wwdc/schedule/ > > David > > >> On Jun 8, 2015, at 19:02, Vincent Lubet <[email protected]> wrote: >> >> SCNetworkReachability can only have very limited view of the network >> topology from the point of view of the device. It should be used as a hint >> after a connection that something has changed in the configuration of the >> device and that it is worth trying to connect again. >> >> If the connection failure is not caused by the configuration of the device, >> then SCNetworkReachability is not going to give a useful hint -- for example >> when the server or a router is down >> >> Vincent >> >> >>> On Jun 8, 2015, at 4:03 PM, Rick Mann <[email protected]> wrote: >>> >>> So, the biggest problem has to do with network timeouts. I guess in these >>> situations, SCNR would report connectivity, but it would ultimately fail, >>> resulting in the same behavior, correct? So there should be no problem with >>> going ahead. >>> >>> >>>> On Jun 8, 2015, at 16:01 , Joshua Graessley <[email protected]> wrote: >>>> >>>> >>>> SCNetworkReachability may return reachable in situations where the >>>> connection will not succeed. Your preflight check does not solve the >>>> problem. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jun 8, 2015, at 3:56 PM, Rick Mann <[email protected]> wrote: >>>>> >>>>> I thought I'd seen advice from Apple engineers (Quinn?) that instead of >>>>> first checking SCNetworkReachability, we should just try to make the >>>>> actual connection, and then take action (e.g. alert the user) only if >>>>> that fails. >>>>> >>>>> But of course, if there's going to be a long timeout, I don't want to >>>>> make the user wait that long. >>>>> >>>>> In my app, there are many moving parts. Background processes try to make >>>>> network connections (that should not necessarily complain if they fail), >>>>> sometimes the user initiates network connections...it's challenging to >>>>> get it all correct. >>>>> >>>>> What was the specific advice regarding checking SCNR vs. just trying to >>>>> connect? >>>>> >>>>> Thanks, >>>>> >>>>> -- >>>>> Rick Mann >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Macnetworkprog mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/macnetworkprog/jgraessley%40apple.com >>>>> >>>>> This email sent to [email protected] >>> >>> >>> -- >>> Rick Mann >>> [email protected] >>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Macnetworkprog mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/macnetworkprog/vlubet%40apple.com >>> >>> This email sent to [email protected] >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Macnetworkprog mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/macnetworkprog/dschinazi%40apple.com >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Macnetworkprog mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/macnetworkprog/dangerwillrobinsondanger%40gmail.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com This email sent to [email protected]
