In the router-dealer example for NetMQ, we see that clients can set their own identity. This can be useful for logging purposes. However, what if I only control code for the server (router) and not the code for the clients (dealers)? What if some clients don't bother to set the identity in a way that is meaningful for my server? How do I include the physical address in my logs, when the client doesn't specifically give it to me in the message or identity?
If you only know the answer based on some other implementation of ZeroMQ, I will be interested to hear it, but ultimately I want something that can be accomplished in NetMQ.
How to identify the physical address of incoming connections in NetMQ ?
Well, there seems to be no magic ready to do this:
While API-s in pre-v4.2+ state have already enabled some help for settings identities, that make some chances for application-level code to become aware of some of the messages' "origin" ( ref. documentation for all lower level details and limitations ) not all Scalable Formal Communication Pattern Archetype can use this.
Next, the whole circus also depends on a free-will to include ( and/or not to include ) such a "helper" piece of information into the processing of the flow of messages. So, the concept of identity-frame(s) is sort of a weak-principle and your side application-level code can only hope and pray to receive some, but principally has no warranty for receiving any such, as zero remote enforcement policy seems available for this under API v4.2 in 2018/Q2.
How do I include the physical address in my logs, when the client doesn't specifically give it to me in the message or identity?
[ Legal aspect ] with a belief of having exclusively legally fair reasons to do that,
the elementary respect
to Human Right to provide one's IDENTITY or not
is to be applied here, isn't it?
Besides the GDPR and other privacy protecting legal framework, this part is way harder even if assessed as just a technical challenge, 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 any / all of the above required mappings of soft-knowledge ( the actually sent or not sent identity-strings ) with the actual transport-class decoder to sniff with.
Next, not all connections are easily sniff-able, are they?
ultimately I want something that can be accomplished in NetMQ.
Given your statement, that your domain of control does not contain the remote ( client-side ) agents in a general distributed-system there is not much about to do, except an enormous MITM/intel spying-grade efforts were motivated to develop an all transport-classes covering privacy penetrating screening over the already complex topologies of possible many-to-many connection meshes, yet with an added level of robustness against any "faked" identities and many other problems to make such efforts functional, universal, unobtrusive and yet robust enough, so as to make 'em meaningful
(
if not aware yet, kindly 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)
)
