Hi Justin: Thanks for taking the time for a very helpful reply! Please see my comments below.
Best regards, Bill > On Jun 2, 2018, at 3:33 PM, Justin Karneges <[email protected]> wrote: > > Hi Bill, > > I'm not sure if the actual handshakes would always finish in order, but you > might have some success with the SUB socket handshake finishing by the time > the broker needs to send on it. You basically have one extra trip of latency > in the client->broker direction while the client sends its first message for > the SUB handshake to catch up. > > E.g.: > > 1) client starts SUB and PUB handshakes > 2) PUB handshake finishes > 3) client sends message over PUB socket > 4) SUB handshake finishes > 5) broker receives message from step 3 and sends it back out I *think* I get what you’re saying — if so, I’m not sure it works for my use case. I don’t care that the subscriber gets ALL the messages, I only care that the subscriber gets ANY message that ANY other subscriber gets. > > That all said, I wouldn't rely on it, unless you can tolerate it sometimes > not working. Better to use ZMQ_XPUB_WELCOME_MSG to be sure. That’s a very interesting idea! I had noticed the ZMQ_XPUB_WELCOME_MSG but hadn’t paid it much attention — based on your suggestion it merits a closer look, and may be just the ticket for my use case. The way I understand things, when the client SUB socket receives the welcome msg, it knows that it is connected to a broker, so it should receive back any message that it publishes subsequent to receiving the welcome msg. That should be a lot simpler and cleaner than monitoring socket events using zmq_socket_monitor, especially since pulling events off the socket monitor should probably be done in a dedicated thread. The documentation on ZMQ_XPUB_WELCOME_MSG is a bit sparse (!), but for any others who are interested there is a nice writeup at: https://somdoron.com/2015/09/reliable-pubsub/ I’ll give that a try, and will let you know what I find out. > > Keep in mind that PUB/SUB is unreliable by design, so if you absolutely must > receive all messages then you'll need a fallback mechanism. And if you have a > fallback then you may not need the welcome message after all. > > In our app, we use SUB for best effort instant receiving, and REQ as a > fallback "poll". On initialization, the client starts the SUB, waits 1 > second, then polls with REQ. Hmmm. I dislike relying on an arbitrary sleep — I much prefer to know for sure what state the app is in. Having said that, a lot of the 0MQ unit tests seem to use that approach (" msleep (SETTLE_TIME);”). As for using the REQ socket to “prime the pump”, so to speak — isn’t that pretty much relying on the same behavior that I’m asking about? You’re assuming that if you get a reply on the REQ then the SUB must be connected. That may be true in practice, but I don’t know that that behavior is documented anywhere. > > Justin > > On Sat, Jun 2, 2018, at 11:49 AM, Bill Torpey wrote: >> Hello all: >> >> I have a question that I’m hoping someone with more experience than I >> can help answer, which is whether the order of connections and/or >> handshakes can be relied on in certain cases. >> >> I understand that generally connect and handshake happen asynchronously, >> and that the only way to be certain is to use zmq_socket_monitor and >> capture the individual events. >> >> However, I have a specific use case in mind: >> >> - process A is connecting to a zmq_proxy at a well-known address >> (essentially the "Weather Update" proxy from the Guide): >> - it first connects a ZMQ_SUB socket (to the proxy’s ZMQ_XPUB socket) >> - it next connects a ZMQ_PUB socket (to the proxy’s ZMQ_XSUB socket) >> >> It turns out that it would be very handy to be able to rely on the SUB >> socket completing its handshake BEFORE the PUB socket's handshake >> completes. >> >> If that is the case, then I believe that process A can rely on the SUB >> socket getting any message it publishes on the PUB socket. More >> importantly, it can rely on the fact that no other processes connected >> to the proxy will see a message from process A's PUB socket that process >> A's SUB socket does not see itself. >> >> So I guess the question boils down to: is there any possibility that the >> PUB socket's handshake will complete before the SUB socket's? >> >> Given that the connect calls are both being done from the same process >> to the same (other) process, it seems that this might be a reliable >> pattern, but I don’t know the code well enough to be certain. >> >> Or am I stuck with having to use zmq_socket_monitor to capture the >> events and provide synchronization around them? (Which I would prefer >> to avoid if possible -- that can be messy and error-prone). >> >> Any tips, suggestions much appreciated! >> >> Regards, >> >> Bill Torpey >> _______________________________________________ >> 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
