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:27:11 -0700
If you've already written a thread to do that, then great. That's the
reinventing the wheel thing I mentioned earlier, though. Your question
is essentially coming down to, "why use the API instead of the code
I've already written to do what the API does?" Only you can decide
which you'd rather use, but I tend to lean toward standard API
utilization, and encourage others to do the same, because it's that
much less code to maintain. If you're happy with your implementation,
though, then you might not need it.
Luke
On May 20, 2009, at 1:21 PM, Eric Hermanson wrote:
I understand what you are saying, but if you do IO correctly you'll
do it in a background thread anyway. So waiting on a blocking
socket until it times out or gives EOF is normally how IO is done.
So if you already correctly handle that aspect of the IO in your
application (and reconnect the socket as necessary), then that's
where I don't see the advantage of the Reachability APIs. Anyway,
thanks for your input. Maybe I'm just missing the bigger picture
here.
- Eric
On May 20, 2009, at 4:13 PM, Luke the Hiesterman wrote:
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:
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:
@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