Hi Stephen, 2017-03-31 15:49 GMT+02:00 Stephen Riesenberg <[email protected]>: > Good deal. Also, a note on the number of threads issue, instead of > monitoring sockets, everything is in your control inside this multithreaded > component you're building, so the proxy that funnels messages should have a > way to know how many threads are running. You'd want the same setup method > that fires up the threads in the first place to pass that number to the > publisher thread or some side channel that keeps state. And if threads come > and go for some reason, you'd just need to keep track of when they start up > and exit to update a counter. This is assuming that number is necessary as > part of your design. If not, one less thing to worry about, right?
absolutely; moreover for now I'm assert()ing the connection of each thread to the frontend socket of the proxy. So that the number of threads I create is always matching the number of threads sending data to the proxy, otherwise the program would abort. I don't know if INPROC sockets can fail to connect for some reason or not.. apparently no so far :) thanks, Francesco > > On Fri, Mar 31, 2017 at 5:55 AM Francesco <[email protected]> > wrote: >> >> Hi Stephen, >> indeed I tried and the setup of that networking schema was faster than >> I expected... and more importantly it just worked!!! :) >> The only "limitation" I discovered is that you cannot do >> zmq_monitor_socket() on the INPROC side of the PROXY. >> So that I don't have a way to ask to the proxy how many threads have >> connected to its frontend socket. However's that not a big issue... >> and more importantly I can still monitor the backend socket which is >> the one exposed via TCP to the rest of the world. >> >> >> 2017-03-30 21:56 GMT+02:00 Stephen Riesenberg >> <[email protected]>: >> >... >> > Though I'm not sure what you mean by "I would like to have all these >> > thread >> > appear as a unique endpoint to the outside world." Would this be through >> > a >> > topic name or some other piece of data? This also seems fine, but wasn't >> > sure if that's what you meant. >> >> Well, I just meant that other components must be able to subscribe to >> the events produced by all threads by doing subscribe to a single ZMQ >> endpoint (i.e., the endpoint of the backend socket of the proxy)... >> that may seem obvious but I just wanted to specify that. >> >> Thanks for your reply! >> >> Francesco >> >> >> >> >> >> > >> > On Tue, Mar 28, 2017 at 7:39 AM Francesco <[email protected]> >> > wrote: >> >> >> >> Hi all, >> >> >> >> I'm trying to work out a problem in a multithreaded application and I >> >> would like to use ZMQ to solve it. >> >> >> >> In particular I have a process with several threads that are >> >> generating messages; each one has its own PUB socket. >> >> I would like to have all these thread appear as a unique endpoint to >> >> the outside world. >> >> >> >> For this reason I'm thinking of changing the PUB socket of each thread >> >> to use the INPROC transport and then create a ZMQ proxy exposing an >> >> XSUB frontend socket with INPROC transport and an XPUB backend socket >> >> with TCP transport, for the external world. >> >> >> >> Do you think such kind of scenario would work? >> >> >> >> Thanks! >> >> Francesco >> >> _______________________________________________ >> >> zeromq-dev mailing list >> >> [email protected] >> >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >> > >> > _______________________________________________ >> > zeromq-dev mailing list >> > [email protected] >> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
