java - 如何实现多个 BitTorrent 公告请求的超时？

Question

我正在尝试制作一个 BitTorrent 客户端，只是为了学习目的。我首先会解释一下到目前为止我所做的事情。

我创建了一个线程池，其大小是可用处理器的数量。现在每个 torrent 文件都在单独的线程上执行。我从每个 torrent 文件中获取跟踪器 URL 列表，并使用 java NIO 发送连接请求。我假设我大约在同一时间发送所有连接请求，因为我只是循环 URL 列表并发送请求。因此，我不再为每个 URL 维护超时，而是在发送第一个请求时启动计时器。当计时器超时时，我向所有未响应的 URL 重新发送连接请求。 (在这里，对于计时器，我计算间隔并跟踪开始时间startTime。我循环直到currentTimeMillis()超过startTime +interval。在循环内，我使用 selector.select() 来选择准备好的 channels。当循环退出时，我将连接请求重新发送到所有 channel 没有响应。我没有使用 Timer 和 ScheduledExecutorService 因为我认为这可能会导致线程数量激增。我已经在每个文件使用一个线程。请纠正我这并提出更好的方法)。

主要问题出现在发送公告请求时。我可能在任何时间点收到连接响应，此时我应该发送公告请求并启动计时器，如果超时则重新发送请求。目前，对于每个连接响应，我向线程池提交一个 Runnable 任务，该任务处理通知请求的发送。因此，我为每个声明请求-响应周期使用一个线程。因此，如果我有很多 torrent 文件，并且每个文件至少有 5 个跟踪器 URL，这不会造成性能问题吗？有什么更好的方法可以让这件事发挥作用？如果有人能够阐明 torrent 客户端如何同时处理如此多的文件和如此多的请求响应周期，那将非常有启发。

Answer 1

使用 nio 或基于选择器的库(如 netty)的主要好处是允许您将多个网络连接复用到一个对象中，并且只等待该对象。 Multiplex 的定义是 comprising several interleaved parts 。在这种情况下，您将多个网络连接(以前需要单个线程等待)编织到一个概念对象( Selector )中，该对象只需要一个线程等待。在您的情况下，您可以将整个网络连接编织到一个选择器中，并在单个线程中等待它。这样就不会出现线程激增的情况。以这种方式重新架构系统可能需要为每个连接进行更多的簿记，而这些连接以前是负责处理该连接的线程的本地连接。

此外，不要使用 System#currentTimeMillis 来计算时间差，而是使用 System#nanoTime，因为它不会受到系统时间任何更改的影响。