Hi Doron, thanks for your kind help! So with an XPUB/SUB connection over an inproc transport no hand-made syncronization is needed? Have I understand correctly?
Giacomo On Fri, Jun 28, 2013 at 9:19 AM, Doron Somech <[email protected]> wrote: > Hi Giacomo, > > The poller is actually a copy of the zloop from czmq, actually I'm not big > fun of the event pattern but I want to make it as close as possible to > CLRZMQ. > > 1. The start method is blocking, you should call if from a dedicated > thread. > 2. Stop(false) just signal the dedicated thread to stop but don't actually > wait the thread is stopped, this is good when you want to close the poller > but continue doing something else with your code, but if for example you > closing the application and want to wait until the poller is completely > stopped call it with true. > 3. Actually you cannot call Stop(true) from the dedicated thread, you can > call Stop(false) from the dedicated thread, but I don't have to implement > this kind of socket, you can just call Stop > 4. Just call the stop method > > Regarding the bonus question, you have to do some synchronization magic to > make it work, for the example let's call the socket which bind server and > the sockets which connect clients. So when the server binds no client is > connected yet (with inproc you have to bind before you can connect), now if > you will start send messages now the client will miss them. > > After the client connected the client should send a signal message to the > server, after the server bind we wait for message from client, after this > the server can start publish messages. > > If we are talking about pub-sub pattern you should have a sub socket as > the client, xpub socket as server, now the client immediately send > subscribe message and the server wait for the first message... > > Doron > > > On Fri, Jun 28, 2013 at 3:23 AM, Giacomo Tesio <[email protected]> wrote: > >> Hi, I'm having an hard time understanding the NetMQ.Poller usage (here: >> https://github.com/zeromq/netmq/blob/master/src/NetMQ/Poller.cs). >> >> The fact is, it doesn't expose any Poll method. >> >> I guess that this is done in the aim of OOP desing. >> >> But I'm not sure about its correct usage. >> >> My insight is that after adding the sockets to the Poller, I should >> simply observe the sockets' events ReceiveReady and SendReady, but if so: >> >> >> 1. does the Start method block? If not, this should mean that I don't >> have to use it in a dedicated thread, right? >> 2. what are the pro/cons of Stop(false)? >> 3. one of the socket I added to the poller is a "control" one that >> send a "STOP" command when required. In the event handler can I stop the >> poller and remove the sockets? >> 4. what should I do to cleanup things (before context disposition)? >> >> Moreover I'd like to know if the socket events will ever be fired from >> sockets that aren't in a Poller, or not. >> >> >> Finally a bonus question (be patient, I'm a newbie here): I've read that >> with ZeroMQ I can loose a few messages at connection startup (even if I >> start the receiver before the sender): does this apply to inproc sockets >> too? >> >> >> Thanks a lot. >> >> >> Giacomo >> >> _______________________________________________ >> 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 > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
