[zeromq-dev] Proposal for new features in ZMQ.

[Pieter Hintjens]

On Sun, May 15, 2011 at 10:32 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> This is a request for explicit ACKs. Pieter is right that if the ack is to
> be issued only after the message was processed by the app, you are going to
> run into lot of complexity. This way lie distributed transactions et al.

Actually, I've never said this. It's not about complexity and
certainly not about transactions. It's about how much this can be
handled by the transport layer alone.

>From experience there are three places you can ack a message: when
it's received by the transport (queued by 0MQ client side), when it's
delivered to the application (zmq_recv) and when the application has
processed it.

The only way to be sure that delivery = processed is to involve the
application. The mechanism is quite simple. The application ACKs a
message, that gets sent back to the sender, which removes it from its
queue. If the application doesn't ACK, the message eventually gets
delivered to another client. If the application NACKs the message, it
gets pushed back onto the queue and redelivered to another client.

This is bog-standard reliable queue processing, and it's what the LRU
queue is designed to do (though it's a skeleton). You cannot replace
this with a smarter socket unless you do weird stuff like treat the
recv as an ack, which is what I do in the MDP worker patterns. But
it's weird.

The best you can do purely in the socket layer (and it's already quite
good IMO) is to ack when the message is received by the client queue,
and then to reduce the queue sizes to 1. This ensures that only a few
messages get sent speculatively to clients, and loss can be detected
with timeouts on those.

Martin explained this a while back, it's essentially synchronizing the
send and recv queues.

-Pieter