On Sun, Jun 3, 2018, at 7:49 AM, Bill Torpey wrote: > > On Jun 2, 2018, at 3:33 PM, Justin Karneges <[email protected]> wrote: > > 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.
The problem with subscription acknowledgments is they don't really work past the first hop (i.e. the broker). So you can know for sure that the broker considers your connection subscribed to some topic, but you can't know that an upstream broker or publisher considers the broker to be subscribed to that topic. In other words it's not end-to-end. And this isn't practical to solve either, when you consider multiple publishers or late-arriving publishers. I agree that an arbitrary sleep isn't very satisfying. Weirdly it's about the only pure thing that can be done though, aside from doing nothing. Think of it as a multi-hop propagation timeout. Our client doesn't send a REQ to assure the SUB is connected, but rather it sends a REQ after enough time has passed for us to believe that the SUB is probably already connected, to pick up anything that may have been missed before then. Justin _______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
