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.

Thanks!
LVL 1
razza_bAsked:
Who is Participating?
 
nociConnect With a Mentor Software 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.
0
 
QlemoConnect With a Mentor 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.
0
 
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!

Thanks!
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
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?
0
 
razza_bAuthor Commented:
I would say -> client then that's in control to make that connection
0
 
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.