I2P 开发者会议 - 2006 年 5 月 16 日

<cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html <cervantes> 0) 嗨 <cervantes> 1) jrandom 不在 <cervantes> 2) ??? <cervantes> 0) 嗨 <cervantes> 嗨 <cervantes> 转到 1) <cervantes> jrandom 今天不在，但他明天会给我们一个状态更新 <cervantes> 2) ??? <cervantes> 还有人要在会议上补充什么吗？ <bar> 我有个问题 <cervantes> 那样的话... * cervantes 做好准备 * cervantes 停止准备 <Complication> 啊哈，一个问题... <bar> cvs 里的 PRNG（伪随机数生成器）修复，会提升整体性能，还是与别的东西有关？ <cervantes> 目前不确定它总体会有什么影响 <Complication> 我个人不清楚它的总体影响，但至少涉及我知道的两种行为： <cervantes> 但它具体修复了 i2ptunnel 的一个问题 * cervantes 让 complication 来解释 <Complication> tunnel 长度随机化，以及 IRC 服务器的选择（更一般地说，从 I2PTunnel 目标列表中随机选择） <Complication> tunnel 长度的随机化可能对整体网络健康有显著影响，因为它允许那些可以在 tunnel 长度上做出权衡的客户端真正这么做 <Complication> 这样他们就不会一直屏住呼吸只建 2 跳的 tunnel，也会尝试一些 1 跳的 tunnel <Complication> （在困难时期，1 跳的更容易成功） <cervantes> 此外，部署之后 IRC 连接性可能会改善。基本上，freshcoffee 因为在列表中排第二而从未收到任何客户端连接——所以下个版本中，负载应该会在两个服务器之间均匀分布 <bar> 所以这个 bug 让人们在可选时总是选择更长的 tunnel 长度？ <Complication> 如果我理解正确，所有涉及较小整数的随机化（例如选择 0 或 1）都会受影响 <Complication> 我觉得涉及较大整数的随机化（例如在 0 到 100 之间选一个整数）受影响要小一些 <Complication> 如果你感兴趣，他回来后你可以问 jranom 了解细节 <Complication> 我可能会把细节说错。 <bar> 我明白了，谢谢。抓得好 <Complication> 嗯，cervantes 过来就开始抱怨没有任何过载 ;P <cervantes> 我也是这么理解的 <cervantes> 你看……人生中不抱怨就什么也得不到 :) <cervantes> 还有谁有其他问题或会议议题吗？ <fox> <duck> 有 <Pi> 关于总体网络健康有个问题：我看到越来越多的客户端在 I2P 版本上落后（比如还有 2 个在用 0.6.1.11 等）。这些客户端不会让我们更难监控对核心更改的效果吗？（似乎‘更少的人’愿意更新） <fox> * duck 重复了上面的内容 * w423412323 建议沿着这个方向换个话题。 ;) <fox> <duck> 我在想，我在 cvs 邮件列表上看到一些有点怪的调参提交。那些是更多的实验吗？是基于观察的吗？是不是为时过早？ <Complication> Pi：只要数量不多，就不应该有太大影响 <Pi> 根据我现在的 netdb，300 个客户端里有 70 个不是 0.6.1.18 版本 <Complication> 这是一场比拼数量和容量的游戏——如果大多数 router，或者至少最高容量的 router 都合理更新了，少数人忘了自己安装过 I2P 也无关紧要 :) <cervantes> Pi：如果旧的 router 行为异常，网络应该会自我适应，减少通过它们转发的流量 <cervantes> *被路由 <cervantes> Complication：你看到 duck 的问题了吗？ <Pi> 还有一个关于 i2p-console 上前些时候出现的一个统计的问题：handle backlog 是什么意思？ <Complication> duck：你是指 tunnel 限速的调整吗？这些算是调优，意思是它们本身不会带来很多全新的东西，但现在应该已经经过了相当充分的测试（比如它们大概不会 byte〔双关：bite/byte〕） <Complication> 但在你运行一种完全超出我能想到参数范围的奇异配置时，它们可能会小小地 byte 一下 <fox> <duck> Complication：我在想，把‘3’改成‘2’这些小东西真的有那么重要吗 <fox> <duck> 不过看起来那个随机问题可能是个大麻烦 <fox> <duck> （不过它对网络不健康的相对影响取决于它是什么时候引入的） <cervantes> Pi：handle backlog 是待处理的入站 tunnel 加入请求的数量（引自变更日志） <Complication> 如果你指的是随机的 nextInteger() 问题，以及它对 tunnel 长度随机化的影响，我认为会有显著效果 <Complication> 构建 1 跳和 2 跳 tunnel 的成本差异相当明显 <Pi> 谢谢，cervantes :) <fox> <duck> 它是何时引入的？ <Complication> duck：我想它是在切换到 Fortuna 生成器时引入的，或者是其中的一些修改 <fox> <duck> 好的；非常感谢你的意见 <Complication> 让我查一下 cvsweb 获取更多细节... <cervantes> Pi：我相信现在已经有代码在队列填满时丢弃入站 tunnel 请求（以帮助降低 CPU 负载） <Complication> Pi：是的，那应该是用于决定“我们是否有足够容量参与另一个 tunnel？”的另一个参数的可见指示器 <cervantes> duck：自从引入修复后，我确实感受到 router 行为有很大变化——不得不说，并不全是好事 :) <Complication> handle backlog 很大 == 拥塞，尝试加入他人的 tunnel 没什么意义 <cervantes> 前几天负载平均值到了 14，参与的 tunnel 有 12000 个 <Complication> handle backlog 在高容量 router 上似乎尤其重要（指的是 cervantes 看到的情况） <Complication> 低容量的 router 通常会因为带宽原因而限制它们对 tunnel 的接受率 <Complication> （更准确地说，是因为 tunnel 测试时间） <Complication> （至少，会尝试这么做） <cervantes> 哇，我们已经撑了半个小时.... <Complication> 的确 :D <cervantes> 还有人想提点别的吗？ <cervantes> 那样的话... * cervantes 做好准备 * cervantes *啪* 把会议关了 <fox> <duck> 谢谢你操持这次会议 <cervantes> 呵，我本来打算在大家还没开口之前就‘啪’地把它关了....但 bar 破坏了那个计划 :)