python zmq 多客户端到多服务器发现消息模式
python zmq many client to many server discovery message patterns
在这个问题上苦苦思索了一段时间，终于向高手求助了。
语言：python
problem/setup:
我有很多客户，client[n], client[n] ..等
我有很多服务器，server[n], server[n] .. etc
每个服务器 可以插入 5 个外部 ws 连接。在任何时候我可能需要打开 [x] ws 连接；也许 2，也许 32，我需要的总 ws 连接，因此需要的服务器，是动态的...
每个客户端可能连接来自服务器[1]的1个ws连接，来自服务器[2]的1个ws连接......等
我想象中的流程如何运作
- 已加载新客户端[1]，需要 2 个 ws 提要
- 新客户端[1]向所有服务器广播[xpub/xsub ?] 消息说，'hey, I need these 2 ws connections, who has them?'
- Server[1] 与 ws 连接回复 client[1]（且仅该 client）- 'I got what youre looking for, talk to me'
- client[1] 与 server[1] 进行 req/reply 通信，以便 client[1] 可以利用 server[1] 的 ws 连接对其进行查询，例如，'hey, server[1] with access to ws[1], can you request [x]' .. 服务器[1] 回复客户端[1] 'heres the reply from the ws request you made'
tldr
- 客户端将有多个 req/rep 和许多服务器
- 服务器将与许多客户端打交道
- 客户端需要 broadcast/find 合适的客户端才能与
进行消息传递
我将专注于发现问题。客户端如何知道哪些服务器可用以及每个服务器有哪些 ws 连接？
一种方法是添加第三种类型的节点，称之为broker。只有一个代理，所有客户端和服务器都知道如何访问它。 （例如，所有客户端和服务器都配置了代理的 IP 或主机名。）
当服务器启动时，它会向代理注册自己："I have ws feeds x,y,z and accept requests on 1.2.3.5:1234"。代理跟踪此状态，可能在哈希 table.
中
当客户端需要 ws feed y 时，它首先联系代理："Which server has ws feed y?" 如果代理知道谁有 feed y，它会向客户端提供服务器的 IP 和端口。然后客户端可以直接联系服务器。 （如果多个服务器可以访问提要 y，代理可以 return 一个服务器列表而不是单个服务器。）
如果服务器 运行 时间 "long"，客户端可以缓存 "server X has feed y" 信息，并且仅在需要访问新提要时才与代理对话。
通过这种设计，客户端使用代理来查找感兴趣的服务器。服务器根本不需要了解客户端的任何信息。 "real" 流量（客户端通过服务器访问提要）仍然直接在客户端和服务器之间完成 - 不涉及代理。
HTH。郑重声明，我绝对不是专家。
Zyre 协议专为无代理 "gossip" 发现而设计。 Pyre (https://github.com/zeromq/pyre) 是 Python 的实现。它为节点提供了加入 "discovery group" 和共享信息的机制。除其他功能外，它还允许群组成员向个别成员耳语或向所有成员喊话（多播）。
Zyre 使用 UDP 广播信标来发起联系，因此它通常仅限于单个子网（UDP 广播通常不会转发到子网之外）。但是，您可以通过每个子网中的服务器跨不同子网桥接一个组（见下文）。
您可以使用 zyre 将拓扑信息（在本例中为您的服务器列表）分发给您的客户端。
我只玩过一点 pyre，所以我可能没有完全正确地了解所有细节，但我会尝试这样设置它：
- 定义一个 Zyre 组。
- 每台服务器...
- 加入群组。
- 在其信标中设置其服务器地址（ip 或 fqdn，可能还有端口）header。
- 每个客户...
- 加入群组。
- 从服务器收到的 HELLO 消息中读取服务器地址。
- 与服务器建立 REQ 连接。
- Adds/removes 服务器连接数基于一段时间内收到的 HELLO/LEAVE/AVOID 条消息。
如果服务器不在同一个子网中（例如，可能它们在不同的 AWS 可用性区域），您可以预先配置 servers 了解所有服务器 IP 是什么，定期验证它们是否正常（通过服务器之间的 REQ/REP 或 PUB/SUB），并向本地组 SHOUT active-servers 信息。客户可以使用此信息 inform/adjust 他们的活动列表 servers/connections.
我考虑过完全按照上面的方法做，但不幸的是它并没有超过积压工作中的其他优先级，所以我没有超过上面的详细程度。
在这个问题上苦苦思索了一段时间，终于向高手求助了。
语言：python
problem/setup:
我有很多客户，client[n], client[n] ..等
我有很多服务器，server[n], server[n] .. etc
每个服务器 可以插入 5 个外部 ws 连接。在任何时候我可能需要打开 [x] ws 连接；也许 2，也许 32，我需要的总 ws 连接，因此需要的服务器，是动态的...
每个客户端可能连接来自服务器[1]的1个ws连接，来自服务器[2]的1个ws连接......等
我想象中的流程如何运作
- 已加载新客户端[1]，需要 2 个 ws 提要
- 新客户端[1]向所有服务器广播[xpub/xsub ?] 消息说，'hey, I need these 2 ws connections, who has them?'
- Server[1] 与 ws 连接回复 client[1]（且仅该 client）- 'I got what youre looking for, talk to me'
- client[1] 与 server[1] 进行 req/reply 通信，以便 client[1] 可以利用 server[1] 的 ws 连接对其进行查询，例如，'hey, server[1] with access to ws[1], can you request [x]' .. 服务器[1] 回复客户端[1] 'heres the reply from the ws request you made'
tldr
- 客户端将有多个 req/rep 和许多服务器
- 服务器将与许多客户端打交道
- 客户端需要 broadcast/find 合适的客户端才能与 进行消息传递
我将专注于发现问题。客户端如何知道哪些服务器可用以及每个服务器有哪些 ws 连接？
一种方法是添加第三种类型的节点，称之为broker。只有一个代理，所有客户端和服务器都知道如何访问它。 （例如，所有客户端和服务器都配置了代理的 IP 或主机名。）
当服务器启动时，它会向代理注册自己："I have ws feeds x,y,z and accept requests on 1.2.3.5:1234"。代理跟踪此状态，可能在哈希 table.
中当客户端需要 ws feed y 时，它首先联系代理："Which server has ws feed y?" 如果代理知道谁有 feed y，它会向客户端提供服务器的 IP 和端口。然后客户端可以直接联系服务器。 （如果多个服务器可以访问提要 y，代理可以 return 一个服务器列表而不是单个服务器。）
如果服务器 运行 时间 "long"，客户端可以缓存 "server X has feed y" 信息，并且仅在需要访问新提要时才与代理对话。
通过这种设计，客户端使用代理来查找感兴趣的服务器。服务器根本不需要了解客户端的任何信息。 "real" 流量（客户端通过服务器访问提要）仍然直接在客户端和服务器之间完成 - 不涉及代理。
HTH。郑重声明，我绝对不是专家。
Zyre 协议专为无代理 "gossip" 发现而设计。 Pyre (https://github.com/zeromq/pyre) 是 Python 的实现。它为节点提供了加入 "discovery group" 和共享信息的机制。除其他功能外，它还允许群组成员向个别成员耳语或向所有成员喊话（多播）。
Zyre 使用 UDP 广播信标来发起联系，因此它通常仅限于单个子网（UDP 广播通常不会转发到子网之外）。但是，您可以通过每个子网中的服务器跨不同子网桥接一个组（见下文）。
您可以使用 zyre 将拓扑信息（在本例中为您的服务器列表）分发给您的客户端。
我只玩过一点 pyre，所以我可能没有完全正确地了解所有细节，但我会尝试这样设置它：
- 定义一个 Zyre 组。
- 每台服务器...
- 加入群组。
- 在其信标中设置其服务器地址（ip 或 fqdn，可能还有端口）header。
- 每个客户...
- 加入群组。
- 从服务器收到的 HELLO 消息中读取服务器地址。
- 与服务器建立 REQ 连接。
- Adds/removes 服务器连接数基于一段时间内收到的 HELLO/LEAVE/AVOID 条消息。
如果服务器不在同一个子网中（例如，可能它们在不同的 AWS 可用性区域），您可以预先配置 servers 了解所有服务器 IP 是什么，定期验证它们是否正常（通过服务器之间的 REQ/REP 或 PUB/SUB），并向本地组 SHOUT active-servers 信息。客户可以使用此信息 inform/adjust 他们的活动列表 servers/connections.
我考虑过完全按照上面的方法做，但不幸的是它并没有超过积压工作中的其他优先级，所以我没有超过上面的详细程度。