Thank you for your help....
I will be looking into it.... ALSO I have seen alot of posts where you
(Remy) have answered to other people and I have alsways found your responses
very helpful... THANK YOU!!! It is much appreciated from my side and I think
from alot of the other post readers!
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:445f8fe2$3@newsgroups.borland.com...
>
> "PeaShooter_OMO" <jacquesvdm@homemail.co.za> wrote in message
> news:445f21f3@newsgroups.borland.com...
>
>> I have seen quite a few examples on how to write Client/Server apps
>> with TIdTCPServer and TIdTCpClient and most do the following:
>
> That is the typical client/server model in general. In most situations,
> the
> clients tell the server what to do. Not the other way around.
>
>> I would like to do things a bit differently, so how do I send something
>> (a
>> string for example) to a TIdTCPClient from a TIdTCPServer whenever
>> needed
>
> You need to find the appropriate client in the server's Threads (Indy 9)
> or
> Contexts (Indy 10) property. You can then access the Connection property
> for that client. Just make sure that you are not writing to the client at
> the same time that the server is responding to a command from the same
> client elsewhere. It is very easy for the server to corrupt its
> communications with that client if multiple threads are trying to push
> data
> to the client at the same time.
>
>> is there a way for the TIdTCPClient to know that it has text waiting
>> to be read without using a timer to poll for incoming?
>
> Indy uses blocking sockets. Unlike non-blocking sockets, blocking sockets
> do not trigger any events when things happen on the socket. Polling
> periodically is the only way to detect incoming data on a blocking socket
> without actually reading the data. Otherwise, use a thread instead of a
> timer, and perform blocking reads that wait for data to arrive.
>
>> 2. The client asks for something and receives a response if needed
>> from the server. (optional)
>>
>> ...time goes by
>>
>> 3. Something happens on the server and it sends something to the client
>
> In order to do that reliably, you need to synchronize access to the socket
> on the server end, so that the server doesn't try to send a response at
> the
> same time as an unsolicited packet, and vice versa. You should also
> format
> your packets from the server in such a way that the client can easily
> differentiate between them. Such as with a fixed-length header that
> indicates whether the packet is in response to a command (and which
> command)
> or whether the packet is a server-generated event.
>
>> Is this possible
>
> Technically, yes. Though you may have to re-think your protocol design in
> order to handle it effectively.
>
>> will I keep the client connections open for the whole time in case
>> the server wants to send something to the client
>
> Yes. Normally, you should be doing that anyway, unless your protolc
> requires a disconnect after each response is received.
>
>> I was thinking about having both TIdTCPClient and TIdTCPServer components
>> on both the Client and Server sides
>
> That is not needed.
>
>
> Gambit
