Transmission 客户端中 Peer 连接候选列表的随机化问题分析

问题背景

在 Transmission 4.0.x 及以上版本的 BT 客户端中，存在一个关于 peer 连接候选列表随机化不足的问题。这个问题会影响客户端建立 peer 连接的公平性和效率，特别是在新添加种子时表现得尤为明显。

技术细节

连接建立机制

Transmission 默认情况下会尝试每秒建立最多 18 个新的出站连接，或者每 500 毫秒脉冲周期建立 9 个连接。在理想情况下，"热"候选列表（最多包含 36 个条目）每 2 秒重建一次，然后在 4 个脉冲周期内逐步消耗。

问题表现

当新种子启动时，客户端会从 tracker 获取最多 80 个 peer 并添加到"冷"peer_info 池中。这个"冷"列表始终按照地址数值顺序维护，即使 tracker 返回的是随机化列表。

get_peer_candidates() 函数负责从"冷"peer_info 池构建"热"候选列表，理论上应该通过添加随机因子(salt)来使最终的"热"列表随机化。然而，当前实现中，只有当候选列表大于"热"列表缓存大小时才会使用随机因子。

实际影响

这导致客户端总是优先连接地址数值最低的 9 个 peer，500 毫秒后再连接接下来的 9 个 peer，依此类推。当 peer 连接限制设置较低（如 5 或 10 个）时，最初连接的 peer 会被优先保留，而同一"热"候选列表中稍后连接的 peer 则处于劣势。

解决方案分析

建议修改 get_peer_candidates() 函数，使其始终执行带随机因子的排序操作。具体实现可参考以下伪代码：

// 只保留最佳的 max 个候选
if (static auto constexpr Max = tr_peerMgr::OutboundCandidates::requested_inline_size; Max < std::size(candidates))
{
    std::partial_sort(
        std::begin(candidates),
        std::begin(candidates) + Max,
        std::end(candidates),
        [](auto const& a, auto const& b) { return a.score < b.score; });
    candidates.resize(Max);
}
else
{
    std::sort(
        std::begin(candidates),
        std::end(candidates),
        [](auto const& a, auto const& b) { return a.score < b.score; });
}

技术影响评估

这个修改将确保：

1. 无论候选列表大小如何，都会进行随机化排序
2. 消除对低地址数值 peer 的连接偏好
3. 提高 peer 连接的公平性
4. 优化新种子启动时的连接分布

结论

这个看似微小的排序逻辑调整实际上对 Transmission 的 peer 连接策略有显著影响。它解决了新种子启动时 peer 连接分布不均的问题，使客户端能够更公平地利用所有可用的 peer 资源，从而提高下载效率和网络资源利用率。对于使用较低 peer 连接限制的用户来说，这一改进尤为重要。