"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
