[zeromq-dev] Question about router-dealer sockets

Marco Trapanese marcotrapanese at gmail.com
Fri Nov 30 18:38:44 CET 2012

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 
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 :)


More information about the zeromq-dev mailing list