Firewalls can play a big part in this perhaps either end does not allow ICMP through You could try a simple connect on the ip with the correct port setting the connenttimeout to 15000 (15 seconds) This should typically give you 3 different possible outcomes Depending on the indy error response, you will have a bit more info e.g. a 10054 is different from a 10061, and is different from a timeout
your firePhil Scadden wrote: > I have a program that connects to a remote server with an Indy > idTCPClient component on a specified port. > What I am trying to do is improve diagnostics for when the server doesnt > respond. Ie there are two possible > reasons for failure. > 1/ The server is unreachable or blocked > 2/ The listening program on the server is down. > > When a failure occurs, I thought I would try pinging the server to see > if present from in the code. No go. > Ping returns an access denied - though using the ping command on the XP > client works fine. Strange. > Any other ideas for distinquishing 1 and 2? The firewall settings around > both client and server are pretty extreme. > > __________ Information from ESET Smart Security, version of virus signature database 4636 (20091125) __________ The message was checked by ESET Smart Security. http://www.eset.com _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
