3

我正在尝试创建一个具有单个服务器和多个客户端的网络架构。客户端可以随时连接和断开连接，因此他们需要向服务器宣布它们的存在或关闭。服务器必须能够向任何特定客户端发送数据。

为此使用的最佳可扩展性协议/架构是什么？

目前我使用一个REQ/REP以便客户端可以“登录”和“注销”，以及一个SURVEY套接字以便服务器可以向所有客户端发送数据。发送的消息具有它想要处理消息的特定客户端的 ID。

这是好事，还是有更好的东西？

4

2 回答 2

2

听起来更像是您需要发布者订阅者。使用 0MQ 和 nanomsg，您无需特别执行任何操作来管理连接/断开连接，该库会为您执行此操作。

但是，如果您想要更复杂的消息管理（例如缓存传出消息以防另一个客户端选择连接），那么您必须自己管理。您可以使用来自客户端的单个推送来让他们宣布他们的存在（他们会发送一条消息说明他们是谁），然后从服务器向每个客户端发送更多推送，以从缓存中发送消息你有。繁琐，但仍然比使用原始套接字编程要容易得多。

使用 req rep 可能会出现问题 - 如果任一端崩溃或意外断开另一端可能会处于停滞、不可恢复的状态。

于 2015-09-22T22:25:36.900 回答
2

对不起，在现实世界中，没有“一刀切”

还有许多其他方面会影响架构 - 大局观。

虽然 Martin SUSTRIK 的两个很酷的孩子 -- ZeroMQ& nanomsg-- 在提供卓越的基础 + LEGO 式可扩展正式通信模式的构建块方面做出了很大的帮助，但他们只是一个开始，并且说REQ/REP或者SURVEY行为原语（伟大的创新，但仍然是一个积木）是架构几乎所有建筑师和福音传道者都会感到不安。

最初的问题很重要，但是您已经收到了第一个建议，将其在行政上关闭，因为一些“翼展更宽”的人认为您的问题“太宽”或“意见”，而不是 MCVE 代码示例驱动( . .. 是的，StackOverflow 的生活有时又快又残酷）。

因此，如果没有任何进一步的详细信息，我的建议是检查最新版本的PUB/SUB( 可以并且确实在PUB-side 上进行过滤 ( 而不是SUB像早期 ZeroMQ 版本中的设计那样，一旦已经 xmited / 交付了数以亿计的字节世界只是在全球分布的同行层面上意识到，没有人还没有SUB收到任何东西）而不是提到的SURVEY。

没有任何上下文，认真判断是无稽之谈，对您尝试设计和实现的东西的改进越少。

我会做我试图这样做的糟糕服务。

最好的下一步？

我现在能为你做的就是引导你看到关于这个主题的更大图景 >>>更多的论据，一个简单的信号平面/消息平面插图和一个指向 Pieter HINTJENS 必读书籍的直接链接.

于 2015-09-22T22:29:23.460 回答