Your backend should be a router (or SERVER socket type) as well (like in the majordomo), worker can be a dealer. You can now manage a dictionary of routing ids from frontend to backend.
On Sat, May 28, 2016 at 2:46 AM, Douglas Petican <[email protected]> wrote: > First off I'm really impressed with zeromq. I've been working with it > since yesterday and already I can amazing stuff. Thx for making it. > > I think I'm trying to do something similar to a majordomo pattern, but I > started with the extended request/reply pattern (router/dealer). The added > thing for my app is I dynamically spawn the workers as new client connects > to the broker. The point is then to enforce the 1:1 relationship between > client and worker from then on. This works, but the broker gets confused > after the second client connects. No messages are crossed, but it still > tries to do fair queueing it seems. The code and output is long and I've > already created a stackexchange question for the problem: > http://stackoverflow.com/questions/37490339/zeromq-router-dealer-broker > > The reason for the 1:1 is that the workers manage serial ports. The > comport the client wants to connect to will be in the message. On the > client side a list of available ports will be maintained. I'm hoping its > something simple and I won't have to go to a full majordomo patter. Thanks > :) > > -- > <-Douglas Petican-> > > > _______________________________________________ > 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
