[zeromq-dev] XSUB/XPUB upstream messages

[John Muehlhausen]

To my knowledge, I have not used a sub with many pub connections, but I
assume that any subscription messages are copied to all of them.  If that
is the case, then these upstream messages (that are not subscription
related) would seem to be copied to all as well, unless pains were taken to
do something different.

As for a use-case, this one is contrived because I'm not sure that I am
free to talk about the real one.  Imagine a chat system where every
subscriber is interested in a some or all of the messages, and where every
subscriber can generate messages.  The new functionality could be used to
get a new message generated by a particular subscriber all the way back to
the root publisher (perhaps there are routing nodes) where it is then
published to all who are subscribing, perhaps with modifications (e.g.,
from a moderator).

Without the modification there seem to be two approaches:
- use another socket, which doesn't seem ideal since we already have one
with upstream capability
- package the upstream "message" as a sub/unsub pair... I actually tried
this and the trie gets unwieldy above around 7000 bytes, particularly with
stack usage in the recursive trie routines

-John

On Mon, Dec 31, 2012 at 10:06 AM, Pieter Hintjens <ph at imatix.com> wrote:

> On Sun, Dec 30, 2012 at 7:13 PM, John Muehlhausen <jgm at jgm.org> wrote:
>
> > Currently XSUB will not send messages unless they contain a subscribe or
> > unsubscribe prefix (see code fragment below).
> >
> > It would be useful to pass these "malformed" messages anyway, although
> they
> > would not affect subscription status.
>
> It's an interesting proposal, but what specific use cases do you have?
>
> Would you round-robin if the sub has many pub connections, or would
> you copy to all connections?
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121231/4ace1522/attachment.htm>