Re: Network Reachability APIs
Re: Network Reachability APIs
- Subject: Re: Network Reachability APIs
- From: Luke the Hiesterman <email@hidden>
- Date: Wed, 20 May 2009 13:13:56 -0700
Again, it's the waiting aspect. The advantage is you don't have to
spin and do something in a loop in your code. You go about your
business and let reachability get back to you when it looks like you
can try your connection. This is the same as the advantage of using
pthread_cond_wait instead of writing your own spin lock.
Luke
On May 20, 2009, at 1:10 PM, Eric Hermanson wrote:
Yes, but even if Reachability says a given host or route is
available, that does not mean it will be available one second later,
for example. You still have to try connecting to the host and
transferring data, and you can still get an 'IO exception' (so to
speak) at any time. I just don't see the advantage of using the
Reachability APIs, and in fact they will overcomplicate the matter
in my opinion. Maybe someone can clear this up for me.
- Eric
On May 20, 2009, at 4:00 PM, Luke the Hiesterman wrote:
Your approach requires you to keep testing the send if it fails
initially. Using SCNetworkReachability, you can get an asynchronous
callback when your target becomes reachable, thereby simplifying
your code. You could write something to do that yourself, but then
you'd just be reinventing the wheel. That's why God invented APIs.
Luke
On May 20, 2009, at 12:55 PM, Eric Hermanson wrote:
On the iPhone, what's the point of the network Reachability APIs,
when one can simply open a network socket (or input/output stream)
and observe the EOF notices from the socket to determine network
availability & reachability? In other words, if a network
connection has to be made in the first place, why not just attempt
the network connection via the socket/stream and see if that is
successful, and then also watch for EOF (-1) return values from
the stream to determine when the network is down?
- Eric
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
@apple.com
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden