I2P 开发者会议 - 2005年4月25日

16:12 <jrandom> 0) 嗨 16:12 <jrandom> 1) 网络状态 和 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) 嗨 16:13 * jrandom 挥手 16:13 <@cervantes> 嗨 16:13 <jrandom> 每周状态说明已发布在 @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 16:14 <jrandom> 在大家浏览的同时，我们进入 1) 网络状态 16:14 <jrandom> 正如大家所见，我们发布了一个新版本，到目前为止结果相当积极 16:15 <@cervantes> （耶！） 16:15 <jrandom> 还没到我们想要的水平，但基本解决了我们看到的主要问题 16:15 <jrandom> 嗯，能在 2+ 跳的 tunnel 上再次获得还算过得去的构建成功率，真不错 :) 16:16 * jrandom 在另一台 router 上，1hop 的 tunnel 成功率超过 50% 16:17 <jrandom> 我认为 0.6.1.17 中最近的几处改动也应有助于避免将来出现类似的拥塞崩溃 16:17 <jrandom> 不过，对用户可见的结果是我们偶尔会看到 lease 过期，但系统不会自我叠加恶化，而是会退避 16:17 * cervantes 打开 azureus 16:18 <+Complication> 今天早上，我记录到客户端 tunnel（长度 2 +/- 1）的成功率接近 35% 16:18 <+Complication> 目前更低，因为我尝试做了一些修改，最新的一次效果不太好 :D 16:18 <@cervantes> jrandom: 你把问题追到这一步很棒——我们一度开始看起来有点像 freenet 了 :) 16:19 <jrandom> *咳* ;) 16:20 <+fox> <inkeystring> jrandom: 你介意简要描述一下退避机制吗？我目前在为 freenet 0.7 做类似的东西 16:21 <jrandom> inkeystring: 我们在传输层已有退避机制，当传输层过载时减少向某个对等体的传输，但这还不够 16:21 <@cervantes> *咳* 我刚说的是 freenet？我其实是说 tor 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: 新的改动是把该机制上推到更高层，这样当我们的通信层饱和时就会停止尝试构建 tunnel 16:22 <jrandom> （而不是发送更多 tunnel 构建尝试） 16:22 <+fox> <inkeystring> 谢谢——传输层只在丢包时才退避，还是接收端有办法控制流量？ 16:23 * jrandom 记得和 toad 讨论过几次拥塞与路由的影响（在 irc 上以及我以前的 flog 上），不过我不记得有任何净积极的解决方案 :/ 16:23 <jrandom> 接收端可以 NACK（否定确认），我们也为 ECN（显式拥塞通知）留了钩子，但还没必要用上 16:23 <+fox> <inkeystring> 是啊，这个争论在 freenet-dev 上又被提起了 :-) 仍然没有银弹 16:24 <+fox> <inkeystring> 酷，谢谢提供信息 16:24 <+Complication> 他们现在也在用 UDP，对吧？ 16:24 <jrandom> 当前，高度拥塞的节点麻烦不在于逐对等体限速，而在于对等通信的广度 16:24 <+Complication> （作为传输协议） 16:24 <+fox> <inkeystring> 广度 = 对等体数量？ 16:24 <jrandom> 是的 16:25 <jrandom> 随着 tunnel 成功率的提高，对等体不再需要和上百个对等体通信才能构建一个 tunnel 16:25 <jrandom> 因此只需 20-30 个对等体就能应付 16:25 <jrandom> （也就是直接连接的对等体） 16:26 <+fox> <inkeystring> 我猜这对 NAT 打洞、保活等来说是个好消息？ 16:26 <jrandom> 另一方面，拥有 2-300 条活跃的 SSU 连接时，6KBps 的链路会吃不消 16:26 <jrandom> 嗯 16:26 <+fox> <inkeystring> Complication: 是的 16:27 <+fox> <inkeystring> （在 0.7 alpha 版中） 16:27 <+Complication> 啊哈，那他们可能也会面临类似的问题 16:27 <+Complication> 希望有人能找到魔弹 :D 16:27 <jrandom> 不过方式不同。 传输层是个相对容易的问题 16:27 <+fox> <inkeystring> 我想他们可能复用了部分 SSU 代码……至少他们提到过 16:27 <jrandom> （也就是说，已经被研究了 30 多年） 16:28 <jrandom> 但 i2p（以及 freenet）的负载均衡工作在比点到点链路更高的层，需求也不同 16:28 <+fox> <inkeystring> 是的，和路由的交互比较棘手 16:29 <jrandom> 嗯，不过 i2p 的情况更简单（我们不需要找到具有所求数据的特定对等体，只需要任何有能力参与我们 tunnel 的人） 16:30 <+fox> <inkeystring> 所以如果避开一个过载的对等体并不会有效率损失…… 16:30 <+fox> <inkeystring> 而在 freenet 中，绕过过载节点可能会增加路径长度 16:30 <+fox> <inkeystring> 总之抱歉跑题了 16:31 <jrandom> 没关系，不过解释 0.6.1.17 中的改动为何影响我们的拥塞崩溃还是相关的 :) 16:31 <jrandom> 好的，关于 1) 网络状态，还有其他要补充的吗？ 16:32 <+Complication> 嗯，正如之前提到的，在纯 .17 版本上运行时，我观察到带宽和活跃对等体数存在明显的周期性 16:32 <+Complication> 还有一些人似乎也遇到了，不过我不清楚普遍程度如何 16:33 <+Complication> 我一直在想其主要原因，主要从 tunnel 限速的角度，但尚无解法 16:33 <+Complication> 我设法让自己的图看起来更平滑，但代价是整体表现有所下降 16:33 <+Complication> 尝试过类似这样的修改： 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> （这是为了避免它对自身的 tunnel 完全不再进行构建尝试） 16:35 <jrandom> 啊对 16:35 <+Complication> （哦，很自然地，日志级别是乱的，因为我为了测试改过） 16:35 <jrandom> 我们里面有些代码试图稍微打散这种周期性，但显然运行得不太对 16:36 * perv 刚把自己的系统弄挂了 :( 16:36 <+Complication> 不过我做过类似尝试，也尝试降低 tunnel 数量的增长因子 16:36 <perv> reiser4 有撤销删除的办法吗？ 16:36 <jrandom> 基本上，如果我们假装 tunnel（随机地）比实际更早过期，应该会有帮助 16:36 <+Complication> 目前在读 TunnelPool.java 里的大函数 “countHowManyToBuild” :D 16:36 <+Complication> 不过我还没读完 16:37 <jrandom> （不过这显然会提高 tunnel 的构建频率，而在 0.6.1.17 之前这并不合理） 16:37 <+Complication> perv: 有一些办法 16:37 <jrandom> 嗯，把随机化放在那里会很难，Complication，因为我们非常频繁地调用那个函数 16:38 * perv 考虑先救数据然后换到 gentoo 16:38 <jrandom> 我建议可以考虑把成功构建的 tunnel 的过期时间随机化 16:38 <+Complication> perv: 用 reiser 肯定比 ext3 要好 16:38 <+Complication> perv: 不过我也不熟 16:38 <+Complication> jrandom: 确实，这样有时可能会过度构建 16:38 <jrandom> （这样现有的 countHowManyToBuild 会认为它在真正需要之前就需要它们） 16:38 <+Complication> （而且当 tunnel 断掉时，它有时不可避免地会匆忙过度构建） 16:40 <+Complication> 嗯，这是我没考虑过的一种可能…… 16:41 <+Complication> 不管怎样，我也在折腾它，但还没有有用的观察结果 16:42 <jrandom> 好啊，我这边也在做一些调整，也许我们可以把这些放到下一个构建里，看看在目前尚算可用的网络上效果如何 ;) 16:43 <spinky> 是否有统计可以查看 I2P 网络为应用数据增加了多少开销？ 16:43 <jrandom> “overhead” 是个很有争议的词…… ;) 16:43 <jrandom> 我们把它称为匿名的代价 ;) 16:43 <spinky> 呵呵 16:45 <jrandom> （也就是：并不真有。 零拥塞、1+1 跳的理想网络上，终端的应用层有效负载大概能达到 70-80% 的效率） 16:45 <jrandom> （（上次我测的时候）） 16:45 <jrandom> 但那真是实验室条件 16:45 <jrandom> 真实网络要复杂得多 16:47 <spinky> 对，我指的是用于建立 tunnel、密钥、填充等所消耗的额外数据量 16:47 <spinky> ……与传输的应用数据相比 16:47 <jrandom> 取决于消息分帧、拥塞、tunnel 构建成功率等 16:48 <jrandom> 构建一个 2 跳的 tunnel，网络需要承担约 20KB 的数据 16:48 <+Complication> 我有时也想测试一下，主要是为了估算像 BitTorrent 和 I2Phex 这类大规模传输应用的“浪费程度” 16:48 <+Complication> 不过我一直没在我的两个节点间做过干净的测量 16:48 <+Complication> 总有一天我会回头做这个的 16:49 <jrandom> Complication: 用话痨型应用来测挺难的，用 wget 测就简单多了 :) 16:49 <+Complication> 太对了 16:50 <+Complication> 我之前试过的一些方法，谈不上精确 16:54 <jrandom> 好的，如果 1) 没有其他内容，我们滑到 2) I2Phex 16:55 <jrandom> Complication: 最近在忙什么？ :) 16:55 <+Complication> 嗯，昨天的提交修复了某些人遇到的、我那个傻乎乎的首次运行检测器的问题 16:56 <+Complication> 首次运行检测器现在不那么傻了，bar 报告说它似乎开始正常工作了 16:56 <+Complication> 不过，既然 I2Phex 在当前网络条件下似乎已经可以运行， 16:56 <+Complication> 我也会尝试找到那个 rehash 的 bug。 16:57 <+Complication> 只要我能找到的话 16:57 <jrandom> 很好，我知道那个问题困扰你几个月了 16:57 <+Complication> 有趣的是，主线 Phex 可能也有这个问题，我也会尝试定位并阅读他们的相关观察 16:58 <jrandom> 不过很高兴听到启动修复已经加进去了 16:58 <jrandom> 啊，懂了 16:58 <+Complication> =就是这样 16:58 <+Complication> 不过我目前无法确认主线 Phex 是否也有这个问题——我个人在那里从未见过 16:59 <jrandom> （间歇性 bug）—— 16:59 <+Complication> 很难以可控方式重现，因此也难以定位 17:00 <+Complication> 我这边目前大概就这些 17:00 <+Complication> 之后我在想，是否值得限制 I2Phex 同时发起的并行对等体联系尝试的数量 17:01 <jrandom> 嗯，可能值得 17:01 <+Complication> 因为那会在短时间内产生一大堆 NetDB 查询，从 I2P router 的角度看可能不太友好 17:02 <jrandom> 而且与新的 destination 建立联系需要使用 elG 而不是 aes 17:02 <+Complication> 不过我还没为这个目标读或写任何实际代码 17:04 <jrandom> 好，没问题。 也许传说中的 i2phex/phex 合并会自带一个解决方案 :) 17:04 <+Complication> 我这边有关 I2Phex 的消息大致就这些…… 17:04 <jrandom> 很好，谢谢你的更新以及为这些问题所做的努力！ 17:05 <jrandom> 好的，我们跳到 3) ??? 17:05 <jrandom> 还有谁有其他要在会议上提出的？ 17:05 <lsmith> 大家好！我只想称赞开发者们在最新版本中的出色改进，我的总带宽只有 0.9/1.4 KBps，我仍然能连着 irc……这也太酷了 :) 17:05 <+Complication> :D 17:06 <jrandom> 感谢你一路以来的耐心——支持低带宽用户至关重要 17:06 <@cervantes> lsmith: 这真的很不错 17:06 <@cervantes> * 连接重置 17:06 <jrandom> 呵 17:07 <lsmith> :) 17:09 <jrandom> 哦，另一个值得一提的是 zzz 回来了，随他而来的是 stats.i2p :) 17:09 <jrandom> [wewt] 17:11 <+Complication> 一个非常有用的对比数据来源 :) 17:11 <jrandom> 那是肯定的 17:11 <jrandom> 好的，还有谁有别的要在会议上说的吗？ 17:13 <jrandom> 如果没有…… 17:13 <jdot> 我有一两个 baf 之后的问题 17:13 <jrandom> 呵，好吧，那就让 baffer 开始转起来吧 :) 17:13 * jrandom 做好准备…… 17:13 * jrandom 用 *baf* 宣布会议结束