CODEWITHSUNDEEP
zeromqpublish-subscribe
bgarcial
bgarcial

Reputation: 3193

How to get data a ZMQ_PUB service?

Can I publisher service receive data from an external source and send them to the subscribers?

In the wuserver.cpp example, the data are generated from the same script.

Can I write a ZMQ_PUBLISHER entity, which receives data from external data source / application ... ?

enter image description here

In this affirmation:

There is one more important thing to know about PUB-SUB sockets: you do not know precisely when a subscriber starts to get messages. Even if you start a subscriber, wait a while, and then start the publisher, the subscriber will always miss the first messages that the publisher sends. This is because as the subscriber connects to the publisher (something that takes a small but non-zero time), the publisher may already be sending messages out.

Does this mean, that a PUB-SUB ZeroMQ pattern is performed to a best effort - UDP style?

Upvotes: 1

Views: 103

Answers (1)

user3666197
user3666197

Reputation: 1

Q1:
Can I write a ZMQ_PUBLISHER entity, which receives data from external data source/application?

A1: Oh sure, this is why ZeroMQ is so helping us in designing smart . Just imagine the PUB-side process to also have other { .bind() | .connect() }-calls, so as to establish such other links to data-feeder(s), and you are done to operate the wished to have scheme. In this gives you a new freedom to smart integrate heterogeneous systems to talk to each other in a very efficient way.

Q2:
Does this mean, that a PUB-SUB ZeroMQ pattern is performed to a best effort - UDP style?

A2: No, it has another meaning. The newly declared subscriber entities at some uncertain moment start to negotiate their respective subscription-topic filtering and such a ( distributed ) process takes some a-priori unknown time. Unless until the new / changed topic-filter policy was established, there is nothing to go into the SUB-side exgress interface to meet a .recv()-call, so no one can indeed tell, when that will get happened, can he?

On a higher level, there is another well known dichotomy of ZeroMQ -- Zero-Warranty Principle -- expect to either get delivered a complete message or none at all, which prevents the framework users from a need to handle any kind of damaged / inconsistent message-payloads. Either OK, or None. That's a great warranty. The more for .

Upvotes: 1

Related Questions