I have spawned a number of cmd processes to manage the ping process for looking for live IPs (about 20 class c networks)
Phew! That's going to be a bit ugly, and pinging by it's nature is prone to false negatives.
Much easier to write to a central message file and get the clients to collect the message(s)
When you write a message to the file you timestamp it.
The clients poll the file every so often, and compare the timestamp to a local timestamp - if it is newer then all the messages with a more recent timestamp get displayed.
The client updates it's local timestamp to match the most recent message displayed.
The client timestamp would probably be stored in HKCU or a small text file in the user's profile.
Doing it this way has a number of major benefits:
- Processing load is distributed amongst the clients.
- Failure (or shutdown) of the transmitting server will not cause message delivery to fail.
- Clients which are shut down when the message is sent will get the message when they start up / log on.
- Messages can be more easily targetted at individuals or groups.
- You are less likely to miss clients due to temporary network issues - probably one of the reasons that you are sending the messages in the first place
- Messages can be given an expiry time, after which they are ignored.
- Optionally if the type of message can stand the extra delay the central file may be stored on a replicated file system and then accessed on the local server
I think that using this technique will be far more robust and far less resource intensive for your particular application.
BTW, don't forget to use UTC for timestamps.
