On Nov 30, 2012, at 11:38 AM, Marco Trapanese <[email protected]> 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 :) Marco, 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: http://zguide.zeromq.org/page:all#Why-We-Needed-MQ 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. cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
