[zeromq-dev] Publisher side filtering... (draft II )

Gerard Toonstra gtoonstra at gmail.com
Fri Jan 14 17:59:57 CET 2011

It looks good to me code-wise, but I can only test this on tuesday against
the setup at the lab.



On Fri, Jan 14, 2011 at 2:33 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Hi Gerard,
>  So, the idea is probably to wait a while to see if any problems pop up.
> Yes. Let's wait for a few days at least.
>  The remainder can be divided in two further steps:
>  1. The changes in the session only ensure that integrity is maintained
>> after reconnects or disconnects. So the app writer doesn't
>>     need to worry about re-issuing sub/unsub requests. The session in
>> the socket will do that on behalf of the user. Since this touches
>>     on the part of the session, I propose to do this last.
>> 2. The xsub does not yet actually send the sub request upstream. So the
>> second patch could be to ensure that forwarding will start to work.
>>     This will then not handle disconnects/reconnects correctly as per
>> 1. Also, the order in which subscribers issue socket/setsockopt/connect
>>     commands has an impact on forwarding subscriptions or not. This is
>> because sub requests prior to a socket connection will store the requests
>>     in the session until a connection is available.
> I would propose the following sequence of steps:
> 1. To actually send the subscriptions up the stream. I'm attaching a patch
> that attempts to do that. Peer review would be appreciated.
> 2. Implement re-sending of subscriptions in case of re-connect. Also
> post-hoc subscriptions (when actual connect happens after the subscription
> itself) etc.
> 3. Implement message filtering in XPUB socket, based on the subscriptions
> received.
> Thoughts?
> Martin

Gerard Toonstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110114/35532b62/attachment.htm>

More information about the zeromq-dev mailing list