The wording suggests that DEALER, at least, does its best to maintain outgoing queues after a disconnection, but not incoming queues. This makes a certain amount of sense when connected to multiple peers. However, it must be taken with a grain of salt, because if a disconnection happens unexpectedly any time after the message passes from 0MQ's queue to TCP's outgoing queue (before sending, during sending, prior to delivery to 0MQ on the other end, or even prior to delivery to the app on the other end) the message will be lost anyway.
This leads to a curious behavior in the one-peer case. If a brief disconnection occurs in the middle of sending 10 messages, you have no way of knowing which, if any messages, were lost. On Fri, Dec 20, 2013 at 8:51 AM, Pieter Hintjens <[email protected]> wrote: > Messages are not being redelivered. They are being queued on an > outgoing pipe, created when you call connect, and when that pipe is > connected, being delivered. Please read the socket pattern specs, RFC > 28 specifically for DEALER semantics. > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
