I have started to implement this feature, and thought, what would be the desired behavior in case of multi-part messages? Are multi-part messages to be considered as one, or to be forbidden as altogether on a "conflate" socket as a not-really-interesting-usecase?
Thanks On Mon, Jun 10, 2013 at 10:43 AM, Michael Haberler <[email protected]>wrote: > Daniel, > > Am 07.06.2013 um 11:53 schrieb Daniel Krikun <[email protected]>: > > Occasionally, the clients might be faster and few messages get > > themselves queued on the server queue. However, only the most recent > > message is of interest as the server does not renders the objects as > > they were a couple of cycles before. > > > > To solve the problem, I have extended the ZMQ_ROUTER socket (via > > subclassing) so that it has a background thread that empties the > > socket message queue and stores the last message. The message is > > stored in a double-buffer (one for each client, this is why I need a > > router socket type). Then, when the server calls recv() on my extended > > socket, it gets one of the stored messages (if there are any). > > > > I ask myself whether some similar functionality should be put inside > > zeromq (say, under ZMQ_FLAT_PULL socket type), left as is in a "user > > space" or maybe I should use UDP instead? > > I have a perfect use case for that kind of pattern > > In fact I think it covers many scenarios with state updates where only the > last update counts > > I'd encourage adding this to the pattern arsenal > > Michael > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Daniel Krikun
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
