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 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. 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. 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 > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
