Back in Mono 4 days, we had to work around an issue where our macOS app would 
get "stuck" if a laptop was wandering through an airport and latched on to a 
captive portal page that intercepted one of our messages back to our server. 
And when I say latched on, we never recovered until the app was restarted. We 
had to dig into the mono code and figure out how to reset it ourselves. I think 
that this was fixed in Mono 5 (or later Mono 4). Not sure which version you're 
working with, but this might be something to look into.

Sorry I don’t have a lot of details off the top of my head. It was a couple of 
years ago and I have been trying to put this out of my mind ever since (

-- 
Mike

On 10/30/2018, 4:41 PM, "Macnetworkprog on behalf of Jens Alfke" 
<macnetworkprog-bounces+mike=dolan....@lists.apple.com on behalf of 
j...@mooseyard.com> wrote:

    A co-worker is struggling with handling online/offline transitions in some 
networking code in a Xamarin (i.e. Mono, i.e. .NET) app for iOS. The code 
maintains a TCP socket to a server. If the device goes offline or into Airplane 
Mode, the code needs to close the socket, so that the higher levels of the app 
know it’s not online anymore.
    
    The behavior he’s reporting is that, when the device is put into Airplane 
Mode, the socket acts as though it’s still connected. It doesn’t close, and 
(obviously) doesn’t receive any data, but most strangely the socket doesn’t 
fail after data is written to it. My knowledge of TCP tells me that if you 
write to a socket, but no ACK packet is received within ~15 seconds, the socket 
will be closed with an error (I think ECONNRESET?) But he swears this isn’t 
happening — it’s like the writes go to /dev/null.
    
    I’ve never seen this, but I’ve mostly been using NSURLSession or at least 
NSStream, not POSIX socket APIs, so the behavior may be different. My first 
guess was that Mono is doing something sketchy; he looked into the source code 
and found that it uses send() instead of write() to write to the TCP socket; is 
that kosher?
    
    The workaround he’s adopting is to run a SCNetworkReachability notifier, 
and to close the socket and go into offline mode when notified that the host is 
unreachable. I’m uncomfortable with this, since I know Reachability can be 
unreliable and this usage doesn’t go along with the best practices, i.e. using 
it just as a trigger to connect, not disconnect.
    
    So what’s the deal with Airplane Mode? I would assume that it takes down 
all network interfaces, which would close all sockets. But it doesn’t. Even so, 
I would assume that writing to a TCP socket would cause an error pretty soon; 
but apparently it doesn’t.
    
    Any advice?
    
    —Jens
     _______________________________________________
    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/mike%40dolan.org
    
    This email sent to m...@dolan.org
    


 _______________________________________________
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

Reply via email to