[zeromq-dev] Reundance/Failover Capabilites?

[Hak Mem]

Martin,

I would posit that the correct behavior should be different:

1. The application at initialization should be allowed to specify the option
for auto-reconnect which is true by default

2. In case of disconnect, the appplication *should* be notified. Clearly,
you can further allow the application to turn of these notifications, but I
think that would tend towards baroqueness and notification by default which
the app can ignore is not a bad behavior.

In most trading application, auto and hidden queueing of messages would be
lead to disasters - like in an order sending application or even a canonical
application receiving market data. In an order sending message if I cannot
send order messages then I - as in the operator needs to immediately
notified so I can correct things.

For example in the receiving market data case, we delineate the following
cases of no-data:

1. There is *no-data* by the generating process - the matching engine is not
generating prints and new prices - and I am getting no data - good.
2. There is *no-data* by the generating process - the matching engine is not
generating prints and new prices - and I am getting data - kinda absurd and
extremely rare scenario
3. There is data being generated by the generating process - but my network
is not receiving it and hence neither am I - bad
4. There is data being generated by the generating process - but my network
is receiving it however the internal broadcasting process is not sending it
to me - bad
5. There is data being generated by the generating process - and the network
is fine and my internal broadcasting process is sending it but the "last
meter" network is down so I cannot receive it - bad

As you imagine there can be a few other scenarios - but we would like to
know about #5 as soon as possible via disconnects notifications.

Hope this helps!

-hak-


On Mon, Oct 13, 2008 at 4:47 AM, Martin Sustrik <sustrik at fastmq.com> wrote:

> Hi Evan,
>
> > My question is about the semantics 0MQ provides for redundancy/failover.
> From
> > what I can tell, there are currently none -- is that correct? I couldn't
> see
> > anything regarding this in the documentation, but there's also a bullet
> point
> > on the front page stating that a goal is to be decentralized, which
> implies
> > that this might be in the works?
>
> I assume you are speaking about applications reconnecting after
> network/application failure rather than about guaranteed delivery.
>
> Currently, when peer disconnects, you are notified about the event via
> callback function and you can reestablish the connection if needed.
>
> This is rather unconvenient, therefore we are working on automating it
> (should be available in version 0.4). The idea is that applications
> won't be even notified about connection failures and 0MQ will reconnect
> automatically as soon as possible. The messages sent by the application
> will be queued in the meantime and actually sent to the network
> immediately after reconnection.
>
> Martin
>
> _______________________________________________
> 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/20081013/a43eb00e/attachment.htm>