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: Imran Patel <email@hidden>
- Date: Thu, 22 Oct 2015 12:11:02 -0700
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!" <email@hidden> wrote:
>
> 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
_______________________________________________
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