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

Pieter Hintjens ph at imatix.com
Sun Dec 22 11:45:09 CET 2013

On Fri, Dec 20, 2013 at 10:18 PM, Lindley French <lindleyf at gmail.com> wrote:

> I'm starting to think a *lot* of reliability protocols built on top of TCP
> could be done more efficiently if TCP could expose some read-only
> information about its internal ACKing....

You are making such assumptions about "reliability". The network is
unreliable. The receiving application is unreliable. The box it runs
on is unreliable. The database it writes to is unreliable.

Before addressing "unreliability" you must, please, itemize and
quantify. What is the actual chance of network failure in your use
case? How does this compare to application failure?

In most use cases, the #1 cause of failure is poor application code.
Why are we even talking about TCP then?

The only use case I know of where network failures are more common are
mobile/WiFi networks, and even then, that case of TCP accepting a
message but not successfully delivering, without reporting an error,
it is extremely rare, by experience.

Thus you must in any case satisfy the end-to-end reliability problem,
i.e. sender app to receiver app, so e.g. a protocol like FILEMQ would
acknowledge received file data only after writing to disk (perhaps
even with an fsync).

There's nothing TCP, nor ZeroMQ can do to solve unreliability in
calling applications.


More information about the zeromq-dev mailing list