🚀 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.