Hi,
I've a question about designing a client/server app using Indy 10. Currently, I've several applications installed on various computers which must be able to receive messages sent by another application. It will send short command as "restart", "shutdown", and so on in oder to "pilot" these applications.
The first and the more intuitive way will be to include in all the applications which have to receive messages (I call them "slaves") a TIdTCPServer or more generally a Indy's server component. The client will control them by connecting to them and sending the message. But it's a little bit difficult to proceed in a such way, since if several applications which must be controlled are installed on the same computer, it would be compulsory to choose differents ports for each server embedded in the applications, tell the administrator to open these ports if a firewall is set, and so on.
So I've thought about implementing this system by replacing the server component by a client component which use this kind of behaviour :
while (true)
Command := MyIndyClient.ReadLn();
Execute(Command);
end while
In a nutshell; each slave has a TIdTCPClient and is connected to the server which broadcast messages. In a separated thread, it waits indefitely for a message sent by the server. When a message is received, it parses it and do some useful actions; then, restart to wait for another message.
First question: can I consider this method reliable ? Can I really use it in oder to avoid including a socket server in all my slaves a server ?
Second question: this method cannot be used if ReadLn() returns if nothing is received during a long time (hours, for instance), since it's possible that I need to broadcast just one or two messages each day (and my client should never be disconnected !). I know that Indy is "fully blocking", but I don't know if the system socket APIs accepts to "keep alive" a connection which is not used during several hours. Could someone explain me if it is possible ?
Best Regards,
A.R.
