c++ - 用于 bittorrent 客户端的良好多线程模型？

Question

我目前正在编写一个 bittorrent 客户端。我的程序即将进入需要开始考虑多线程是否会改进我的程序以及我需要多少线程的阶段。

我假设我会分配一个线程来处理跟踪器，因为程序可能同时与多个(大约 1-5 个)联系，但只需要在跟踪器分配的时间间隔内联系它们(大约 20 分钟)，因此该计划不会很密集。

该程序将与众多同行保持定期联系，以从他们那里下载文件片段。以下摘自Bittorrent Specification Wiki :

实现者的注意事项:即使 30 个对等点也足够了，官方客户端版本 3 实际上只会在少于 30 个对等点时主动形成新连接，如果有 55 个则会拒绝连接。这个值对性能很重要。当一个新片段完成下载时，需要将 HAVE 消息(见下文)发送给最活跃的对等点。因此，广播流量的成本与对等点的数量成正比。超过 25，新节点极不可能提高下载速度。强烈建议 UI 设计人员将其设置为模糊且难以更改，因为这样做很少有用。

这表明我应该与大约 30 位同行保持联系。什么线程模型适合用于我的 Bittorrent 客户端？显然我不想为每个对等点和每个跟踪器分配一个线程，但我可能需要的不仅仅是主线程。你有什么建议？

Answer 1

我认为这里对多线程的需求不大。线程太多还意味着线程之间需要进行大量通信，以确保每个人都在正确的时间做正确的事情。

对于网络，将所有内容都放在一个线程上，并使用非阻塞 I/O 进行多路复用。在 Unix 系统上，这将是一个带有 select/poll(或特定于平台的扩展，例如 epoll)的设置；在 Windows 上，这将是完成端口。

您甚至可以将磁盘 I/O 添加到其中，这将使线程之间的通信变得微不足道，因为没有任何 :-)

如果您想将线程视为独立组件的容器，则磁盘 I/O 可以进入另一个线程。在这种情况下，您可以使用阻塞 I/O，因为反正没有很多多路复用。

同样，在这种情况下，跟踪器处理也可以进入不同的线程，因为它是与对等处理不同的组件。 DHT 也一样。

您可能希望将校验和检查卸载到单独的线程中。不太确定这会有多复杂，但如果涉及大量 CPU 使用，那么将它从 I/O 内容中分离出来听起来并没有那么糟糕。