On Fri, Nov 30, 2012 at 9:38 AM, Marco Trapanese <marcotrapan...@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. in all cases I see a very dangerous behavior to process messages > floating in the queue if the sender is not still connected. > These only apply to your very specific case. In many cases there is no danger at all, the behavior may even be desirable. Consider a log monitor where a producer spews a bunch of error messages and then dies. The receiver would be very interested in those error messages arriving. -Michel
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
