🚀 go-pugleaf

"Binzhong Zhou" <Binzhong.Zhou@csiro.au> wrote in message
news:43d73188@newsgroups.borland.com...

> But what will happen if the requested data will not be transfered
> immediately from the server due the data need to be fetched from
> somewhere else on the server or the data is too big for instantaneous
> transfer?

Then you need to either:

1) just let it wait.  Maybe move the code into another thread so your
program is not blocked while the data is fetched.

2) design your protocol to work asynchronously.  When the client sends a
command, don't have it wait for a response immediately.  Let it cache the
command for later use and then go off and do other things, and use a thread
or timer to read the responses separately.  When a response is eventually
received, the client can match it up to the original command so it knows
what to do.  This also allows responses to be sent back in a different order
than the order that the commands were sent.  In other words, if the client
sends commands A and B, and A takes longer to process than B, then the
server can send a response back for B before A.

> Likewise, the server will similar issue from the client site if the server
> request data from the Client. The event handlings from the Indy TCP
> Client/Server do not give me much suggestions how to handle the situation.

Most Indy clients do not have asynchronous events.  If the server can send
an unsolicited command to the client at any moment, then the client has to
continuously poll the socket for incoming data.  A reading thread works best
for that, and that also plays into the asynchronous model above.  In your
transmitted data, put a small header at the beginning of each packet to
identify what the packet data is meant for - a response, a command from the
server, etc.


Gambit