We act on reachability after the first callback so I don't think we
are reading meaningless data. The bug report that I filed ("22909423
SCReachability reports no connectivity after connection is established
- 9.0 regression") shows how we use SCReachability.After this event, we have changed how we act when SCNetworkReachabilityCreateWithAddressPair reports unreachability - we now send an application-layer ping right away to check the connection. However, it would be useful to have sample code that shows how to use Reachability as per Apple's recommendations. We now connect to a DNS name so that DNS64/NAT64 has a chance to work but that creates its own set of problems when using GCDAsyncSocket which uses BSD sockets (that's a subject for another email :) Imran On Thu, Sep 24, 2015 at 10:04 AM, Quinn "The Eskimo!" <eski...@apple.com> wrote: > > On 23 Sep 2015, at 19:22, Imran Patel <aes...@gmail.com> wrote: > >> We don't use DNS and connect to an IPv4 address directly >> from the client. > > Yikes! You know about the following, right? > > <https://developer.apple.com/news/?id=08282015a> > >> 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? > > That's interesting. Most folks don't need to do this because CFSocketStream > and above are already doing it for them. However, if you're using BSD > Sockets directly then, yes, you need this code. > > In which case I generally recommend that you 'debounce' reachability changes. > It's definitely possible to get transient reachability failures as the > network reconfigures. A classic example is the 'accidentally kick out the > Ethernet cable' problem: you don't want to kill the connection as soon as the > interface goes down because it may well come back up with the same interface > IP address as before, in which case the connection is likely to recover. > > Are you sure you didn't kill the connection based on reachability info from > /before/ the first reachability callback? If you run reachability > asynchronously, which you should be doing, SCNetworkReachabilityGetFlags > doesn't return meaningful data before the first callback, and it's easy to > get confused by that. > > If you think you've got the reachability code right then, yeah, it's worth > filing a bug about it. It'd help if you had a reproducible case or, if not, > solid logging for how things proceeded. > > <https://developer.apple.com/bug-reporting/> > > If you do file a bug, please post the bug number, just for the record. > > * * * > > On 23 Sep 2015, at 22:03, David Schinazi <dschin...@apple.com> wrote: > >> You should not be using SCNetworkReachability to preflight your connections >> or tear them down. > > If you're using low-level networking then using > SCNetworkReachabilityCreateWithAddressPair to tear down a connection is > reasonable enough. That's exactly what CFSocketStream does. However, it's > also a good idea to not be /too/ aggressive about it. > > There's a strong correlation between closing a connection like this and > timeouts. Does it make sense to use timeouts? Does it make sense to use a > different timeout if your source IP address went away than if, say, the > remote peer is not responding? These are complex questions but, in general, > I prefer to err on the side of: > > * using long timeouts > > * keeping the user informed as to what's going on > > * allowing the user to manually retry > > The mechanics of this can get complex (-: > > 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 > > This email sent to aes...@gmail.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
