A general comment on 2):

First this is definitely a strange case exposed on Windows by virtue of the
fact that Windows supports such things as Suspend, and Hibernation. The fact
that the laptop in question was disconnected from one LAN, moved, and
reconnected indicates that somewhere, somehow, the state logic that detects
the network connection Plug & Play event isn't working 100%. At least under
these strange circumstances. Assuming that a generalized prohibition on
trapping Windows in hibernation and then swapping its network connection is
not placed on the use of the library, then:

the win32 api call gethostbyname could potentially be used to check the
health of the network connection prior to opening a socket. However this
function does not take a timeout parameter. As indicated in the MSDN
documentation:
The gethostbyname function returns a pointer to a HOSTENT structure-a
structure allocated by Windows Sockets. The HOSTENT structure contains the
results of a successful search for the host specified in the name parameter.

The application must never attempt to modify this structure or to free any
of its components. Furthermore, only one copy of this structure is allocated
per thread, so the application should copy any information it needs before
issuing any other Windows Sockets function calls.

The gethostbyname function cannot resolve IP address strings passed to it.
Such a request is treated exactly as if an unknown host name were passed.
Use inet_addr to convert an IP address string the string to an actual IP
address, then use another function, gethostbyaddr, to obtain the contents of
the HOSTENT structure.

The gethostbyname function resolves the string returned by a successful call
to gethostname.

My suggestion would be to internally spawn a worker thread to make the
gethostbyname call. All the worker thread does is make the gethostbyname
call - we don't even really care about the result. The main thread then
blocks using WaitForSingleObject passing in the thread handle as the
synchronization object and a non-infinite timeout. Should the main thread
fall out of wait due to a timeout we know the interface is hosed. So as not
to screw anything up, should the timeout occur, we just leave the worker out
hanging in the ether until the process is terminated (thus cleaning up any
structures allocated by windows sockets), and killing the worker.

----- Original Message -----
From: "Daniel Stenberg" <daniel_at_haxx.se>
To: "libcurl Mailing list" <curl-library_at_lists.sourceforge.net>
Sent: Tuesday, January 28, 2003 11:22 AM
Subject: Windows people -- help needed!

1)

Bug report #607604 was fixed a long time ago for non-windows platforms, and
I
just want to ask if there's anyone out there who could possibly consider
helping us closing the report by fixing this in the windows version as well?

http://sourceforge.net/tracker/index.php?func=detail&aid=607604&group_id=976
&atid=100976

2)

There is also this interesting patch in bug report #674095 submitted by
aschiffler, that offers a gethostbyname() that can be aborted with a timeout
(for Windows). I would like someone to test it/comment it to become subject
for inclusion in an upcoming libcurl version:

http://sourceforge.net/tracker/index.php?func=detail&aid=674095&group_id=976
&atid=100976

--
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com