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 :) Bye! Marco _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
