[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