[zeromq-dev] pub matcher again
Martin Sustrik
sustrik at 250bpm.com
Fri Aug 20 18:47:49 CEST 2010
Jon,
Sorry for delay.
> ok found that in both the pub and sub constructors so set them both to
> true and removed some asserts.
>
> so i need to store the outpipe on the sub and the inpipe on the pub.
Right.
> presumably the send and recv methods on the respective sockets are still
> no-ops right?
Right.
> now I assume that when setsocketopt for a sub is called then it has to
> push a message down the writer pipe,
> or is it to send a command and write down the pipe? Will the 'magic'
> under the hoods route it to the other publisher(s)
> automagically?
Send it via the pipe. That way the recepient would be able to correlate
the pipe it got the subscription through with a pipe in the opposite
direction.
> I have also wondered whether the prefix tree needs to remain on the sub
> end to remove the race that
> a subscription is changed/added removed and is in flight to the pub
> whilst messages are sent...
I would say so. The worst case scenario is when the incoming pipe stores
large amount of messages. The you unsubscribe. If there was no filter on
sub side, you would have to read them all even though you've already
unsubscribed.
> In that case if it is still in the sub-side matcher, the app will behave
> correctly?
Yes. It's duplicate filtering, once on pub side, once on sub side. The
application logic won't change.
> sorry for so many questions.... I only just found the zmq_init_t today
> responsible for that 1 byte message on connect...
> (and i still think the socket type should go in that....)
It should.
Btw, I'm cc'ing the list so that people have an idea of what's going on.
Martin
More information about the zeromq-dev
mailing list