在router-dealer example for NetMQ中，我们看到客户可以设置自己的身份。这对于日志记录非常有用。但是，如果我只控制服务器（路由器）的代码而不是客户端（代理商）的代码呢？如果有些客户不愿意以对我的服务器有意义的方式设置身份，该怎么办？当客户没有在邮件或身份中明确地将其提供给我时，如何在我的日志中包含物理地址？
如果您只根据ZeroMQ的其他实现知道答案，我将有兴趣听到它，但最终我想要一些可以在NetMQ中完成的事情。
答案 0 :(得分：2)
如何在NetMQ中识别传入连接的物理地址？
好吧，似乎没有任何魔法可以做到这一点：
虽然pre-v4.2 +状态的API已经为设置标识启用了一些帮助，但这使得应用程序级代码有机会了解某些消息的“来源”（参考文档为所有较低级别的细节和限制）并非所有可扩展的形式通信模式原型都可以使用它。
接下来，整个马戏团还依赖于自由意志将这样的“帮助”信息包括（和/或不包括）到消息流的处理中。因此，身份框架的概念是一种弱原则，你的应用程序级代码只能希望并祈祷接收一些，但主要是没有保证接收任何此类，因为零远程执行政策似乎可在2018 / Q2的API v4.2下使用。
如果客户端没有在邮件或标识中专门提供给我，我如何在我的日志中包含实际地址？
[法律方面] 认为完全有法律上公平的理由这样做，
基本尊重人权提供一个人的身份将在这里应用，不是吗？
除了GDPR和其他隐私保护法律框架之外，即使被评估为技术挑战，这一部分也更难，有许多运输类别，至少在2018年至Q2期间：
这些： { inproc:// | ipc:// | tcp:// | pgm:// | epgm:// | vmci:// } ，因此任何一方都很难配备一些魔法嗅探器来检测任何/所有上述所需的软知识映射（实际发送或未发送的身份 - 字符串）与实际的传输类解码器一起嗅探。
接下来，并非所有连接都能轻易嗅探，是吗？
最终我想要一些可以在NetMQ中完成的东西。
鉴于您的声明，您的控制域不包含一般distributed-system中的远程（客户端）代理，除了巨大的MITM /英特尔间谍等级努力外，没有太多的事情要做。有动力开发一个涵盖隐私渗透筛选的所有传输类，覆盖可能的多对多连接网格的已经很复杂的拓扑，但是对任何“伪造”身份和许多其他问题的附加级别的强大性使这些努力起作用，普遍的，不引人注目的，但足够强大，以使他们有意义
（
如果还不知道的话，请注意 - 如 [ZeroMQ hierarchy in less than a five seconds] 部分所述 - 一个 ZeroMQ - Context() - 实例可能许多 zmq.Socket() - 个实例，每个实例可能有多个 -AccessPoint-s，每个实例都可能使用不同的传输类可能会.bind()/.connect() - 来自许多不同的远程对等AccessPoint-s，所以拓扑形态确实是一团糟 ：o）< /强>
）