On 01/04/2017 06:53 PM, Garrett D'Amore wrote:
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
<mailto: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.
