问题标签 [client-server]

在客户端-服务器系统中，“向客户端询问”更多信息的服务器方法是否被认为是良好的架构？如果是这样，设计这种场景的最佳方法是什么？这有“模式”吗？

例如，假设最终用户在客户端 UI 中选择了他们想要删除的一组记录，然后客户端以该记录集作为参数对服务器进行“删除记录”调用。然后服务器找到那些以某种方式“特殊”的记录的子集，因此需要用户确认。服务器是否适合以某种方式“回调”客户端到称为“确认记录”的方法，同时仍继续从客户端到服务器的原始调用？

那么更复杂的服务器调用可能需要服务器和客户端之间的长时间“对话”呢？

我正在重构一些客户端-服务器代码，它使用术语响应、结果和回复来表示同一件事（来自服务器的答案）。虽然它并不那么重要，但在编写新代码时很难猜测使用哪个词，所以我想将这三个术语统一为一个并进行适当的重构，但我不确定哪个词是“最好”，如果有这样的事情。

有什么基于优先级和标准来命名这个案例的建议吗？

我正在尝试解决以下问题：

1. 我有一个服务器端 .net 应用程序，其中包含 PONO 字典：缓存。

2. 我有许多客户端 .net 用户界面可以查询其中一些 PONO，方法是使用密钥或要求服务器仅过滤具有特定属性值的 PONO：客户端

编辑：客户端是 C# 胖客户端，而不是 Web 应用程序。所以在客户端和服务器之间使用任何通道类型都是可以的。

3. 当然，一些客户端可以更新 PONO 并将其发送回服务器。然后我希望服务器足够聪明，以通知所有已经持有此 PONO 的客户端具有新值，甚至将 PONO 发送给所有具有与新 PONO 值匹配的过滤器的客户端。

4. 我并不真正关心交易方面。就我而言，最后一个发言的总是正确的。

我认为这样的功能看起来很通用，所以它一定已经存在于某个地方。有什么建议吗？

谢谢

作为一个副项目，我目前正在为我曾经玩过的一个古老的游戏编写服务器。我试图使服务器尽可能松耦合，但我想知道多线程的一个好的设计决策是什么。目前，我有以下一系列操作：

• 启动（创建）->
• 服务器（监听客户端，创建）->
• 客户端（监听命令并发送周期数据）

我假设平均有 100 个客户，因为这是游戏在任何给定时间的最大值。对于整个事情的线程化，正确的决定是什么？我目前的设置如下：

• 服务器上的 1 个线程侦听新连接，在新连接上创建一个客户端对象并再次开始侦听。
• 客户端对象有一个线程，监听传入的命令并定期发送数据。这是使用非阻塞套接字完成的，因此它只是检查是否有可用数据，处理它，然后发送它已排队的消息。登录在发送-接收周期开始之前完成。
• 一个线程（目前）用于游戏本身，因为我认为从架构上讲，它与整个客户端-服务器部分是分开的。

这将导致总共 102 个线程。我什至正在考虑给客户端 2 个线程，一个用于发送，一个用于接收。如果我这样做，我可以在接收线程上使用阻塞 I/O，这意味着线程在一般情况下大部分是空闲的。

我主要担心的是，通过使用这么多线程，我将占用资源。我不担心比赛条件或死锁，因为无论如何我都必须处理这些事情。

我的设计是这样设置的，即我可以使用单个线程进行所有客户端通信，无论它是 1 还是 100。我已经将通信逻辑与客户端对象本身分离，因此我可以实现它而无需重写很多代码。

主要问题是：在应用程序中使用超过 200 个线程是错误的吗？它有优点吗？我正在考虑在多核机器上运行它，这样会充分利用多核吗？

谢谢！

在所有这些线程中，它们中的大多数通常会被阻塞。我预计连接数不会超过每分钟 5 个。来自客户端的命令很少会出现，我会说平均每分钟 20 个。

按照我在这里得到的答案（上下文切换是我正在考虑的性能影响，但在你指出之前我不知道，谢谢！）我想我会选择一个听众的方法，一个接收者、一个发送者和一些杂项；-)

考虑到世界上有这么多严苛的防火墙，我有什么理由不应该在端口 80 上运行服务器软件来保证最大可能的可访问性？似乎最常见的防火墙例外是允许端口 80 上的出站连接。我知道任何类型的数据包检查仍会阻止我的非 HTTP 流量，但如果是这种情况，我确信防火墙不会有任何无论如何，其他开放的传出端口。

如果服务器已经在端口 80 上有一个网络服务器，是否可以在端口 80 上使用某种虚拟主机（即同一台机器上的myDomain.com:80和myApp.myDomain.com:80）？

与我一起工作的开发团队的一部分人面临着编写服务器以与我们的产品集成的挑战。我们有一些提供 C SDK 的低级传感器设备，我们希望通过网络共享它们以供收集数据的人们使用。听起来很简单，对吧？有人会将传感器设备连接到建筑物一部分的机器并运行我们的服务器，从而与网络的其余部分共享设备。然后客户端将通过我们的应用程序连接到该服务器并从设备收集传感器读数。

我创建了一个简单的、与语言无关的网络协议和一个 Java 参考实现。问题在于创建一个可与仅提供用 C 编写的 SDK 的设备一起使用的实现。我们正在考虑执行以下操作：

1. 创建轮询线程，收集和存储每个连接设备的最新读数。
2. 使用多线程服务器将每个传入连接分离到工作线程。
3. 当工作线程接收到传感器读取请求时，轮询线程收集的最新值将被发送回客户端。

这是很多线程，尤其是在 C 中。所以，回顾一下，一般要求是：

• 在 Windows XP/Vista、Linux 和 OS X 机器上运行
• 用 C 或 C++ 编写，与我们拥有的 C SDK 交互
• 接受可变数量的同时连接（工作线程）
• 必须使用线程，而不是分叉（不想处理另一层 IPC）

谁能建议一个库，最好是一些示例代码来开始使用？

Cocoa 中是否有一种方法目前被认为是创建多层或客户端服务器应用程序的最佳实践？

我是一位经验丰富的 Web 开发人员，我真的很喜欢 Python。不过，我是 Cocoa 的新手。我正在尝试编写的应用程序是一家大型医院的患者管理系统。该系统预计会随着时间的推移存储大量数据，但在单个会话期间传输的数据非常少（主要是文本）。假设通信发生在本地网络（有线或无线）上。当然，它必须是高度安全的。

我能想到的最好办法是编写一个 Python REST Web 服务并通过 Cocoa 应用程序连接到它。也许我什至会使用 Python 来编写 Cocoa 应用程序本身。

看看 Cocoa，我在 Cocoa 中看到了非常棒的技术，比如 CoreData，但我找不到任何类似的用于客户端服务器开发的技术。我只是想确保我没有遗漏任何东西。

你怎么看？

现实世界的例子将不胜感激。

提前致谢。

我有现在通过 TCP 通信的客户端和服务器程序。我正在尝试使用 POSIX 消息队列（当然，在客户端和服务器在同一台机器上的情况下）。我希望它能提高性能（特别是通过减少延迟）。

我已经解决了大部分问题，但不确定一件事：如何建立“连接”。服务器同时接受来自多个客户端的连接，所以我很想模拟 TCP 连接建立过程，如下所示：

1. 服务器打开一个具有已知名称的队列并连续读取它（它可以select(2)与 TCP 一起使用）。
2. 客户端打开三个队列：两个具有任意名称（包括一些唯一性，例如 PID 以避免冲突），一个具有服务器使用的众所周知的名称。
3. 客户端向服务器的队列发布一条“连接”消息，包括客户端的队列名称（一个指定用于客户端到服务器的流量，另一个用于相反的流量）。
4. 服务器打开客户端连接消息中指定的队列，并开始从客户端到服务器的队列中读取（选择）。
5. 客户端使用众所周知的名称关闭服务器队列。双向通信使用客户端命名的两个队列（每个方向一个）进行。

您可能会看到该方案与常见的 TCP 方法有何相似之处，这绝非偶然。但是，我想知道：

1. 你能想出更好的方法吗？
2. 你看到我的方法有什么潜在的问题吗？
3. 您是否还有其他想法，包括在同一台机器上使用消息队列而不是 TCP 是否会真正提高性能（延迟）？

请记住，我之前没有使用过 POSIX 消息队列（我之前确实使用过 IBM WebSphere MQ，但那是相当不同的）。平台是Linux。

我有一种感觉，必须有客户端-服务器同步模式。但我完全没能用谷歌搜索一个。

情况很简单——服务器是中心节点，多个客户端连接并操作相同的数据。数据可以被拆分为原子，如果发生冲突，服务器上的任何内容都具有优先级（以避免让用户解决冲突）。由于潜在的大量数据，部分同步是首选。

对于这种情况，是否有任何模式/良好做法，或者如果您不知道 - 您的方法是什么？

以下是我现在认为解决它的方法：与数据并行，将保存一个修改日志，所有事务都带有时间戳。当客户端连接时，它以合并的形式接收自上次检查以来的所有更改（服务器检查列表并删除添加的内容，然后删除，合并每个原子的更新等）。瞧，我们是最新的。

另一种方法是保留每条记录的修改日期，而不是执行数据删除，只需将它们标记为已删除。

有什么想法吗？

我正在编写一些客户端/服务器软件，并且面临以下设计问题。通常，我非常随意地使用 VERIFY 宏 - 如果用户的机器出现问题，我希望软件失败并记录错误以便修复。我从不喜欢忽略任何类型的错误。

但是，我现在正在编写一个服务器。如果服务器死了，很多客户端就会宕机，所以服务器应该尽可能少地死掉。因此，我不知道如何处理一些我认为是致命异常的情况。

例如，我从一个没有登录的用户那里得到一个网络数据包。即使它不应该发生，我有足够的经验知道“不可能”的错误确实会不时发生。所以我很确定如果我在这些情况下犯了致命错误，服务器最终会崩溃。另一方面，我可以记录并忽略错误并继续，但我担心一些错误可能会以这种方式未被检测到。

在这种情况下你会怎么做？