I have often though that the HWM settings on a socket could have a variant where they drop the oldest message rather than now queuing a new message. The documentation at least is not clear on does it drop the oldest or newest message when the limit is reached. Having explicit control over this would allow some different behaviors, one being discard old messages if they are superseded by new ones. The addition of a specific error return on a send to indicate messages are being dropped might also help, and an getsockopt to see if messages have been dropped.
Note this is just a suggestion, not something I have the time to actually go try and implement. Steve Lord On Jul 18, 2013, at 9:45 AM, CFK <[email protected]> wrote: > Hi all, I'm trying to figure out what socket options I need to set under ZMQ > 3.2.3 to force ZMQ XPUB sockets to drop messages if they are old. I have > time-sensitive messages, any/all of which can be dropped if they are older > than some amount (set by the option) before ZMQ starts actual transmission. > Is there an option for this? From my testing, ZMQ_SNDTIMEO does not seem to > do this, and none of the other options I've read about seem to be applicable. > As it stands, I'm using pyzmq's MessageTracker interface, along with a > hackish thread interface, to queue all messages I plan on sending until the > currently sent message is actually transmitted, before starting on the next > message. This is suboptimal, and I'd like to do something better. > > Note that any solution MUST work with XPUB/XSUB as they operate over UDP (via > PGM). I'm operating on a lossy wireless network, and cannot tolerate how > long TCP takes to timeout a connection, or how long it takes to figure out a > connection is back up. > > Thanks, > Cem Karan > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
