I2P 开发者会议 - 2005年3月22日

13:01 <@jrandom> 0) 嗨 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) 批处理 13:01 <@jrandom> 3) 更新 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) 嗨 13:01 * jrandom 挥手 13:01 <@jrandom> 刚刚发布的每周状态说明在这里：http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> 嗨 13:02 <+cervantes> 哈喽 13:02 <@jrandom> 直接跳到 1) 0.5.0.3 13:02 <@jrandom> 该版本几天前发布，反馈总体正面 13:02 <+cervantes> jrandom：当蓝色会跳舞的矮人爬到你显示器上时告诉我们，我们就提前结束会议 13:03 <@jrandom> 呵呵 cervantes 13:03 <@jrandom> （感谢 Bob 提供可编辑的会议日志；） 13:04 <@jrandom> 关于 0.5.0.3，我没有太多要补充的，邮件里已经说得差不多了 13:04 <@jrandom> 有人对此有任何评论/问题/顾虑吗？ 13:04 <bla> jrandom: 有关于 fast-peers-selection 代码的任何新测量数据吗？ 13:05 <@jrandom> 啊，我就知道 0.5.0.3 里还有我漏掉的东西；） 13:06 <@jrandom> 我还没有硬核指标，但从经验看，快速对等节点选择找到了我明确知道“快”的节点（比如同一台机器上的 routers 等） 13:07 <bla> jrandom: 有时，eepsites 仍需重试多次才能找到可用的优质 tunnel 13:07 <@jrandom> 也偶尔收到吞吐率相当不错的报告（在 10–20KBps 范围），不过还不常见（我们依然把参数调得比较保守） 13:08 <+ant> <Connelly> 哎呀，正在开会 13:09 <@jrandom> 嗯，是的，我发现可靠性仍未达到应有水平。不过多次重试并不是解决方案——如果重试 1 次后站点还没打开，请等 5–10 分钟再试 13:09 <@jrandom> 不过我在网络上传输层的延迟尖峰出现得不算少 13:10 <@jrandom> 比如，通过一个套接字把 1–2KB 的消息刷出就要花 5–20+ 秒 13:10 <@jrandom> 再加上一条 5 跳的路径（2 跳的 tunnels），就容易出问题 13:11 <@jrandom> 这其实也是推动批处理代码的原因之一——减少需要发送的消息数量 13:13 <@jrandom> 好的，关于 0.5.0.3 还有其他问题/评论/顾虑吗？ 13:13 <bla> jrandom: 看起来不错。我会在下一个“部分”里再多问一些 13:14 <@jrandom> w3rd，好，我们可以继续到 2) 批处理 13:15 <@jrandom> 邮件和我的博客（jrandom.dev.i2p</spam>）应该说明了计划的基本内容 13:15 <@jrandom> 而且，说真的，这些都相当基础 13:15 <@jrandom> 我们现在的预处理器是最容易实现的那种（类名：TrivialPreprocessor）；） 13:16 <@jrandom> 新的预处理器提供了可调的批处理频率参数，并在各个 tunnel 池内提供出站 tunnel 亲和性（例如在 500ms 内尽量为后续请求选择同一个出站 tunnel，以便优化批处理） 13:17 <@jrandom> 关于这部分我大概就这些补充——有任何问题/评论/顾虑吗？ 13:18 <bla> 这是否要求所有参与的节点都运行新的预处理器，还是可以让 Trivial/NewOne 混合共存？ 13:18 <+Ragnarok> 这会给时延增加 0.5 秒，对吧？ 13:19 <@jrandom> bla：不会，这个预处理器只用于 tunnel 网关，由该网关自行决定如何或是否进行批处理 13:20 <@jrandom> Ragnarok：一般不会——第 1 条消息可能会被延迟最多 0.5 秒，但第 2–15 条消息会比原先快得多。此外这是个简单的阈值机制——一旦达到一个完整 tunnel 消息的大小，就会立刻刷出 13:20 <+Ragnarok> 酷 13:20 <+Ragnarok> 能省下多少开销？ 13:21 <@jrandom> 相当可观；） 13:21 <+Ragnarok> “相当可观”听起来不错，虽然有点含糊 :P 13:21 <@jrandom> 看看你的 http://localhost:7657/oldstats.jsp#tunnel.smallFragments 13:21 <@jrandom> 把它跟 #tunnel.fullFragments 比较一下 13:22 <bla> jrandom: 这只涉及 endpoint->IB-gateway 的通信吗？ 13:22 <@jrandom> 启用批处理后，full 与 small 的比率会上升，small 中的填充字节数会下降 13:23 <@jrandom> bla：嗯，它涉及所有 tunnel 网关，无论入站还是出站 13:24 <mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events 13:24 <bla> jrandom: ok 13:24 <mihi> 碎片数量会出现小数吗？ 13:24 <@jrandom> full：1.00（共 807,077.00 次事件） small：746.80（共 692,682.00 次事件） 13:25 <@jrandom> 呵呵 mihi 13:25 <@jrandom> （small：746 的意思是，在那 69.2 万条消息中，每条 996 字节里有 746 字节是“浪费”的填充字节！） 13:26 <@jrandom> 呃，也不算完全浪费——它们起到了应有作用 13:26 <+detonate> 不管怎样都是不必要的开销 13:27 <@jrandom> 是的，很多都可以通过批处理预处理器去掉 13:28 <@jrandom> 不幸的是，它不会打包进下一个发行版 13:28 <@jrandom> 但会包含在 0.5.0.6 版（或许 0.5.1）里 13:28 <@jrandom> 呃，是 0.5.0.5，或者 0.5.1 13:28 * jrandom 被这些数字搞糊涂了 13:29 <bla> jrandom: 为什么不能？ 13:29 <+cervantes> 大麻和药片……该死 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla：0.5.0.3（及更早版本）里有个 bug，碎片化消息处理器会导致同一个 tunnel 消息里的后续分片被丢弃 13:31 <@jrandom> 如果直接上线批处理预处理器，会导致大量消息丢失 13:31 <@jrandom> 别担心，我们还有其他好东西，所以即将到来的 0.5.0.4 绝不会无聊；） 13:31 <bla> jrandom: 啊，原来如此 13:32 <bla> jrandom: 啊，所以这就是为什么要等 0.5.0.4 成为主流之后再做这个……明白了。谢谢。 13:33 <@jrandom> 是啊，要是分片处理器能搞定就好了。总体上它是能处理的，只是释放字节缓冲得太早，把后续分片清零了（糟糕） 13:33 <@jrandom> 好的，关于第 2 点还有别的吗，或者我们转到 3) 更新？ 13:35 <@jrandom> 好的，正如状态说明里提到的（并且我们也在不同场合讨论了一阵），我们将添加一些简单且安全的更新功能，用户无需去网站、看邮件列表，或读频道主题 :) 13:36 <+detonate> 酷 13:36 <@jrandom> smeghead 已经写了一些代码来帮助流程自动化并提升安全性，并与 cervantes 合作，使其既能集成 fire2pe，也能对接常规的 routerconsole 13:37 <@jrandom> 邮件里列出了将要提供内容的总体描述，其中大部分已经可用，不过还有少数部分尚未完全敲定 13:37 <@jrandom> 不同于批处理，这个会在下一个版本里提供，不过直到 0.5.0.5（需要更新的时候）大家才会真正用得上 13:39 <+Ragnarok> 那么……5.0.4 会有什么酷东西？ 13:42 <@jrandom> 更新代码还带来了拉取公告数据的能力，比如能在 router 控制台顶部显示一小段新闻。此外，作为更新代码的一部分，我们实现了一个新的可靠下载组件，既可以直连，也可以通过 eepproxy 工作，过程中会自动重试并断点续传。或许将来会基于它构建一些相关功能，但不作保证 13:42 <+Ragnarok> 不错 13:43 <@jrandom> 好的，关于 3) 更新，大家还有其他问题/评论/顾虑吗？ 13:45 <@jrandom> 如果没有，我们继续 4) ??? 13:45 <@jrandom> 还有其他想提的吗？ 我肯定漏掉了一些东西 13:45 <+detonate> i2p 能在 OpenBSD 3.7 的 Sun JVM 上运行是已知的 :) 13:45 <@jrandom> 好极了！ 13:47 <bla> UDP 传输的进展如何？ 13:48 <+detonate> udp 可能会很麻烦，我觉得不如偷 bt 的流水线代码来改改；） 13:48 <@jrandom> 咳咳 13:49 <@jrandom> 我预期问题不大，但确实有不少活儿要干 13:49 <@jrandom> 队列策略如何运作，以及进入队列时的带宽限速（bw throttling）会很有意思 13:50 <bla> 前期工作是谁在做？ 13:50 <@jrandom> bla：detonate 和 mule 13:50 <+detonate> 是啊……不过我这一个月左右一直在偷懒 13:50 <bla> detonate: 我猜你在开玩笑吧，关于 BT 那个说法？ 13:51 <+detonate> 我半认真 13:51 <+detonate> 至少可以把传输层的线程数减少一半 13:51 * jrandom 朝 detonate 泼了一桶泥 13:51 <jdot> 哇哦。 我的 router 现在跑在我的独立服务器上了，不再用我那渣渣的有线连接。 13:51 <@jrandom> 给力 jdot 13:52 <@jrandom> 传输层与所有对等体通信只需 3–5 个线程就能搞定 13:52 <bla> detonate: 但当网络变大时（> 几百个节点），减半还是不够的 13:52 <jdot> 可支配带宽有 1000GB 13:53 <jdot> 不巧的是，j.i2p 和 chat.i2p 在我迁移期间还会再停几个小时 13:53 <duck> detonate: addressbook 也停了吗？ 13:53 <+detonate> 是的，也停了 13:54 <+detonate> 唯一没停的是单文件的 profile 存储，我本来打算今天晚些时候把它搞起来 13:54 <@jrandom> w3rd 13:54 <+detonate> 这样 i2p 就不会把硬盘严重碎片化 13:54 <jdot> jrandom: 就带宽（BW）限制而言，它们是平均值吗？ 13:54 <+frosk> 现代文件系统不会碎片化的，傻瓜 13:55 <+detonate> NTFS 会 13:55 <@jrandom> jdot：带宽限制是严格的 token bucket（令牌桶） 13:55 <@jrandom> jdot：如果你设置了突发持续时间，系统会按这个时长来做平均 13:56 <@jrandom> （嗯，2 倍的突发时长 == 周期） 13:56 <@jrandom> （（差不多）） 13:56 <jdot> 嗯…… 我有 1000GB，想让 i2p 每月最多用到 800GB.... 13:56 <+ant> <mihi> detonate: NTFS 会把很小的文件存到 MFT 里，这意味着几乎不会碎片化 13:57 <jdot> 而且我不在乎突发能到多高 13:57 <+detonate> 好吧，当你运行碎片整理时，它要花 10 分钟搬动所有 6000 个 profiles……所以它们肯定会碎片化 13:58 <@jrandom> jdot：嗯，800GB 可能已经超过它本来想推的量了，所以大概可以不设限；） 13:58 <@jrandom> 另一方面，如果你能描述一下你想要实现的策略，我们也许可以支持 13:58 <jdot> jrandom: 我先这么做，看看效果如何 13:58 <bla> detonate: 据我记得，NTFS 是日志型文件系统。所以即使是单体文件，如果你以小块方式写入，也会产生碎片 13:58 <+detonate> 所有东西都是一次性写入的 13:59 <+detonate> 也会一次性读取 13:59 <bla> detonate: 好的，明白了。 13:59 <jdot> jrandom: 那就等等看这是否真会成为问题。 13:59 <bla> detonate: 那干得不错！ 13:59 <+detonate> 我很想知道在不设上限的情况下，实际会用掉多少带宽 14:00 <+detonate> 在一条不错的连接上 14:00 <jdot> 我也很感兴趣！ 14:00 <@jrandom> 我的托管 router 都是不限速运行，不过受 CPU 限制 14:00 <+Ragnarok> 能用一个大号的桶把它按一个月平均吗？ 14:00 <jdot> jrandom: CPU 受限？ 什么 CPU？ 14:01 <@jrandom> 4d 传输 3.04GB/2.73GB 14:01 <+detonate> 嗯，本以为会更少 14:01 <@jrandom> jdot：之所以受 CPU 限制，是因为我在上面跑了 3 个 router，加上其他几个 JVM，有时还要做性能剖析 14:01 <+detonate> 肯定是那些 bt 人 14:01 <+detonate> 等批处理上线后，看看会有什么变化应该很有趣 14:02 <@jrandom> detonate：有些流量也是我在它自己之间传 50MB 的文件；） 14:02 <+detonate> 呵 14:02 <jdot> 啊，好。 那就看看这套系统表现如何。 它是 AMD XP 2400，512MB 内存，10Mbit 连接 14:02 <@jrandom> Ragnarok：token bucket 其实不是那样工作的 14:02 <@jrandom> jdot：word，嗯，这台是 P4 1.6，记得没错的话 14:03 <@jrandom> Ragnarok：在 token bucket 里，每（比如）一秒会按设定速率往里加一些令牌。如果桶满了（大小 = 突发时长），新加的令牌会被丢弃 14:04 <@jrandom> 当你要传数据时，需要先拿到足够的令牌 14:04 <@jrandom> （1 个令牌 = 1 字节） 14:04 <+Ragnarok> 我知道它是怎么工作的……如果把桶做得非常大会怎样？ 14:05 <+detonate> 那你就永远不会停止发送数据 14:05 <+detonate> 如果它大小是无限的 14:05 <+detonate> 呃，而且桶里填满了令牌 14:05 <@jrandom> 如果桶真的很大，在低使用率之后可能会以不受限的速率突发发送 14:06 <@jrandom> 不过在某些情况下也许正是你想要的 14:07 <@jrandom> 问题在于，你不能把 token bucket 就设为 800GB，因为那并不能限制总传输量 14:08 <+detonate> 你需要一个字段能设置每秒的令牌数，然后把每月带宽用量除以秒数就行了 14:08 <+detonate> :) 14:10 <@jrandom> 那等同于把速率按月平均设定，这会很不均衡。不过，总之有很多可选方案——如果有人有当前设置无法满足的需求，请联系我们 14:10 <+Ragnarok> 但是如果把速率设为你想要的平均值……比如我这里 308 kB/s，然后把桶（bitbucket）设得很大……为什么不行？ 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> 嗯，你可以设置成在 60 秒的突发周期内，从不发送超过 800GB/44000 的数据 14:12 <+detonate> 44000 大约是一个月的分钟数 14:13 <@jrandom> 桶大小/突发时长描述的是在不受限情况下我们会发送多少。而大多数人确实希望有约束，这样 router 才不会在清空桶的时候（之类的情况）连续 5 分钟吞掉 10Mbps 14:14 <@jrandom> 也可以在从桶里取令牌的环节再加一道限速（然后那道限速也有自己的 token bucket，而那个桶又有自己的限速，等等） 14:16 <+Ragnarok> 我以为只有在带宽没被用满时才会往桶里加令牌 14:16 <@jrandom> 令牌是以恒定速率加入桶里的（比如每秒 64k 个令牌） 14:17 <@jrandom> 任何需要带宽的都会先向桶申请 14:18 <+Ragnarok> 啊……好 14:19 <@jrandom> 好的，很棒。还有谁想在会上提点什么？ 14:21 <@jrandom> 如果没有的话，就这样 14:21 * jrandom 做好准备 14:21 * jrandom *baf* 地宣布会议结束