I know you are correct regarding the closed ports for Ping. It has been our experience that a few of our customers in fact have these ports closed. What I have done to "Ping" them was to use the "InternetCheckConnection" and if that fails then hit it with a "HTTPGET". And finally if that fails return an appropriate error code.

Glenn


>Using a real PING isn't a good thing because many sites disable those ports that are used by PING. Ultimately you need an HTTP client to check to be sure that you can access the site in question. I'm not sure - it looks to me like this function actually does use HTTP because you specificy a URL not kjust a domain name.
>
>+++ Rick ---
>
>>One other thing, Rick. I know you implemented the ping function with a HTTPGET but what about the wininet function as follows:
>>"
>> Platform SDK: Windows Internet
>>
>>InternetCheckConnection
>>Allows an application to check if a connection to the Internet can be established.
>>
>>BOOL InternetCheckConnection(
>> LPCTSTR lpszUrl,
>> DWORD dwFlags,
>> DWORD dwReserved
>>);
>>
>>Parameters
>>lpszUrl
>>[in] Pointer to a null-terminated string that specifies the URL to use to check the connection. This value can be NULL.
>>dwFlags
>>[in] Options. FLAG_ICC_FORCE_CONNECTION is the only flag that is currently available. If this flag is set, it forces a connection. A sockets connection is attempted in the following order:
>>
>>If lpszUrl is non-NULL, the host value is extracted from it and used to ping that specific host.
>>If lpszUrl is NULL and there is an entry in the internal server database for the nearest server, the host value is extracted from the entry and used to ping that server.
>>dwReserved
>>[in] Reserved. Must be zero.
>>Return Values
>>Returns TRUE if a connection is made successfully, or FALSE otherwise. Use GetLastError to retrieve the error code. ERROR_NOT_CONNECTED is returned by GetLastError if a connection cannot be made or if the sockets database is unconditionally offline.
>>"
>>
>>This appears to do a "real" ping
>>
>>Glenn
>>
>>
>>This looks like a "
>>>>Yeah, I wasted a ton of time trying to track that down. I'm sure there is some caching going on with this, and it actually does have some useful side effects. For example, you can write a method that hits a website to establish a session. In another method, you do some other operation w/o having to reinitialize the session. You don't need to share an instance of the object between the methods for this to work. I wonder if there is a way to "clear" this cache?
>>>
>>>Clear all, close all <g>...
>>>
>>>The issue is that the WinInet runs its request on separate threads that never shut down. Those threads just sit and wait for new requests. I wasn't aware that the timeouts don't get set on a per instance basis - I have to check that out again, but if it doesn't work it surely is something that happens inside of WinInet.
>>>
>>>The good thing is that because this works this way you can keep Cookies between requests. I suspect CLEAR DLLS will do the trick too...
>>>
>>>+++ Rick ---