Can you get the identity/address of the publisher and subscriber in ZeroMQ?

Question

I have been reading the docs and I can't seem to find if there's any information regarding my query.

I just need the IP addresses of the publisher and the subscriber to keep track and so I can display them as an output of my program.

Assuming I have a network wherein my publisher and subscribers are connected, is it possible for publishers to determine every subscribers' IP address and vice-versa?

So I can have something like this:

Publisher of topic "foo":
 192.168.1.1
Subscribers of topic "foo":
 192.168.1.2
 192.168.1.3

Answer 1

^{[+1] for your inspirative motto: " The day we die is the day we stop learning "}

can have something like this: ?

Well,
Yes and No :

While API v4.2+ enables some help for settings that make PUB-side application code aware of the actually setup/cleanup of individual SUB-side initiated subscriptions ( using an XSUB Scalable Formal Communication Pattern Archetype instead of SUB ), yet the PUB/XPUB-side has to change it's behaviour, so as to process such re-arranged flow of messages.

---

Identity/Addresses? ^{( a Human Right for Privacy lost forever ? ... inferior danger )}

This part is harder, there are many transport-classes available, as of 2018-Q2 at least:
these : { inproc:// | ipc:// | tcp:// | pgm:// | epgm:// | vmci:// }, so either side would hardly be equipped with some magic-sniffer to detect all above required mappings of soft-knowledge ( the actually valid topic-filter mask ) with the actual transport-class decoder to sniff with. Next, not all connections are easily sniff-able, are they?

---

Anyway, doable :

In case your application needs to work this way, one may extend the ZeroMQ tools and either equip the ZMTP/RFC'd-protocol decoders, so as to provide your application-side programmes with this low-level piece of information, or the top-level application programmes can self-advertise theirs respective identities

(
yet, notice -- as depicted in [ ZeroMQ hierarchy in less than a five seconds ] Section -- one ZeroMQ-Context()-instance may have many zmq.Socket()-instances, each of which may have many-AccessPoint-s, each of which may use a different transport-class and may get .bind()/.connect()-ed to many different remote peer AccessPoint-s, so indeed a wild mess of topology morphologies are out there :o)
)