[zeromq-dev] Why 0mq doesn't define TTL for message (for in-mem queue)?

Ian Barber ian.barber at gmail.com
Fri Dec 27 16:31:13 CET 2013


Part of the difficulty with that is providing usable guarantees - for
example, a fair chunk of messages might be buffered in the TCP send or recv
buffers, particularly with small messages. It is relatively straightforward
to set HWM to 1 (or some other small number) and implement a queue prior to
sending (you can poll for sockets to become writeable). Sustrik pretty much
got rid of non-transport buffers in nanomsg due to the mental model
complexity that arises from having them, and I must admit I'm sympathetic
to that viewpoint!



On 27 December 2013 12:30, artemv zmq <artemv.zmq at gmail.com> wrote:

> Though, not sure where TTL should be defined: per message or/and per
> in-mem queue .
>
>
> 2013/12/27 artemv zmq <artemv.zmq at gmail.com>
>
>> hello there!
>>
>> Just came to my mind -- why 0mq doesn't define TTL?  0mq still queues
>> messages inside in-mem queues, so eventually it's sort of queueing system
>> (pls. don't blame me, I'm just saying) . Right?
>> And all queueing solutions do have TTL .
>>
>> Overall, I'm big fan of 0mq, but some principal design choises make me
>> really curious.
>>
>>
>> BR
>>  -artemv
>>
>>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131227/76cb19d9/attachment.htm>


More information about the zeromq-dev mailing list