[RESOLVED] Connect apps together on Tcp

Hello,
I am building an intercom class library that will be included in many of our apps. The intercom will be responsible for creating a Tcp a connection between itself and another app running the intercom on the same network (or computer.) When the intercom is running, it needs to be able to TX and RX to any number of other apps running the intercom. The problem I'm having is getting 2 apps to navigate the port selection together. Since a port can only be used for a listener once on any machine, if an app is connecting to 3 other apps, it needs to use 3 different ports (at least that's how I understand it.)

Every app uses a Mutex to make it a guarantee it runs only once on any computer at any time.

My approach to this to has the intercom class creating a Udp listener on a port that is selected from a range of ports (49000-49010). The intercom will also broadcast a hello Udp packet on every port in the range at 15 second intervals.The payload for this message will include a unique identifier for the app instance, and all of the available ports between 50000 and 50200 on the computer hosting the app.

The communication between 2 apps to negotiate the connection goes like this...

App1 - Hello here are my available ports
App2 - I've looks at your ports. Please connect to me on these Rx and TX ports
App1 - Done. These are the port I connected to.
App2 creates the connection. done

I am finding a few pitfalls, the biggest being the Udp packets are not guaranteed to arrive and if they do, they might not be in the correct order. Also, if there are multiple apps already running and others come online and says hello, all existing apps reply at the same time. This is causing synchronizing issues and headaches.

I have considered having a dedicated port for each app, but since the apps may run on the same machine, this would fail since a port can be used as a listener only once on a computer.

Ultimately, my approach to this seems to be getting exponential complex which in my experience is one of the first signs of a bad approach so I'm thinking there is a better way.

Does anyone have any experience getting their apps to communicate with each other? and if so what is the approach you have used?
Thanks for looking
kevin

Typically you would have the server listen on a fixed pretty number, the clients would make a connection to this port. A connection is defined by the combination of server ip, server Port, Client IP, Client Port. Having multiple clients connect to the same port on a server is not a problem, if it was a web server would need a separate port for every single concurrent user.

The issue is probably down to how you are managing the connections on the server side. I am currently on my phone so can't really give an example, however if you search these forums you spotless find plenty of examples of how to implement a tcp server application.

Thanks for that.

There is no dedicated server however. I'm trying to create a cluster where each app connects directly to each other.

Check NATS (www.nats.io) - it has pretty good support in .NET and you can use it as communication layer so all your apps will be just clients that talk using messages. There are different patterns to send messages to listeners so you can organize your apps communication very flexibly.

Another "feature" is that it is designed for availability and scalability for cloud applications. Simply you can run a cluster of few NATS servers in a network and even most are down but one is still available, the clients will continue working and automatically switching to the available server.

UDP is unreliable, as you've found out, but it does seem like the way to go. Perhaps you can simply add a step (or actually, just modify a step you already have). Basically, computer A sends out a message, computer B must reply. If A doesn't get the reply, it re-sends X number of times. If it doesn't get a response in those X times, it assumes that B is down. Set X based on how noisy your network is.

One key is to keep the UPD portion as small as possible. It doesn't sound like the packet size should be an issue, but you did mention packets fragmenting, which would suggest your packets are too verbose. There are ways to deal with packet fragmentation, but avoiding it is always going to be easier.

I figured this out and was way overthinking it.

The right way to do it is to have the intercom create a single tcp listener and when the app announces with a hello on udp, it sends the port it's listening to in the payload. When another app gets the announcement, it creates an internal class that handles sending data to that port. It certainly cleaned up a big mess of code.

Thanks to all who participated.
kevin