You can make a device to route automatically between transports like this …
see nn_device().
Note however that if you are updating extremely frequently, you might find
that you lose messages as the PUB/SUB pattern drops messages when queues
get full. As TCP generally is slower than inproc, its easy to overwhelm
it. nanomsg has some concerns at present around inproc as well, and I’d be
somewhat cautious of using it in production (test it yourself). (TCP and
IPC are fine though.) However, if you are able to, you can use mangos
(which is a rewrite of nanomsg in Go), as it does not suffer any of the
same concerns. Very soon I think you’ll also have libnng as an option,
which I think won’t have any of the same considerations either. However,
libnng is probably a couple of weeks away from being ready for use in
production apps.
Current PUB/SUB in nanomsg is handled by subscriber filtering, so the
publisher knows nothing about it. I have a plan to create a new version of
this pattern that actually does publisher side filtering, but that will
also be several weeks away I think. (And its likely that this new pattern
will only be available in libnng and mangos.)
- Garrett
On Wed, Jan 4, 2017 at 9:42 AM, Roberto Fichera <kernel@xxxxxxxxxxxxx>
wrote:
Hi There.
I'm evaluating to introduce nanomsg as common communication library for my
multithreaded and distributed applications. I would like to know what is
the best
approach to use for my specific use case.
My application updates thousands of separated data from many different
threads.
For every data I would like to notify the changes to external subscribers.
So my idea is to have a PUB nn_socket using a TCP transport for the whole
app.
Within the app, I could have a SUB nn_socket using a inproc transport
collecting all
subscribers one for each single data (topic) to PUB. Every inproc PUB data
might
wait a new data in a thread and publish the data as soon as it's available.
Finally the SUB nn_socket collecting all the data published could route
the data up
to the PUB nn_socket for delivering outside the data. What is the best way
to
"route" messages between TCP PUB (external) and INPROC SUB (internal)?
If this is ok I would like to allocate inproc publishing threads only for
topics (data) that external
subscribers have subscribed, so having real demand, in order to optimize
the performances.
Then this trigger another question: is there anyway to know the topic
subscribed by a subscriber?
Any suggestion?
Thanks in advance,
Roberto Fichera.