razza_b
asked on
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!
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!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
"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?
ASKER
I would say -> client then that's in control to make that connection
"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.
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.
ASKER
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(machi
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!