[zeromq-dev] Question about router-dealer sockets

Charles Remes lists at chuckremes.com
Fri Nov 30 18:54:46 CET 2012

On Nov 30, 2012, at 11:38 AM, Marco Trapanese <marcotrapanese at gmail.com> wrote:

> Il 30/11/2012 17:50, Ian Barber ha scritto:
>> Its just message queuing. In the case in OP, the dealer sends, say, 10
>> messages, which get transmitted to the other party (the router socket)
>> and queued there. If the application controlling the router socket does
>> zmq_recv(), it'll get one of them. If the dealer disconnects, the other
>> 9 are still in the queue on the router socket, available for the app to
>> consumer as it wants.
> I understand this. But it makes little sense to me. I apologize for my 
> difficulties.
> The key point is in your last few words: "[...] available for the app to 
> consumer *as it wants*".
> For me, any transmission is meaningless if both router and dealer aren't 
> alive. Or, better, as you pointed out the router should know the dealer 
> has disconnected. Thus, it may decide if it wants or doesn't want to 
> receive queued messages.
> Anyway, may you provide some examples where is useful to receive data 
> after the dealer has disconnected, please?
> Any application I can imagine requires the messages are valid only while 
> both ends are running:
> - if you send commands you don't want they will be executed if your 
> "control panel" isn't running;
> - if you send telemetry data you don't want to receive sensor's 
> information if they are not currently transmitting anything;
> and so on...
> in all cases I see a very dangerous behavior to process messages 
> floating in the queue if the sender is not still connected.
> Of course the same applies is the receiver disconnects and reconnects 
> later. Would you execute any commands queued some time before? You'll 
> likely break up something or worse :)


I think there is a fundamental misunderstanding about how a message queue is supposed to work. If you haven't read the guide yet (zguide.zeromq.org) then at the very least read this section:


The issues you describe are specific to your use-case. You need heartbeating and ack'ing at the very minimum but you need to *build those concepts* on top of zeromq. For example, if you don't want your client to process any more messages if the server goes down, then you need to build a protocol between your client and server so that it behaves that way. In that case, I would have the server send only a single message at a time and wait for an ack from the client before it could send another. Your client shouldn't ack until it has processed the received message.

As I said in the beginning, I think you are misunderstanding the purpose of zeromq. Please read the guide.


More information about the zeromq-dev mailing list