Imram, You should not be using SCNetworkReachability to preflight your connections or tear them down. The purpose of reachability is to listen for notifications of when to try again after your initial attempt failed. If your initial attempt succeeded, you should not tear it down if reachability changes.
Also note that if you make reachability or socket calls to an IPv4 address directly, you probably won't work over IPv6-only networks and your app will get rejected from the App Store. Here is some documentation on the topic: https://developer.apple.com/library/prerelease/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html <https://developer.apple.com/library/prerelease/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html> David > On Sep 23, 2015, at 11:22, Imran Patel <aes...@gmail.com> wrote: > > Hi Quinn, > > Thanks for the reply. I don't think this is the same issue as what > Jens saw. We don't use DNS and connect to an IPv4 address directly > from the client. Based on our investigations, we suspect the problem > is triggered due to a bug in SCReachability. After the socket > connection is established, we start monitoring reachability changes > via SCNetworkReachabilityCreateWithAddressPair. We think that right > after this, reachability (falsely) reports that the destination is > unreachable which causes our code to reconnect. Not all of our clients > are exhibiting this behavior so maybe some network-specific issue > triggers this? We have disabled our reachability checking code as a > work-around and our metrics indicate that this has improved things. > Does this sound like a known regression? I will file a radar shortly. > > Thanks! > Imran > > On Mon, Sep 21, 2015 at 1:05 AM, Quinn "The Eskimo!" <eski...@apple.com > <mailto:eski...@apple.com>> wrote: >> >> On 18 Sep 2015, at 17:36, Imran Patel <aes...@gmail.com> wrote: >> >>> We see connections being disconnected by the >>> client after socket establishment and before SSL can proceed. >> >> This sounds suspiciously like an issue that Jens raised earlier this month. >> >> <http://lists.apple.com/archives/macnetworkprog/2015/Sep/msg00007.html> >> >> It's possible that tweaks to iOS's connect-by-name feature are triggering >> this change in behaviour. >> >> Regardless of whether you can reproduce it, I still recommend that you file >> a bug about it (including a server-side packet trace). >> >> <https://developer.apple.com/bug-reporting/> >> >> Please post your bug number, just for the record. >> >> Share and Enjoy >> -- >> Quinn "The Eskimo!" <http://www.apple.com/developer/> >> Apple Developer Relations, Developer Technical Support, Core OS/Hardware >> >> >> >> _______________________________________________ >> 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/aesboe%40gmail.com >> <https://lists.apple.com/mailman/options/macnetworkprog/aesboe%40gmail.com> >> >> This email sent to aes...@gmail.com <mailto:aes...@gmail.com> > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Macnetworkprog mailing list (Macnetworkprog@lists.apple.com > <mailto:Macnetworkprog@lists.apple.com>) > 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 dschin...@apple.com <mailto:dschin...@apple.com>
_______________________________________________ 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
