Hi Remy,
Thank you very much for your comments. I already understand that Indy10 has
client side command handlers, and am thinking of possibly moving to that
version of Indy. The problem for me is that I am still very new to Indy,
and have already coded very much around Indy9 - Due to my current workload,
I just don't know at this time if it would be practical for me to make the
change now.
Since I can use a polling scheme, I may do this for now. In this case, I
would use a lower polling frequency for the clients. 10 - 30 seconds
between polls. I may also make the frequency a user definable option to
assist those with heavy traffic networks.
Additionally, I may also organize it so that the server doesn't handle
client polls if it is already handling a one - to lower bandwidth problems.
Kindest Regards
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:472f6864$1@newsgroups.borland.com...
>
> "RandomAccess" <Not@TellingYou.com> wrote in message
> news:472ebe8b@newsgroups.borland.com...
>
>> I am using Indy 9 and would like to know how something similar
>> can be achieved in this version.
>
> The CommandHandlers are specific to TIdTCPServer in Indy 9. Short of
> re-writting Indy's source code, you can't use CommandHandlers on the
> client side unless you upgrade to Indy 10.
>
>> Basically, what I would like to do is to have the server
>> broadcast a message out to the clients when data is available
>> for them.
>
> TIdTCPClient does not have that functionality built in. You would need to
> create and run a separate thread that continuously reads from the
> connection, processing whatever data arrives and then sending
> notifications to the rest of your application when needed. The same
> principle is used by TIdTCPServer (and TIdCmdTCPClient) internally.
>
>> I was thinking of having the clients poll the server with a
>> simple CMD instead.
>
> That is another option, though would require more bandwidth, and would not
> be as real-time as a broadcast.
>
>
> Gambit
