[zeromq-dev] 0MQ 2.0 Model Question

Martin Sustrik sustrik at fastmq.com
Thu Oct 8 10:50:53 CEST 2009

Hi Tom,

> from what i understand about message queing is that it will shield you 
> from having to worry about delivery of messages. even if the receiver 
> goes down, a message queing system will automatically reconnect at a 
> later stage when the receiver is back up and guarantee delivery.
> Examples like MSMQ also store details on disk locally so even if your 
> machine dies, and you bring it back up it will read the disk and will 
> try to recover & send the message
> if i look at the 2.0 Model with the sockets, i'm a bit confused how 0MQ 
> would achieve this. 
> With a SUB / PUB  sender/receiver example i can see that if i send a 
> message to the receiver it will arrive as soon as the receiver starts 
> up, but only as long as the sender process is still running.

> in the case where i first startup the sender, send a message, quit the 
> sender, startup the receiver and then start the sender again, it does 
> not automatically recover the send message. it just goes missing. 
> Am i mistaken in assuming any message queing system should do this ? or 
> do i misunderstand the model or implementation ?

That's pub/sub model. The model is based on the notion of late joining. 
I.e. publisher is producing messages continuously, consumers are binding 
to the producer at a specific moment. From that point on they are 
getting messages. They won't get old messages as the amount of old 
messages is in theory infinite.

The alternative is req/rep model, where each message exchange is 
initiated by requester. The number of messages is always finite 
(request+reply). In this case messages are never dropped.


More information about the zeromq-dev mailing list