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 <[email protected]> wrote: > Though, not sure where TTL should be defined: per message or/and per > in-mem queue . > > > 2013/12/27 artemv zmq <[email protected]> > >> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
