Re: Spike in SSL handshake failures since iOS9 rollout
Re: Spike in SSL handshake failures since iOS9 rollout
- Subject: Re: Spike in SSL handshake failures since iOS9 rollout
- From: "Quinn \"The Eskimo!\"" <email@hidden>
- Date: Thu, 24 Sep 2015 18:04:31 +0100
On 23 Sep 2015, at 19:22, Imran Patel <email@hidden> 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 <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden