Dave Cragg wrote:
On 11 Dec 2005, at 19:16, Alex Tweedly wrote:
Sorry - was I sounding like a broken record ? And a negative one at
that :-(
Not at all. I really appreciate it. I think many of us are now having
to or wanting to deliver things that have to work in various
networked settings, and we can get carried away with our little bits
of knowledge. Although I know something about things such as http
and ftp protocols, I'm fairly ignorant about many aspects of
networking. I'm glad for any pointers I can get (especially
pointers to pitfalls).
Phew !
Thanks Dave - I was concerned that I was coming over as too negative too
often on this topic.
I have nothing very practical in mind. But it's nice to store away
these snippets of code with an accurate description of what they do.
(note you can have a "network connection" with nothing but a
successful link status - i.e. a hub or switch, there is no certainty
that any other computer is connected; I don't see how that is
sufficient for anything).
Well, in a company setting, and the sales person has returned to the
office from the road with his/her laptop, and has forgotten to plug
it into the company network when he/she starts an app that requires a
network connection... I guess it could perhaps give a better
description of the problem than "invalid host address". (Just
thinking aloud here.)
I think that getting a negative result back from the test gives you the
possibility of a better (and perhaps sooner) error message. I'll give
some thought to how reliable that might be - but off the cuff, it seems
safe to assume that if this test for network fails, then you really do
have no network connection.
But in general, getting a positive result from the test gives you
effectively nothing.
- even if there is a network connection, there may be no internet
connection
(or in your case, there may be no connectivity to the
required part of the corporate network)
- even if there is an internet connection, the part of the net you want
may not be reachable
-even if it is, the server may not be up and running
- even if it is, the service (e.g. http) you want may not be up
- even if it is, it may not accept your connection
- even if it does, the file you want may be unavailable
- even if ......
And even if the internet connection is up, and the first request is
satisfied, it may then die / become unreachable before, or during, a
subsequent request.
Bottom line : if you want to write a robust networked application, it
should never do any blocking operation, should alway be prepared for
errors (or delays) and should gracefully continue with other operations
or user interactions in parallel with any attempted network operation.
And if you do all that anyway, then the initial test was unnecessary :-)
The exception might be, as you suggest, to give a better, quicker error
response in some cases; whether that is worth the risk of unreliable or
misleading error messages is up to the author of each app.
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/197 - Release Date: 09/12/2005
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
