On 04/08/2011 09:31 AM, Pieter Hintjens wrote: > On Fri, Apr 8, 2011 at 8:11 AM, Martin Sustrik<[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
