适用于bittorrent客户端的良好多线程模型

Good Multi-Thread Model for a bittorrent client?

本文关键字：多线程模型 bittorrent 客户端适用于更新时间：2023-10-16

我目前正在编写一个bittorrent客户端。在我的程序中，我需要开始思考多个线程是否会改进我的程序，以及我需要多少线程。

我假设我会分配一个线程来处理跟踪器，因为程序可能会同时与几个（大约1-5个）跟踪器接触，但只需要在跟踪器指定的时间间隔内（大约20分钟）与它们接触，所以程序不会很密集。

该程序将定期与众多同行联系，从他们那里下载文件。以下内容摘自Bittorrent规范Wiki：

实施者的注意：即使有30个对等点也足够了，事实上，官方客户端版本3只有在对等点少于30个的情况下才会主动形成新连接，如果对等点少于55个，则会拒绝连接。此值对性能非常重要。当一篇新文章完成下载后，需要将HAVE消息（见下文）发送给大多数活跃的对等方。因此，广播流量的成本与对等体的数量成正比地增长。在25岁以上，新的同行极不可能提高下载速度。强烈建议UI设计者将其弄得晦涩难懂，因为这样做很少有用。

这表明我应该与大约30名同龄人接触。对于我的Bittorrent客户端来说，什么是好的线程模型？显然，我不想为每个对等端和每个跟踪器分配一个线程，但我可能需要的不仅仅是主线程。你有什么建议？

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

对于网络，将所有内容保持在一个线程上，并使用非阻塞I/O进行多路复用。在Unix系统上，这将是一个带有选择/轮询（或特定于平台的扩展，如epoll）的设置；在Windows上，这将是完成端口。

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

如果您想将线程视为单独组件的容器，那么磁盘I/O可以进入另一个线程。在这种情况下，您可以使用阻塞I/O，因为无论如何都没有太多多路复用。

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

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

当您标记问题[C++]时，我建议使用C++11的std:thread。你可以在这里找到一个很好的教程（还有很多其他教程）。

关于线程数量：您可以毫无问题地使用30个线程，并让它们检查是否有什么事情要做，并在检查之间让它们休眠一段合理的时间。操作系统将处理其余部分。