I checked "OverbyteIcsPingTst" sample. Tested it and pinging or ping error, everything finishes in a couple of seconds for a complete list and that includes internet pinging. Most of my pings will most likely be over LAN. After all suggestions, I plan to; 1- ping all clients that claim to be active using TPingThread 2- clients that complete ping without error, do additional test if client software is actually running.
That's all fine except one thing, I am completely novice as to what kind of a connection/component should I be using on item number 2 above? Is there anything which can be used in a thread not to block server side software? For me, even establishing a connection will be enough to be sure that client software is up. I don't need to send anything at all (if such an option possible). Thanks. --Ertan -----Original Message----- From: TWSocket [mailto:twsocket-boun...@lists.elists.org] On Behalf Of Angus Robertson - Magenta Systems Ltd Sent: Saturday, March 12, 2016 8:13 PM To: twsocket@lists.elists.org Subject: Re: [twsocket] Pinging multipe hosts > *Subject:* Re: [twsocket] Pinging multipe hosts > *From:* Ertan Küçüko_lu <ertan.kucuko...@1nar.com.tr> > *To:* "'ICS support mailing'" <twsocket@lists.elists.org> > *Date:* Sat, 12 Mar 2016 19:34:21 +0200 > > I thought, at first, that ping might be a solution. After reading your > post, I better find another way to check if client is running. More > details about subject: > - I will be writing both applications that running on server and > client. > - Client will inform server first time it is running thru a > webservice. > - Client will inform server every minute it is running thru a > webservice. - If it is more than a minute and client still didn't > inform that it is running, I would like to know that client is really > alive, or busy and couldn't say that it is running. > - If client is really closed, I will do some database operations on > server side. Look at the sample OverbyteIcsPingTst which illustrates ping using a thread, so your application is not blocked while testing a host. As François says, it's better to test the protocol, in your case by sending your own defined packets back and forth every minute. This is very low overhead. But there is no notification if an open TCP connection is lost, until you try to send more data when it will fail after a timeout. But beware opening a TCP connection to a host that is offline is a effectively a blocking operation and will timeout after about 40 seconds preventing any other new connections during that time. That is when it's better to ping first since it has a controlled timeout of a few seconds so you get a failed response more quickly. I did all this 10 years ago tracking 500 London buses with wifi on parts of their routes, so connections dropping all the time, but had to FTP data to and from them when they were online. All this was controlled from a SQL database with a web application showing which buses were online, last contact, and environmental stuff like failed fans that meant the PC would overheat and die, as dozens did. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
