I have an application that remotely speaks to another application. There's a lot of coordination between the two applications, but they can exist on their own with out the other, just with restricted functionality (one is functionally a GUI for the other one with some control functionality).
In the process of building up communication protocols for these two applications (the projects are developed independently from one another on different repos), we've built up several sockets that we use. There are a few sockets that use fundamentally different paradigms for communication, so those can't be combined, but there some that are really similar.
For example, application A sends application B status messages every so often, which tell the orientation of some hardware and this is sent at regular intervals. Application A also however sends additional interval messages that are sent a fixed intervals that have nothing to do with these hardware messages.
What I'm not understanding is at what point does combining these two channels into a single socket with two separate topics make sense over maintaining two separate sockets? It seems ridiculous that other one way interval published messages would eventually add up to N extra sockets, especially since sockets have to be configured and identified at some point. At the same time if the messages are conceptually different, and on application B, a different subscriber is going to be handling the messages anyway, why should these messages exist on the same socket?