• 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: Best practices for interpreting network reachability flags?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best practices for interpreting network reachability flags?


  • Subject: Re: Best practices for interpreting network reachability flags?
  • From: Allan Nathanson <email@hidden>
  • Date: Sun, 9 Sep 2007 19:05:46 -0400

Rich -

What you are likely running into is a system which HAS a modem service enabled. In this case, if the system is not currently connected to an ethernet/wireless network the modem "can" still provide a path off the system (but you'd have to "connect" first). This is indicated by the kSCNetworkFlagsConnectionRequired flag.

The test most applications will want to make is the following :

  if ((flags & kSCNetworkFlagsReachable)
      && !(flags & kSCNetworkFlagsConnectionRequired)) {
	// target is reachable
  }

- Allan


On Sep 9, 2007, at 5:51 PM, Rich Siegel wrote:

Good afternoon,

I've written some code which schedules a SCNetworkReachabilityRef and inspects the reachability flags before attempting a recurring automatic network connection (think "software update" or "email check"). I've been fairly strict in interpreting the reachability flags: if (0 == (flags & kSCNetworkFlagsReachable)) then I don't attempt to connect.

Unfortunately, I've been getting reports from beta sites saying that their automatic connections aren't working, even though they're connected. Typically this happens after a transition; for example they were using an AirPort connection at the office, put the laptop to sleep, brought it hope, woke it up, and connected to their AirPort connection at home. A couple of sites have reported refusal to connect after putting the laptop to sleep at the office and waking it up at home, then plugging in an Ethernet cable to use their home LAN.

I'm unable to reproduce any of these behaviors with the resources available to me; but I'm wondering whether my interpretation of the flags is overly strict. Would it be better for me to assume that kSCNetworkFlagsReachable is only one of a number of flags that indicate that it's worth attempting a connection? I realize that with kSCNetworkFlagsTransientConnection, kSCNetworkFlagsConnectionAutomatic, or kSCNetworkFlagsInterventionRequired that success isn't guaranteed, but if I need to test those as well, I can do that.

Thanks for any advice...

R.
--
Rich Siegel Bare Bones Software, Inc.
<email@hidden> <http:// www.barebones.com/>


Someday I'll look back on all this and laugh... until they sedate me.

_______________________________________________
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
  • Follow-Ups:
    • Re: Best practices for interpreting network reachability flags?
      • From: Rich Siegel <email@hidden>
References: 
 >Best practices for interpreting network reachability flags? (From: Rich Siegel <email@hidden>)

  • Prev by Date: Best practices for interpreting network reachability flags?
  • Next by Date: Re: Best practices for interpreting network reachability flags?
  • Previous by thread: Best practices for interpreting network reachability flags?
  • Next by thread: Re: Best practices for interpreting network reachability flags?
  • Index(es):
    • Date
    • Thread