7

我正在尝试在 C 中为协作实时编辑器http://en.wikipedia.org/wiki/Collaborative_real-time_editor创建一个套接字服务器，但我不知道什么是最好的服务器架构。

起初，我尝试将 select 用于套接字服务器，但在那之后，我正在阅读有关 epoll 的内容，现在我认为 epoll 是最佳选择，因为客户端将发送每个用户将在 textarea 上写入的字母，以服务器，因此服务器将分配要处理的数据。

另外，我想在 epoll 中使用线程，但我不知道如何使用它们。我想使用线程，因为我认为在目标机器上使用 2 个或所有 CPU 会更好。

我的计划是

  • 服务器启动时创建2个线程

  • 第一个线程将分析新客户端并为读取或发送做好准备

  • 第二个线程将负责从/向客户端读取和发送数据

问题是这 2 个线程将使用带有 epoll_wait 的 while(1)。

我的问题是，这是使用 epoll 和线程的良好服务器架构吗？如果没有，我有什么选择？

编辑：我不能使用libevent或libev或其他库，因为这是一个大学项目，我不允许使用外部库。

4

3 回答 3

7

我认为你试图过度设计这个问题。epollLinux 中的体系结构适用于具有数千个并发连接的情况。在这些情况下，定义poll和select系统调用方式的开销将成为服务器的主要瓶颈。poll使用or selectvs.的决定epoll是基于连接数，而不是数据量。

对于你正在做的事情，在你打了几十个并发编辑器之后，你编辑系统中的人似乎会发疯。使用epoll可能会让你发疯；他们使用 API 使用一些技巧来挤出额外的性能，并且您必须非常小心地处理从调用中返回的信息。

这种应用程序听起来像是受网络 I/O 限制而不是 CPU 限制。我会先尝试将其编写为单线程服务器poll。当您收到新文本时，如有必要，为您的客户端缓冲它，然后在套接字接受write调用时将其发送出去。使用非阻塞 I/O；您要阻止的唯一呼叫是poll呼叫。

如果您在收到数据后，但在将其发送回客户端之前对数据进行大量处理，那么您可以从多线程中受益。先写单线程版本，然后如果你是 CPU 密集型的（检查 using top）并且大部分 CPU 时间花在你正在做数据处理的函数上（检查 using gprof），添加多线程来做数据处理。

如果需要，您可以在程序中使用管道或 Unix 域套接字在不同线程之间进行通信——这样主线程中的所有内容都可以通过poll. 或者，使用此模型，您甚至可以使用多个进程fork而不是多个线程。

于 2011-12-17T23:23:32.437 回答
3

只需开始使用libevent或libev并按照他们的示例进行操作即可。有很多例子——不要试图在这里发明任何新东西

于 2011-11-28T14:07:05.480 回答
3

您可能需要考虑使用libev或libevent之类的东西，而不是编写自己的事件处理实现。这些为您提供了一个跨平台的事件处理程序，它将使用任何合适的东西（无论是select、poll、还是其他任何东西） epoll，kqueue并且最有可能比让两个线程相互移交工作的开销更低。

于 2011-11-28T14:05:29.380 回答