在NetMQ 的路由器经销商示例中，我们看到客户端可以设置自己的身份。这对于记录目的很有用。但是，如果我只控制服务器（路由器）的代码而不是客户端（经销商）的代码，该怎么办？如果某些客户端不费心以对我的服务器有意义的方式设置身份怎么办？当客户没有在消息或身份中明确提供给我时，我如何在我的日志中包含物理地址？
如果你只知道基于 ZeroMQ 的其他一些实现的答案，我会很想听听它，但最终我想要一些可以在 NetMQ 中完成的东西。
问问题
715 次
1 回答
2
如何识别 NetMQ 中传入连接的物理地址？
好吧，似乎没有什么魔法可以做到这一点：
虽然处于 v4.2+ 之前状态的 API 已经启用了一些设置身份的帮助，但这使得应用程序级代码有机会了解一些消息的“来源”（参考所有较低级别的文档细节和限制）并非所有可扩展的正式通信模式原型都可以使用它。
接下来，整个马戏团还依赖于将这种“帮助”信息包含（和/或不包含）信息流处理的自由意志。因此，身份框架的概念是一种弱原则，您的应用程序级代码只能希望并祈祷接收一些，但原则上不能保证接收任何此类，因为零远程执行策略似乎可在 2018/Q2 的 API v4.2 下使用。
当客户没有在消息或身份中明确提供给我时，我如何在我的日志中包含物理地址？
[ 法律方面 ]相信有完全合法的公平理由这样做，这里适用于提供或不提供个人身份
的基本
人权，不是吗？
除了 GDPR 和其他隐私保护法律框架之外，即使仅将其评估为技术挑战，这部分也更加困难，至少在 2018 年第二季度有许多可用的传输等级：
这些 : { inproc:// | ipc:// | tcp:// | pgm:// | epgm:// | vmci:// }，所以任何一方都很难配备使用一些魔术嗅探器来检测任何/所有上述所需的软知识映射（实际发送或未发送的身份字符串）与实际传输类解码器进行嗅探。
其次，并不是所有的连接都容易被嗅探，是吗？
最终我想要一些可以在 NetMQ 中完成的东西。
鉴于您的陈述，您的控制域不包含一般分布式系统中的远程（客户端）代理，没有太多要做的事情，除了巨大的 MITM/intel 间谍级别的努力被激励开发一个全部传输类涵盖隐私穿透筛选可能的多对多连接网格的已经复杂的拓扑结构，但对任何“伪造”身份和许多其他问题具有更高的鲁棒性，以使这些努力具有功能性、通用性、不显眼且足够健壮，以使它们有意义
（
如果还没有意识到，请注意——如[ ZeroMQ 层次结构在不到五秒的时间内]部分所述——一个ZeroMQ-Context()-instance 可能有许多 zmq.Socket()-instances，每个实例可能有许多-AccessPoint-s，每个实例可能使用不同的传输类，并且可能被.bind()/.connect()-ed 到许多不同的远程对等 AccessPoint-s，因此确实是一团乱麻的拓扑形态在那里:o)
)
于 2018-05-10T15:49:03.137 回答