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/ <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] >> <mailto:[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 >> <https://lists.apple.com/mailman/options/macnetworkprog/vlubet%40apple.com> >> >> This email sent to [email protected] <mailto:[email protected]> > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Macnetworkprog mailing list ([email protected] > <mailto:[email protected]>) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/macnetworkprog/dschinazi%40apple.com > <https://lists.apple.com/mailman/options/macnetworkprog/dschinazi%40apple.com> > > This email sent to [email protected] <mailto:[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]
