• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Detecting network disconnected
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Detecting network disconnected


  • Subject: Re: Detecting network disconnected
  • From: Quinn <email@hidden>
  • Date: Sat, 31 May 2003 01:37:28 +0100

At 11:13 -0700 30/5/03, Larry Gerndt wrote:
Can you tell me what section, in particular, speaks to my need? Was it,
perchance, the section about getting notified when the local IP address list
changes?

Yep. Take a look at the section "Endpoint Mortality on Mac OS X".

However, when the local IP address list changes, it's possible for the source address of a connection to disappear from the list. This creates a stale connection , one that is effectively broken. Unfortunately, your application is not notified of this. Specifically, you might expect a TCP connection to break (for example, an asynchronous OT endpoint would receive a T_DISCONNECT event), but this doesn't happen. Instead the connection continues to exist but won't be able to send or receive any data.

This problem is fundamental to the TCP/IP protocol itself, and affects both BSD sockets and Open Transport endpoints. A connection is stale if its local address is no longer in the local IP address list. The most commonly affected connections are:

o connected TCP sockets and endpoints

o connected UDP sockets

o non-connected TCP and UDP sockets and endpoints that are bound to a specific IP address (rather than the wildcard IP address)

Your strategy for dealing with stale connections will depend on the nature of your application. For client applications, where connections are typically short-lived, you probably don't need to do anything. If you implement a timeout mechanism the total lack of any data transferred on the connection will eventually trigger your timeout and you will close the connection. Alternatively, the user may choose to manually close the connection.

For client applications with long-lived connections, you should implement some sort of safeguard against stale connections. One technique for doing this is to watch for changes to the local IP address list (using System Configuration framework, as described above ) and, after each change, verify that the source address of each of your connections (which you can get using the code shown earlier ) is still in the local IP address list. If the connection's source address is no longer in the local IP address list, the connection is stale and you should reestablish it (subject to any nuisance call considerations ). Listing 12 shows how to check for stale connections under both BSD sockets and the Open Transport API.

IMPORTANT:
There are a number of ways that an interface can temporarily go down (for example, the user strays outside of their AirPort network, or simple changes which port they're using on a hub), so it's important that you implement a time delay between when the interface disappears and when you shut down the connection.

S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Detecting network disconnected
      • From: Larry Gerndt <email@hidden>
References: 
 >Re: Detecting network disconnected (From: Larry Gerndt <email@hidden>)

  • Prev by Date: Re: Detecting network disconnected
  • Next by Date: Seeking advice: Implementing SSL in a Carbon/CFM app
  • Previous by thread: Re: Detecting network disconnected
  • Next by thread: Re: Detecting network disconnected
  • Index(es):
    • Date
    • Thread