On Sat, Sep 11, 2010 at 9:17 PM, david starkweather <[email protected]> wrote:
> Actually, the intention here is not to send messages back to the client > using the pub/sub model through main. (That would be a little absurd > anyways.) It is to relay messages recieved from the client to servers > on the back end for further processing. I dont think push/pull would > work, as all these backend servers need to recieve all messages, not > just the next available server. (This is useful for lookup services, > when you dont know in which server to look.) > > I resolved this by creating separate channels for each publisher skt in > each worker thread named "inproc://publish%d", where the the %d is the > worker thread number. Then the subscriber skt in the forwarder can just > connect to each inproc://publish%d. Your explanation, the sample code, and that last paragraph don't seem to fit together. You have 1 forwarder. It subscribes to 10 'publisher sockets'. That is just a pipeline sink done wrongly. Correct way is: forwarder opens a PULL socket, publishers all PUSH into that. Your design is made awkward by the idea that you want a forwarder device, which again is an implementation, not an intention. A forwarder is a pubsub device, thus you try to make the sink work with a SUB socket instead of a PULL. You can of course write your own devices that mix patterns. Read from a PULL, write to a PUB. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
