One TCPClient --> Multi TCPListeners

Hello Experts

Looking for advice, views, experience for a project our company are working on.

What it is our project consists of is 2 C# executables both being multi-threaded, one being setup as a TCP listener and the other being setup as TCP Client, these 2 do not talk directly to one another, but what they will do is communicate to 20 machines and both the exe’s will be hosted in the application server.

Exe 1 (TCP Listener) - communicates with 10 machine clients this way we are controlling the business process.
Exe 2 (TCP Client) - communicates with the other 10 machines which are listeners(code setup by vendor), this way they are doing the controlling of the business process.

Exe 1 we have completed that's fine.

Exe 2, how this works is we load up from a SQL DB table the 10 IP's of the each of the 10 machines and put each IP into its own thread and we connect directly to them, and the 2 way comms begin sending/receiving based on signal protocols information.

Our company have always setup to be controlling the complete process were we are the listener only and every machine is a client, but due to inexperience people in the project have some doubt using it the other way around.

My question is has anyone set up in this fashion before were 1 TCP client executable connects straight into multiple listeners and how they found it?

I appreciate all advice, views and experiences.

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
What's your concerns exactly with exe #2? Since your team seems to be experienced with multi-threading, it should work, there is not much of a difference between both exe, network wise.

Who starts the communication? If the client needs to actively query each machine, it is usually better to run that in the single thread with short timeouts.
Large DB write operations should be kept in another thread from the communication, but that also applies to exe #1.
nociSoftware EngineerCommented:
I think you should get your terminology straight.
A process that is listening on a socket for work is called a Server (Listener).
A process that is connecting to a server is called a Client.  So in Ex. 1 all your machines are clients and the exe 1 is the server.

For ex.2 all machines are servers, and the central system is the client.
(This is the same in the X protocol, where the Display/Keyboard/Mouse SERVER runs on the workstation, and the client processes are the session manager & X application running on a central system.)

It is a misconception to think of a Big Central machine as 'THE SERVER'..., yes it can be a server..., but be a client as well in other respect.

Controling the Business process is something completely distinct from controlling communications.
Controlling the business process is about the status messages received from machines and send to machines. And coordination between them and f.e. storage fascilities packing / unpacking etc.
Controlling the communication is making the connection and exchanging messages in an agreed upon language. (ie. Protocol).
The Client / Server issue is mostly about communication.

And some machines may be able to connect outwards, but most machines i have seen need to be connected to. (ie. they act as server).
Most were PLC based that would allow you to fetch some internal state to be processed by the central systems.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
razza_bAuthor Commented:
hello, thanks for comments. appreciated.

exe 1: we're the ones acting as server(in an app server) and listening for clients connecting to us, just thought is was just the common way to always do it and a lot more easier to manage(and our perception was us controlling the business that way) - but as noci says "controlling the comms"....seems we are not in anyway then for exe1, but as for "controlling business" we are doing this in both cases for exe 1 and exe 2 within our protocol signals on how we handle that.

exe 2: we're the client(in a app server) connecting into multiple remote tcp hosts acting as a server.
x10 of this to connect to them all...
clientSocket = new TcpClient();
clientSocket.Connect(machineIP, machinePort);

Qlemo  - that's exactly, so yes we do the same basically just new(ing) up a thread for each of these I agree and keeping these timeouts very short. As for the comms we have that in the same thread but they are not large packets of info, but maybe I should look into separating that into its own thread too.

noci - Exactly I totally get you, I like the way you put that!

Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

razza_bAuthor Commented:
sorry just to be clear.

"Controlling the communication is making the connection"  - who is actually doing the controlling Client or Server?

noci do you mean being the client then that's in control to make that connection, or the server being the controller waiting for a client to connect?
razza_bAuthor Commented:
I would say -> client then that's in control to make that connection
nociSoftware EngineerCommented:
"controlling the communication" in this sense: the one who initiates communication.
any party can stop communication at any moment (or be forced to due to loss of connection )
then the client will always be the initiating  party ==> the one that retries connecting.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.