🚀 go-pugleaf

Old Wolf wrote:

>I am using Indy 10 that came with BDS2006, in C++.

That version is quite old.
You should probably download the latest version as Remy has done a
hellalota work on it in the 1.7 years since BDS came out.

>My application accepts multiple connections on a TIdTCPServer
>and re-routes them all on the same TIdTCPClient connection,
>then listens for responses and sends them back to where the
>initial request came from.

Ok, so you are a "concentrator" or "front-end controller"

>I have managed to write an OnExecute handler for the
>TIdTCPServer so that inbound packets can be read, and then
>call IdTCPClient1->Socket->Send to send it on upstream. Is
>IdTCPClient thread-safe or do I need some extra protection
>in here?

I wouldn't think it is. I think you need to serialize access to the
single (client) pipe.
How do you handle routing the return response?
Is it one question, one response, next question? No interleaving?
Or does the return contain an ID that lets you route it?

I would think a ReadThread and a WriteThread for Client.
Server adds questions to WriteThread's fifo queue.
WriteThread serially forwards the requests over Client connection to
mainframe.
Mainframe returns data to Client connection's ReadThread which
forwards them by writing to the Server, and thence to the user.
Each user has their own Server socket, so there should be no
contention there.
Then, if you have throughput issues, bottlenecked in the ReadThread
waiting to write to Server, you could add write queues and threads on
the server side as well.

>I have been able to read responses by setting up a TTimer
>on the main form, and polling the IdTCPClient for incoming
>messages. However I'm not sure if this is the recommended
>strategy.

No, I would not reccommend that.

"Old Wolf" <oldwolf@inspire.net.nz> wrote in message
news:466cbb16$1@newsgroups.borland.com...

> I have managed to write an OnExecute handler for the
> TIdTCPServer so that inbound packets can be read, and then
> call IdTCPClient1->Socket->Send to send it on upstream. Is
> IdTCPClient thread-safe or do I need some extra protection
> in here?

You need to serialize the writes yourself.

> I have been able to read responses by setting up a TTimer
> on the main form, and polling the IdTCPClient for incoming
> messages. However I'm not sure if this is the recommended
> strategy. Waiting for a blocking response in the same
> function where I sent the message to the IdTCPClient will
> not work because there I am in a thread of the Server, and
> the message received might be the message intended for a
> different thread.

I would suggest using two dedicated threads with the TIdTCPClient.
Have one thread contain a queue of outbound requests and continously
sends thems them when available, and another thread that continuously
reads the inbound responses that arrive.  That way, when your
TIdTCPServer receives a request, it can pass it on to the queue thread
and then continue on with its own things, and then the response thread
can pass the response back to the TIdTCPServer once it becomes
available.


Gambit

On Jun 12, 4:35 am, "Remy Lebeau \(TeamB\)" <no.s...@no.spam.com>
wrote:
> "Old Wolf" <oldw...@inspire.net.nz> wrote:
> > [I'm making a concentrating router]
>
> I would suggest using two dedicated threads with the TIdTCPClient.
> Have one thread contain a queue of outbound requests and continously
> sends thems them when available, and another thread that continuously
> reads the inbound responses that arrive.  That way, when your
> TIdTCPServer receives a request, it can pass it on to the queue thread
> and then continue on with its own things, and then the response thread
> can pass the response back to the TIdTCPServer once it becomes
> available.

Ok, sounds like good advice. (Thanks to Bob too).
Do I make my threads descend from TThread, or
from TIdThread ?

"Old Wolf" <oldwolf@inspire.net.nz> wrote in message
news:1181608221.077134.252370@g37g2000prf.googlegroups.com...

> Ok, sounds like good advice. (Thanks to Bob too).
> Do I make my threads descend from TThread, or
> from TIdThread ?

It doesn't really matter.  TIdThread is just a wrapper around TThread.
For something like this, TThread will work fine.


Gambit