Hi Goswin / Brandon, On Mon, Feb 3, 2014 at 8:01 AM, Goswin von Brederlow <[email protected]>wrote:
> Don't create threads like that. Create a thread pool of handlers that > keep their sockets connected and dispatch events to them. That solves > your problem and also cuts down on the (rather long) time to start a > thread per event. > In that approach, how would you suggest choosing the number of listener threads to create? Why use PUB/SUB then? Why not PUSH/PULL or something else? > Alright, I have redesigned it to use PUSH/PULL connected to a PUB, which works okay. On Mon, Feb 3, 2014 at 8:42 AM, Brandon Carpenter < [email protected]> wrote: > In that case, I bind two sockets: PULL for incoming messages and PUB for > outgoing messages. Then the two are plugged together using a proxy. > Publishers connect to the PULL socket using a PUSH socket; messages get > passed on to the PUB socket; and subscribers, who connect to the PUB > socket using a SUB socket, receive messages matching their > subscriptions. Subscribers still suffer from the slow joiner issue, but > published messages will not be dropped from the perspective of the PUB > socket.The above produces a single message bus which allows multiple, > concurrent publishers and subscribers. I have tried this, and it works alright. It just means that instead of using the zmq::proxy device, I needed to write a short bit of code to do the forwarding from PULL to PUB. Thanks to both of you for your replies. Cosmo
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
