multiple publishers & subscribers in nanomsg (nng)

问题:

How does one setup multiple publishers & subscribers with a TCP transport. I suspect that you don't do automatic mesh/bus creation. So one needs a unique IP bind point for each publishers, right? They just have the subscribers connect to each publisher on a single socket.

(this was discussed in: https://www.freelists.org/post/nanomsg/does-nanomsg-support-multi-producer-in-pubsub-mode,10 )

Is that basically correct?

The reason I lean to a pub/sub over a bus/mesh approach is because (and I admit I might well be mistaken) -

• I don't need a fully connected mesh
• I figure your radix -tree filtering at each node is better than what I would come up with
• I like the "auto-discovery" aspect of pub/sub as opposed to the manual wiring of the mesh for the bus transports
• (i.e. automatic "entry and exit from mesh")

Basically what I have is 2 producers (that mainly do publishing, but can receive occasional requests to put additional info on the stream being published, so they do need to listen) And then about five consumers who mainly do receipt of the data stream from the publishers, but do need to occasional send requests to the producers.

And yes, I want the pub to be async, as as well as the recv() for the subscribe (no blocking is allowed in the context where I am using this).

So this is a bi-directional pub/sub architecture. And I am looking at the simplest way to implement this. (traffic is pretty light).

---

Of course a UDP transport would be nice for this, but I am not holding by breath.

回答1:

Easy :

Use the NN_PUB/NN_SUB as it was designed, for non-blocking, async, broadcast direction.

Use another async channel "bottom-up", be it a NN_PAIR/NN_PAIR or any another, more complicated Scalable Formal Communication Archetype pattern, like NN_PUSH/NN_PULL or a reversed NN_PUB/NN_SUB that fits both your intentions and latency goals.

Worker processes will be free to .nn_send() whenever either one feels such a need and the rest is in the hands of the "central"-process.

Given the scaling is 1:5 and workflows are light, as you have posted earlier, there are indeed no hidden traps on this, except the lost messages ( again, a principal solution for a reliable message delivery protocol was already proposed in an earlier post ).

On the "central"-node, there you just .nn_poll() these signalling channels regularly ( again, in a non-blocking async manner ) and .nn_recv() data just in a case, when a such channel has POSACK'ed a message to already be present there for being fetched and processed on your application code side.

That's all you need.

回答2:

NanoMSG NNG is very symmetric and orthogonal. I had a couple discussions with gdamore.

Each Endpoint can be push, req, bus, or whatever You can have multiple endpoints (e.g. 2 push, or a push and req/res) Protocol can be in either direction Rec can be blocking, async, or poll based.

If you want to see how to do this, see:

https://github.com/nanomsg/nng/issues/551