On Wed, Feb 16, 2011 at 6:14 PM, Ian Barber <[email protected]> wrote:
> Perhaps this is somthing that could be solved with a new type of device. > Like, we know the solution is some signalling that a subscriber is > connected... > > void *ss = zmq_syncsub(&pub, &pull, 1); > zmq_send(ss, zmsg); > > This kind of metasocket seems like a reusable style, much as the current in, > out device format is. It's kind of the API design we used for the reliable RPC layer in ZFL... internal device threads. It definitely works. After thinking about it, synchronizing the two ends isn't really enough. What if the subscriber dies and restarts, how do you recover? If you don't need to, then there's no need to synchronize at the start of data either. A previous thread on this topic brought us to the notion that we need a distributed hash table approach so subscribers can join at any time and get a guaranteed state. It's quite doable to make IMO, I'm thinking of it for Ch4 of the Guide. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
