用于游戏（和其他任务）的简单而有效的UDP服务器的策略

Question

我正在努力实现我在UDP上工作的简单但非常有效的多线程服务器的想法。主要目标是游戏（类似）应用程序，但如果它也可以用于其他目的，那将是很好的。

我想使用此API /技术等

1. STD :: Thread for multithreading，因为它是C ++标准的一部分，它应该是面向未来的，据我所知，它既简单又适用于C ++。
2. BSDSock（Linux）＆amp; WinSock2（Windows）。我将创建一个名为Socket的抽象类，并为每个平台（Linux - BSD，Windows - WinSock）创建实现本机API的派生类。然后我会使用基类Socket提供的API，而不是本机/平台API。这将允许我使用一个代码用于整个服务器/客户端模块，如果我想更改平台，我只需要切换类型的套接字就可以了。

对于服务器 - 客户端通信的策略，我想到了这样的事情： 每个程序都有两个套接字 - 一个用于侦听指定端口，另一个用于向服务器/其他客户端发送数据。两个套接字都运行在不同的线程上，这样我就可以同时读取和发送数据（排序），等待数据的方式不会破坏我的性能。将有一个主服务器，其他客户端将直接连接到该服务器。客户端将仅发送其数据并直接从服务器接收数据。

现在我有一些问题：

1. 使用STD :: Thread是明智的吗？我听说它在Linux上很好用，但在Windows上却没那么好。 PThreads会好得多吗？
2. 关于为许多平台（主要是Linux和Windows）制作一个代码的任何其他有趣的想法？或者我的还够好吗？
3. 关于服务器/客户端如何工作的策略的任何其他想法或一些提示？我写了一些简单的网络应用程序，但它不需要那么好的策略，所以我不确定它是否最好来自简单的想法。
4. 我应该多久从客户端向服务器（以及从服务器到客户端）发送数据？我不想泛滥网络并使服务器负载100％？

另外：它应该同时适用于2-4名玩家，我不打算在目前更多地使用它。

Answer 1

直观地说，从多线程目的来看，Linux + Pthread将是一个很好的组合。大量关键任务系统正在运行该组合。但是，当我们来到std :: thread时，具有平台依赖性质是一个很好的功能。当然，如果窗口方言中有一些难闻的气味，MS将来会纠正它们。但是，如果我是你，我一定会选择Linux + std :: thread组合。选择Linux over Windows是一个不同的主题，不需要在这里发表评论（关于服务器开发的观点）。 std :: thread为您提供了一组很好的功能，但具有pthreads的强大功能。

关于UDP，你既有利也有弊。但是，我想说如果你打算公开你的服务器，你也必须考虑网络防火墙。如果您可以解决UDP（数据包重新排序，丢包恢复）的固有传输层问题，那么在大多数情况下UDP服务器都是轻量级的。

取决于您的游戏，您需要决定发送邮件的频率。我无法发表评论。

此外，请更加重视数据通信的额外安全性。你的服务器迟早会被黑客入侵。这只是时间问题。