david starkweather wrote: > Thanks, Pieter for your work in detecting this error. > > 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. > > So you want the messages to go through the worker thread and then onto elsewhere for further processing? That's why Pieter suggests the pipeline model.
As an aside, it is possible to have the SUB sockets do the bind and the PUB sockets do the connect, which would have negated the need for having N "publish%d" endpoints where N = number thread, if you are continuing with that model. ie the worker threads do connect and the forwarder SUB socket does the bind. There was a bit of discussion on IRC about this the other day, which if I recall concludes it is push/pull. Jon _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
