Re: Network Reachability APIs
Re: Network Reachability APIs
- Subject: Re: Network Reachability APIs
- From: Eric Hermanson <email@hidden>
- Date: Wed, 20 May 2009 17:03:43 -0400
I think that's precisely my point. If I have to manage the data
transfer mechanism independently of the Reachability APIs in the first
place, then that was why I asked the question, why use the
Reachability APIs at all? I guess that was the basis for my original
post. Sure, Reachability is a nice thing to have to notify me in a
general sense if a given network MAY be reachable (such that I can
update a UI status element), but beyond that, for actually
transferring a boat load of data back/forth (which is what my app
does), I pretty much have to handle network outage, reconnect logic,
and IOException/EOF myself (as one would expect). I think anyone
would have to handle these things. Hence my original question. Thank
you for your thoughts.
- Eric
On May 20, 2009, at 5:00 PM, Luke the Hiesterman wrote:
Ok, so you write your implementation to simply send the first bit of
data repeatedly in some background thread. If that first send ever
succeeds, does that guarantee the next one will? No, it does not.
There's no way you can write anything that guarantees that at any
given moment that a send will succeed. So, the question comes to you
- what would you like the reachability API to do?
Luke
On May 20, 2009, at 1:54 PM, Eric Hermanson wrote:
The Reachability only tells you if a network MIGHT be available.
You still have to write code to do the data transfer. What if
Reachability tells you the network is available, but then you go to
transfer the data (a second later) and the network is no longer
available? You still have to handle that situation, don't you? I
don't see how the Reachability does what I, or anyone else, needs.
It only notifies you of a condition that WAS true at the time of
notification, but that condition may not hold true when the code in
your Reachability callback is actually executed. See what I mean?
Or do I misunderstand.
- Eric
On May 20, 2009, at 4:27 PM, Luke the Hiesterman wrote:
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:
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
_______________________________________________
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