How messaging infrastructure maps topic to IPC/TCP layer for PUB/SUB?

Question

Usually people would just work above this layer - but I am now working on this layer where I need to map the PUB/SUB many-to-many messaging relationship to a IPC or TCP infrastructure - which naturally, I could have only 1 publisher binding per address.

The alternative I could think of each has their own drawbacks:

1. Adding a daemon and route the messages. This add a single point of failure as well as an additional layer during messaging.
2. Adding a registry. Adds a single point of failure and also cannot notify the newly started processes.
3. Disallow multiple publishers on the same topic - lose some flexibility on arranging architecture.
4. Pre-define a port range and IPC address range and every process periodically retry connecting to them. Add delay on service discovery and all ports must be available from OS.

So how does the modern messaging software packages like JMS, LBM doing this? I know Tibco RV and Reuters doing through approach 1) - anyway I could avoid such a daemon process?

I am using Java if it matters.

Thanks.

Answer 1

I would try to tackle the reqs by creating a local daemon on each machine, that spoke jms locally and then provided persistence.

I would use TCP broadcast to a known port to advertise topics and queue associations to IP addresses and ports. You could then establish direct connections to the advertised ports to publish or subscribe to messages in a transaction.