On Fri, Dec 20, 2013 at 10:18 PM, Lindley French <[email protected]> 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. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
