[zeromq-dev] Identities & PUB/SUB

[Martin Sustrik]

On 04/08/2011 09:31 AM, Pieter Hintjens wrote:
> On Fri, Apr 8, 2011 at 8:11 AM, Martin Sustrik<sustrik at 250bpm.com>  wrote:
>
>> If that's you use case, it should be solved inside 0mq by providing acks in
>> push/pull model. That would allow us to limit number of messages on the
>> flight (HWM) to particular worker to an exact number (even though the
>> network buffers are not yet filled).
>
> Doing acks in sockets is a great idea. It raises many questions, I'm
> sure you've thought of already:
>
> * When does the socket ack, when it receives the message, or when it
> delivers it to the application, or when the application has finished
> processing it? Only the last actually solves the use case.
> * Do you ack every single message (slow) or do you allow acking of
> multiple messages?
> * If you allow ack of multiple messages, how do you do that? Do you
> number messages? Who numbers them? Where?
> * If it's the application that acks messages, what is the API for
> this? Another zmq method?
> * Do you allow nack? If so, do you allow nack-drop vs. nack-requeue?
> * If you allow nack, do you detect poison payloads? I.e. messages that
> kill consumers.
> * If you allow redelivery, do you have any indicator that a message is
> 'redelivered'? If so, where?
> * Do you allow consumers to control the flow, i.e. stop and restart
> getting messages? Or can they only do this by closing their sockets?
> What if they are connected to multiple producers?
> * If you don't implement real-world ack/nacking like this, do you ban
> 0MQ for applications that need it?

Acks only for flow control. No reliability features. Basically, HWM 
algorithm stretched over network. No change to API whatsoever.

Martin