对于连接到单个服务器的多个客户端，我应该使用哪种双向 ZeroMQ 模式? [英] Which bi-directional ZeroMQ pattern should I use for multiple clients connecting to a single server?

问题描述

我有多个(1000 多个)客户端连接到单个服务器并发送一些日志数据.

服务器分析数据并在必要时做出响应.

PUB/SUB 是一个方向(监控示例).
REQ/REP 无法识别对等点并专门回复对等点(更多用于 ACK 等).

我需要注册这些客户，识别他们并在分析他们的日志后能够做出回应.

使用套接字，我有客户端套接字，在接受之后我可以使用该套接字进行响应，并且客户端可以在我连接到的同一个套接字上接收.

我在使用 0mq 的第一周没有在 ZeroMQ 中找到这样的东西.

ROUTER 套接字可以打印对等方的 id，但如何使用该 id 回复该对等方?

有没有更好的方法来处理这个问题?

解决方案

没有一个——意味着没有一个！
_{...而是在更高的抽象层次上使用更多的逻辑.}

为什么?

因为马斯洛的锤子:

<块引用>

_{当你拥有的唯一工具(...想要使用)
是一把锤子，
每个问题都开始类似钉子."}

ZeroMQ 是一套可爱的微调构建块，它们普遍配备(根据它们在最终实现组合中将使用什么传输类的中立性)，可用于在一个人的高层中重新使用它们分布式系统设计逻辑原型制作.

因此期望 PUB/SUB、PAIR/PAIR 或任何其他正式的可扩展通信原型原始人会正确匹配系统要求，而不是缺少核心好处，我们凡人都从真正的马丁 SUSTRIK &Pieter HINTJENS 的智能消息传递团队.

提案

可以想象以下模型概念:

使用:

• 服务器 .bind()-s 并处理一个所有客户端都知道的 SUB 端口，该端口已订阅足以接收所有日志"-从所有 id#-hashed 客户端处理的数据(并忽略任何其他数据输入——即使是旧版本的 ZeroMQ 也为 PUB 实现了一个 SUB 端过滤>/SUB 原型将允许在服务器节点上可接受的性能负载下进行此操作).(当然，有人可能会反对，可能还有其他要求，以便更好地处理或完全避免 DDOS 类型的攻击等，但让我们在这个模型中保持微不足道)

• client .connect()-s 它是 PUB 角色，按需，并将自身介绍给监听 SUB 的服务器code>-role + 移动日志数据，然后挂起"或保持线路静默(在决定这组架构问题之前，应该对扩展和性能问题进行现场测试).

• 服务器可能决定需要与 id# 散列的特定客户端进行一些临时对话，但不希望另一个 .bind() 与静态端口# 相关联，因此服务器使用另一个 .connect()-ed 角色，一个 PUB，发送特别短的，因此具有可接受的占用空间系统范围内关联的开销、信令、电报到 id#-hashed 客户端(类似于启动端口敲击安全行为的软件方式)，告诉它从哪里 .connect() 到服务器并解决额外的任务等(客户端重新发现和注册和维护是可行的，因此全局方案满足规定的要求，不暴露任何其他静态暴露给外部入侵者的端口)

• client 有另一个 .bind()-ready SUB 角色，订阅监听服务器 id#-hashed 信令公告 + 设置指令，什么是合适的客户端应该 .connect()-against-.bind() (而反向 .bind()/.connect() 方案只需要一点扩展的客户端重新发现维护)并且根据服务器端信号，这种事后处理可能发生在单独的(甚至是一次性使用的(完全一次性的))广告上-临时通信基础设施(可以是 XREQ/XREP 或其他双边正式通信模式原型，或者是几种这样的、智能编排的更智能的混合)，它不会不需要服务器具有静态公开的端口，但足以进行临时服务器/客户端请求处理.

对草图模型不满意? ^{... 毫无疑问，这里太原始了}

最好的下一步:

之后 (cit.:)我的第一周 0mq" 最好的下一步可能是恕我直言得到一点更全局的视图，对于尝试使用 ZeroMQ 进行编码的前几件事，这听起来可能很复杂，但是如果您
和
图 62 HA 克隆服务器对，以获得可能的高可用性方法，然后回到根源，元素和细节.

<小时>

无论如何，享受 ZeroMQ
和
在此处阅读其他与 ZeroMQ 相关的 Q/As 可能会很有趣 >>>

I have multiple ( 1000s ) of clients connecting to a single server and sending some log data.

The server analyses the data and responds, if necessary.

PUB/SUB is one directional (monitor example ).
REQ/REP cannot identify the peer and reply specifically to a peer ( it is more for ACK and such only ).

I need to register these clients, identify them and be able to respond after analysis of their logs.

With sockets, I have the client sockets, after accept and I can respond using that socket and the clients can receive on the same socket that I connected to.

I am not finding such a thing in ZeroMQ in my first week of 0mq.

ROUTER socket can print peer's id, but how do I reply to that peer using that id ?

Is there a better way to deal with this?

解决方案

None of them -- meaning not a single one !
_{. . . rather use more of 'em with some logic on a higher level of abstraction.}

Why ?

Because of Maslow's hammer:

_{"When the only tool you have ( ... want to use )
is a hammer,
every problem begins to resemble a nail."}

ZeroMQ is a lovely set of fine-tuned building blocks universally equipped ( as per their neutrality as to what transport-class will be used in the final implementation mix ) that is available for re-using 'em inside one's High-Level Logic of the distributed system design & prototyping.

Thus expecting that the very PUB/SUB, PAIR/PAIR or any other Formal Scaleable Communication Archetype Primitive will right match the system requirements is rather missing the core of the benefits, we mortals have received from the genuine Martin SUSTRIK & Pieter HINTJENS' smart messaging Team.

Proposal

One can imagine a following mock-up concept:

using:

• Server .bind()-s and handles one SUB port, known to all clients, that was subscribed well-enough for receiving all "log"-data to process from all id#-hashed clients ( and ignoring any other ingress of data -- even the older versions of the ZeroMQ implemented a SUB-side filtering for the PUB/SUB archetype would allow for this at an acceptable performance load on the server node ). ( Sure, one may object, there may be also other requirements, so as to better handle or avoid completely DDOS-sort of atacks et al, but let's stay trivial in this mock-up )

• client .connect()-s it's PUB role, on-demand, and introduces itself to the Server listening on the SUB-role + moves log-data and either "hangs" or keeps the line silent (a scaling & performance issues ougth be field-tested prior to deciding this group of architecture issues ).

• server may decide to require some ad-hoc conversation with an id#-hashed specific client, but does not want to have an a-priori port publicly exposed by another .bind() associated with a static port#, thus server uses another .connect()-ed role, a PUB, sending ad-hoc a very short, thus having an acceptable footprint of the system-wide associated overhead, signalling, telegramme to the id#-hashed client ( alike a software manner to initiate a port-knocking security behaviour ), telling it where to .connect() to the server and solve the additional tasking et al ( client re-discovery and registration and maintenance is doable this way, so the global scheme meets the stated requirement, not to expose any other port statically exposed to external intruder )

• client has another .bind()-ready SUB role, subscribed to listening to server id#-hashed signalling announcement + setup instructions, what an appropriate client ought .connect()-against-.bind() ( while a reversed .bind()/.connect() scheme requires just a bit extended client re-discovery maintenance ) and upon a server-side signal, such ex-post processing may take place on a separate ( even a one-time used ( a fully disposable ) ) ad-hoc communication infrastructure ( be it an XREQ/XREP or other bilateral Formal Communication Pattern Archetype or some kind of a smarter-mix of several such, intelligently orchestrated ones ), which does not require server to have a statically exposed port but suffice for an ad-hoc server/client request processing.

Not happy with the sketched mock-up? ^{... no doubts, it's so primitive here}

The Best Next Step:

After (cit.:) "my first week of 0mq" the best next step one may do is IMHO to get a bit more global view, which may sound complicated for the first few things one tries to code with ZeroMQ, but if you at least jump to the page 265 of the [Code Connected, Volume 1] [available asPdf >>> http://hintjens.wdfiles.com/local--files/main%3Afiles/cc1pe.pdf ], if it were not the case of reading step-by-step thereto.

The fastest-ever learning-curve would be to have first an un-exposed view on the
Fig.60
Republishing Updates
and
Fig.62 HA Clone Server pair for a possible High-availability approach and then go back to the roots, elements and details.

---

Anyway, enjoy the powers of ZeroMQ
and
might find interesting to read other ZeroMQ-related Q/A-s here >>>

这篇关于对于连接到单个服务器的多个客户端，我应该使用哪种双向 ZeroMQ 模式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！