Thinking about this a bit more, I came to the conclusion that the protocol
api already provides what I'm asking for. I could just implement my own pub
send function, which directly deals with the pipes of a pub, and replace
the original pub send in the sockbase. AFAICS this is not possible in zmq
without patching it, but it can be done in nanomsg using the provided
protocol api.
Still, I would like to hear your opinion about the different strategies,
maybe I'm reading too much in the protocol api and it isn't really intended
to tweak existing sps but only to implement new ones.
Cheers
--
Carlos
On Dec 12, 2015 11:59 PM, "Carlos Pita" <carlosjosepita@xxxxxxxxx> wrote:
Hi all
I have created an issue in github for this [0], but maybe it's worth
discussing here.
pubsub specifies and implements the only built-in subscription based
routing mechanism of nanomsg (and zmq). It could be replicated
user-side by means of other sps (push/pull is close to the internal
pipes of nanomsg/zmq, and nanomsg also offers a protocol api that can
directly deal with pipes). But doing it right is no trivial task.
Anyway, why would someone reimplement the sp? Because there are other
ways of distributing besides "drop msg if pipe is full". True, the
provided one is simple and sensible for the main use case:
distribution to many unknown, unreliable, maybe slow subscribers. But
the question of blocking when pipe is full pops up every once in a
while in stackoverflow and zmq's mailing list. There is even a patch
for zmq that implements that, although not without problems [1], [2].
I think ev
Generalizing pubsub distribution
en Martin Sustrik suggested a couple of years ago a mechanism to put
some back pressure on the publisher.
I think there is a tension between the distribution aspect of pubsub
(namely, the send method of dist) and the subscription and routing
aspects. Some use cases require these last ones but with a different
distribution strategy (v.g. "block if pipe is full", which is a
suboptimal but trivial form of flow control, there are other choices
here... "send anything you can before sndtimeo"). The current
implementation couples the distribution aspect too tight with
subscription and routing. One way out of this is to provide socket
options for different dist strategies (say PUB_NO_DROP). A more
general solution is to have a distbase, in a more OO fashion, so that
distribution could be extended the same as protocols and transports,
by "overriding the send method".
What do you think?
--
Carlos
[0] https://github.com/nanomsg/nanomsg/issues/573
[1] zeromq/libzmq#1597
[2] zeromq/libzmq#1598
