C# 自组织应用程序

对于许多人将在office中使用的应用程序，我有以下要求-无服务器组件。客户端应用程序的所有实例都应该以某种方式进行协商，以决定哪个客户端将担任服务器角色。客户端之间应该通过IP进行通信

如果客户端应用程序宕机，另一个客户端必须以无缝方式接管。我知道拥有一台服务器会简单得多。但由于应用程序必须具有很强的弹性，因此，强大的应用程序不希望冒服务器宕机（甚至备份）的风险，而是依赖于这种混合网状连接，即服务器角色从客户端跳到客户端

我想我的应用程序连接被切断了。基本上，当应用程序启动时，它会通过UDP（到所有人都收听的预定义IP地址或通过UDP广播）宣布自己。从那时起，通信以类似的方式进行

我遇到的问题是如何在客户端之间协商/自组织，以选择一个具有服务器角色的客户端。以及如何可靠地检测到客户已经失败，然后必须进行新的协商。最后一个困难是复制由具有服务器角色的客户端累积的数据

我在c#中创建了一个原型，用于通信并尝试复制数据，但协商部分（尤其是与客户端故障相结合的部分）

起初我认为这就是ZeroConf（又名Bonjour）所做的。但这只是宣布可用的网络服务

无论如何，我不想重新发明，我也不能成为第一个想做这件事的人。所以我的问题是：

• 是否有一种模式已经实现了我上面描述的内容
• 如果是这样，是否有一个可用的.NET（甚至本机）库
• 在客户端之间协商服务器角色的好方法是什么

---

为什么您需要协商服务器的角色？想一想。如果每个“客户机”都可以处理在客户机上启动的工作的“服务器”职责，那么在一定程度上，所有“客户机”都可以同时处理客户机和服务器。然后，唯一的问题是在客户端之间协商持久状态的复制，并在两个客户端处理相同的状态时处理并发性（从我的角度来看，最困难的部分是在一个客户端“保存”时提醒其他客户端状态已更改）这些数据以及让其他客户机在该州工作为解决冲突提供了一种方法——如果last in始终获胜，这可能不是一个问题，但这种情况很少见）

如果您真的要使用mesh，那么每个客户机都应该能够独立于其他客户机处理它的工作，并且只传递对持久化状态的更改，以便副本匹配

---

以上假设一个人在同一时间使用同一状态的次数是有限的。如果这是正常情况，那么您必须找出一些“服务器”逻辑。

因此，您目前有一个系统，其中LAN上的每个客户端将通过UDP向LAN的其余部分宣布自己。其中一个客户端应用程序是一个“服务器”，除了本身就是一个客户端之外，还具有一些额外的命令和控制能力

当然，这不是一个新的想法。您想要的是在最初的“我在这里”连接通信期间添加一些额外的对话。当一个新客户端对局域网的其余部分喊“我在这里”时，如果有服务器，服务器应该说“欢迎，我就是服务器”，新客户端应用程序现在知道哪个客户端充当服务器。所有其他客户可能也应该说“嗨”。如果没有服务器，新客户机应该首先重复“hello”（毕竟是UDP；您必须预期一些消息不会被接收），如果没有人响应，则该新客户机是网络上唯一的客户机，默认情况下是“服务器”。如果有其他人但没有人声称是服务器，客户端可以“相互讨论”以确定新服务器

除此之外，服务器副本应该定期（可能每3-5秒）向所有人喊出“我还在这里”；这被称为“心跳”消息，是双向“ping”验证方法的常见替代方法

如果服务器应用程序（或任何副本，真的）正常关闭，它应该喊出“再见，大家，找出谁是下一个服务器”。剩下的客户可以相互讨论。如果充当服务器的客户端崩溃，客户端将错过服务器的“心跳”消息，询问“谁是服务器”，如果没有人响应，客户端将相互讨论

现在，客户“相互讨论”可以是简单的，也可以是复杂的。最简单的方法是，无论哪个客户端说“好的，我现在是服务器”都变成服务器。您可能需要在消息中包含某种时间，这样，如果另一台计算机在同一时间说了，客户可以说“客户15先说了，所以我们要跟他一起去”。客户可以“投票”；让每个客户机与所有其他客户机对话，以确定该客户机与所有其他客户机之间的标称延迟，该客户机将“投票”选择延迟最低的连接（没有客户机可以投票给自己，除非它发现它是唯一的连接）。多数选票获胜

或者，作为“心跳”消息的一部分，服务器可以说“如果我宕机，我的继任者就是客户机X”；如果心跳信号丢失，并且来自客户端的后续“您还在吗，服务器”消息没有响应，客户端可以说“国王死了！国王客户端X万岁！”

需要了解的是，在全客户机系统中选择“权威”客户机作为服务器的这一层治理将极大地增加客户机通信的复杂性。此外，虽然使用UDP协议有助于快速通信，但UDP消息始终会发生冲突；如果你在说话，而另一个