[zeromq-dev] Can we customize a behaviour for in-mem queued messages after reconnect?

[Lindley French]

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 <ph at imatix.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131220/782f7afd/attachment.htm>