TCP高CPU多点服务器

Question

我很好奇TCP服务器处理500+活动连接的最佳设计，即向我发送数据流。这里最大的问题是，我的数据处理程序使用活动CPU，比在客户机发送块之间花费更多的时间。

客户端用麦克风记录声音，并以2000字节的块实时发送到我的服务器。

我编写了一个简单的原型，接下来要做的是：

正在工作并侦听新的connections

• When新连接的

1. 侦听器发生了，它接受它并分派一个单独的线程来处理流的精确连接。它使用套接字上的轮询来获取新的数据。
2. 在数据块到达后，我正在处理它，可能需要很长时间。数据处理后的
3. 完成了，我从套接字读取下一个可用的数据，然后再处理，等等，直到客户端发送给我一个特殊的最终包。

。

我相信有一个更好的设计解决方案。

Answer 1

我想要考虑的关键问题是，当数据被发送到服务器的速度超过服务器处理速度时，您想要发生什么？

例如，假设您的服务器的CPU足够快，可以同时实时处理100个音频流，但有200个客户端连接并发送音频。

处理该问题的一种方法是采用简单的FIFO方法:只在先前读取的连接数据已被处理时才从给定的TCP连接读取更多的数据。这具有最终处理所有数据的优点，但缺点是，如果服务器没有及时在套接字上调用recv()，则TCP层将减缓TCP连接的速度，客户端将无法按照客户端麦克风生成数据的速率向服务器发送数据。(也就是说，您已经将问题转移给了客户端，客户端现在必须决定如何处理它生成的“过量”音频样本，但不能很快地处理send() )。

另一种方法是让服务器缓冲RAM (或磁盘)中的“多余”数据；也就是说，服务器尽可能快地读取所有传入的TCP数据，并在本地存储它，然后一个或多个单独的线程将尽可能快地处理缓冲的音频数据。这样做的好处是，当音频处理任务无法跟上时，网络数据传输速度不会减慢，但缺点是，如果服务器不断超载，待办事项队列将不断增大，直到最终服务器耗尽存储空间(RAM或磁盘)，而此时它可能会崩溃或无法运行。

第三种方法是，当待办事项变得太大(对于一些适当的值“太大”)时，简单地删除一些多余的数据，而不是处理它。这是否合理取决于应用程序的用例。

第四种方法是将同步客户端的数量限制在您知道服务器的CPU强大到足以及时处理的数量上。这是大多数多人游戏服务器使用的方法；然后，如果您发现您的服务器是“满的”，您可以通过旋转第二个服务器硬件来响应。

不管您上面选择了哪些选项，如果您不希望服务器的音频处理减慢TCP数据传输的速度，那么您将需要将您的CPU密集型音频处理和您的recv()调用分离到单独的线程中，以便您的TCP套接字都能尽快地在它们上调用recv()。否则，TCP层将通过告诉客户端减慢发送速率和减少TCP数据包窗口来响应临时完全传入的TCP缓冲区。