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

13:04 <jrandom> 0) 嗨 13:04 <jrandom> 1) 0.5 13:04 <jrandom> 2) 下一步 13:04 <jrandom> 3) azneti2p 13:04 <jrandom> 4) ??? 13:04 <jrandom> 0) 嗨 13:04 * jrandom 挥手 13:05 <jrandom> 每周状态笔记已发布 @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html 13:05 <jrandom> （是啊，就在会议开始前一两分钟发布的，来考考你的速读吧） 13:05 <+detonate> 我想等它再少点 bug，我再把 Boondock Saints 放上去 13:06 <jrandom> 为什么……那是……那是……那可是侵权啊！ 13:06 <+detonate> Azureus 测试版有些奇怪的新东西 13:06 <+detonate> 分类 13:06 <+detonate> 哈哈 13:06 <+detonate> 一个 DHT tracker 13:06 <+detonate> 赞 13:07 <jrandom> 是啊，看起来很酷，不过在聊 3 之前，咱们先过 1 和 2，行吧？ ;) 13:07 <+detonate> 嗨 13:07 <+detonate> 确实 13:07 <jrandom> 开始 1) 0.5 13:07 <jrandom> 嗯，总之已经发出来了，诸如此类 13:08 <cervantes> 耶！ 13:08 <jrandom> 今晚晚些时候会有一个新修订版，包含一堆更新（当前 CVS head 是 0.5-5，-6 正在一些 router 上测试） 13:09 <jrandom> 进展相当不错，但一路上也碰到了一些怪 bug。 唉，人生如此 13:09 <frosk> 我可以报告，0.5-5 比 -4 友好多了（-4 经常让我参与的 tunnel 数量上千） 13:09 <bla> jrandom: 0.5.0.1 会修复找不到 destinations 的那个问题吗？ 13:09 <jrandom> 啊，那其实更多取决于别人，-0 构建确实会建立数百条 tunnel 13:09 <bla> s/nor/not 13:10 <jrandom> bla：是的，那是 netDb 里的一个 bug 13:10 <bla> jrandom: 太好了！ 13:10 <jrandom> （更具体地说，在 leaseSet 发布中） 13:11 <jrandom> 对，0.5.0.1 修订版也会去掉那个偶尔代理消失的 bug 13:12 <jrandom> 还有一个古怪的内存泄漏我还没定位，会影响到一些用户 13:12 <bla> 那么，总的来说，除了这些 bug，0.5 的网络运行得非常好。耶！ 13:12 <jrandom> 据我所知，它其实只影响到两三个 I2PTunnel 实例 13:12 <Meomia> 自 0.5 起从 0 到 130 条参与的 tunnels，这算是进步的迹象吗？ 13:13 <jrandom> w3wt 13:13 <jrandom> Meomia：切，我这边超过 5000 条 tunnels ;) 13:13 <jrandom> 不过 dm 的确帮忙找到了 exploratory pool 代码里的一个 bug，所以我们会更频繁地在“随机”的节点上构建 tunnels 13:14 <jrandom> （好耶） 13:14 <Meomia> 好 13:14 <bla> jrandom: 这是否也意味着，现在不同于 0.4，任何节点都有可能在某个时刻成为你的入站网关？ 13:14 <jrandom> 是的，对 exploratory tunnels 来说 13:15 <jrandom> client tunnels 只会使用“fast”层里的节点 13:15 <bla> bla: 好的。client tunnels 只用快速节点这一点很好：否则就会出现我们之前讨论过的匿名性问题 13:16 <jrandom> 而且不这么做性能会很糟糕 ;) 13:17 <jrandom> 事实上，这就带到了 2) 下一步 13:18 <jrandom> 0.5 系列剩下的重点，是一组用于对 tunnel 所用节点进行排序和/或过滤的策略 13:18 <godmode0> jrandom 可以在 i2p 里用 NNTP 吗？ 13:18 <jrandom> godmode0：i2p 上有两个 NNTP 服务器，没错。 去论坛看看 13:19 <godmode0> jrandom 好的，我正在测试 13:19 <godmode0> 我也可以搭建我的服务器吗？ 13:20 <jrandom> godmode0：我们现在在开会，不过是的，你可以运行一个服务器 13:20 <godmode0> jrandom 好的，抱歉 13:20 <jrandom> 不客气 13:20 <jrandom> 提出的这些策略基本上是为了提升匿名性，但我们也可以在其中平衡其他一些目标 13:21 <jrandom> 也许我们能像 bla 建议的那样，把一些 AS（自治系统）路径纳入选择方式中 13:22 <jrandom> 那既可以提升（司法辖区层面的）匿名性；如果尽量待在同一个 AS（或两个）内，也可以提升性能 13:22 <bla> jrandom: 这基本上与 Tor 的作者的一篇论文有关: http://theland.i2p/files/routing-zones.pdf 13:22 <jrandom> 嗯 13:23 <jrandom> 大家可以使用很多不同的策略，尝试新的也应该很容易 13:24 <jrandom> 我们不会花几个月去实现我们能想到的所有东西，而是提供大多数人所需的基础。 任何人想添加新的都非常欢迎把它们接进来 13:25 <jrandom> 总之，一旦基础就位，我们就会转向专注于 0.6 的 UDP 传输 13:26 <jrandom> 关于 2) 下一步，我就这些了，还有人有评论/问题/顾虑吗？ 13:26 <bla> 之前开始研究 I2P 的人是谁来着？ 13:26 <bla> 最近好像没怎么听到他们的消息。 13:27 <bla> s/into I2P/into UDP/ 13:27 <bla> 抱歉 13:27 <jrandom> 啊，mule 一直生病，不过我觉得 detonate 在推进 13:28 <jrandom> detonate：有新进展吗？ 13:29 <jrandom> 或者没有也说不定 ;) 13:30 <jrandom> 好，进入 3) azneti2p 13:30 <+detonate> 抱歉 13:30 <+detonate> 我在推进 13:30 <+detonate> 我还需要完成重组那一侧的工作 13:31 <+detonate> 至于把数据分包并有序地发过去，那部分已经能工作了 13:31 <+detonate> 继续 3) 13:31 <jrandom> 太棒了 13:31 <godmode0> 抱歉回到第 2) 步，i2p 对攻击有没有什么问题？ 13:31 <bla> detonate：酷！能在论坛上同步给大家吗？ 13:32 <+detonate> bla：当然 13:32 <tracker> 关于 azneti2p，看这里: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 下载似乎可以，但做种不行。 13:32 <jrandom> godmode0：不同的排序策略应当能让用户自行选择对 predecessor attacks（前驱攻击）的抵抗程度 13:33 <microsoft> 谁在运营 i2p.net，应该在页面上多加点“企业级解决方案”这种流行词。 13:33 <+detonate> 还需要有人确认那个新的 DHT tracker 相对于 Azureus 插件没有出问题 13:33 <tracker> 我本地测试似乎证实了，我用 Azureus 能下载，但不能做种。 13:34 <jrandom> 嗯，好，太好了，tracker，谢谢——我知道他们昨晚更新了些东西并发布了 b34，但看起来还有更多要做 13:34 <jrandom> detonate：好点子 13:35 <tracker> 说得对 detonate，我把 DHT 关了，因为 Azureus 开着 DHT 的话几个小时后就会挂，CPU 100%。 13:35 * jrandom 想再强调一下，azneti2p 插件还处在相当早期的测试阶段，Azureus 的匿名性影响尚未完全审计过 13:36 <jrandom> 我相信他们很乐意让大家测试，但需要匿名性的用户可能要谨慎些 13:36 <tracker> 另一方面，i2p-bt 运行得非常好。只是它不会关闭 tunnels，但我觉得这不算太糟。 13:37 <jrandom> 哦，tracker，你那边还会这样吗？ 我没能复现。 13:37 <jrandom> 你用的是 0.1.7 修订版，对吧？ 13:37 <tracker> 是的。 13:38 <jrandom> 好，太好了，如果你那边总会发生，会议之后我想跟你多聊聊，帮忙找出原因 13:39 <tracker> 也许和用 XP 跑而不是 Linux 或 Unix 有关。用 Azureus 关闭 tunnel 是可以的，所以我猜是 I2P-BT 相关。 13:39 <jrandom> 嗯对，i2p-bt 用的是 SAM，而 Azureus 直接用的是 i2p 的 SDK 13:40 <tracker> 顺便说一句，我在论坛上给你发了个 bug 报告。I2P 最新的 CVS 构建里 timestamper 会死掉。 13:40 <jrandom> 啊好，谢谢，今天还没看那边的私信 13:41 <jrandom> 发生在 -5 还是 -4？ 还是更早？ 13:42 <jrandom> 啊，-4。 好，知道了 13:42 <jrandom> 谢谢，我会在 0.5.0.1 修掉它 13:42 <jrandom> 好，关于 3) azneti2p 还有别的吗？ 13:43 <tracker> 在 -5 上也会发生 13:43 <jrandom> 你明确配置了 sntp 服务器，对吧？ 13:44 <tracker> 是的。我们国家的那两个。 13:44 <jrandom> 我刚看了源码，如果并发服务器数量（默认=3）大于你配置的服务器数量（新默认也是 3），就会抛异常 13:44 <jrandom> 好，这很好修，把它对服务器数量取模就行 13:45 <jrandom> 好，如果 azneti2p 没别的了，继续到传统的 4) ??? 13:46 <jrandom> 还有谁要在会上提点什么？ 13:46 <tracker> 好。我刚在论坛上把关闭 i2p-bt 时 router 的日志错误发给你了。 13:47 <jrandom> 好的，谢谢 13:47 <cervantes> 没别的要说的：0.5 的发布干得漂亮，等把 bug 都消灭了，看来会非常给力 13:48 <tracker> 是的，最新的 CVS 构建在我这儿表现真的不错。 13:48 <jrandom> 谢谢，有你们和其他 0.5-pre 测试者的帮助，我们修掉了好多问题 13:49 <jrandom> 性能比我预期的要好，不过吞吐量仍不如以前高。 还有很多可优化之处 13:49 <cervantes> 奇怪的是预发行版对我来说更稳定……不过我当时是在另一台机器上跑的 ;-) 13:49 <jrandom> （还有这些该死的 bug，要把可靠性拉回它该有的水平） 13:50 <jrandom> 呵，是啊，不过 -pre 网络只有 5-7 个 routers，而且都在非常非常快的连接上，可靠性爆表 13:50 <cervantes> :) 13:51 <cervantes> 那把我加入 0.6 的预测试吧 :) 13:51 <jrandom> 呵 13:51 <tracker> 也许我该参加下一个预网络。提供一个非常不稳定且很慢的连接 ;)。 13:51 <jrandom> 我希望 0.6 的迁移会更容易一些，因为我们只需把新的 router 地址加到 routerInfo（UDP 地址）里 13:51 <jrandom> 呵，说的好 13:51 <cervantes> 我可以把我 1TB 的文件分享上线…… 13:52 <jrandom> 我们肯定需要大量 0.6 测试的帮助，覆盖各种各样的网络环境 13:52 <hobbs> ssh 的‘~C’命令很妙 13:52 <laberhorst> 这会是另一个不兼容的步骤吗？ 13:53 <Myo9> 有人知道哪些 NNTP 服务器在线吗？ 13:53 <jrandom> laberhorst：不会，0.6 将向后兼容 13:53 <jrandom> Myo9：不清楚，它们可能在线，只是被 0.5-0 的 bug 咬到了 13:54 <jrandom> 0.5.0.1 修订版应该会修复很多问题，一发布就强烈建议升级 13:54 <laberhorst> 那就构建个 0.6 测试版给测试者用吧 13:54 <cervantes> 我们可以让 BT 流量只使用过期的 routers……这会鼓励大家升级 ;-) 13:54 <laberhorst> 那明天就是大型升级派对了 13:54 <jrandom> 准备好后会在论坛和列表上发公告 13:54 <jrandom> 对的，laberhorst 13:54 <jrandom> 呵，cervantes ;) 13:55 <laberhorst> *迫不及待要帮你们测试* 13:55 <jrandom> 在 0.5 上 BT 性能相当不错，我在 trackers 上看到很多大文件成功传输了 13:55 <laberhorst> 上传速率: 8.85 kB/s 13:55 <jrandom> （而且 IRC 没像之前那样受影响，除了我们在 duck 的 tunnel 上遇到的问题） 13:55 <tracker> 取决于你说的“大”是什么尺度 ;) 13:56 <jrandom> tracker：我想到的是一个 874MB 的文件，有很多成功下载 ;) 13:56 <jrandom> 但确实，对某些人来说那很小 13:56 <laberhorst> 只是经典的小黄片 13:56 <laberhorst> 我猜是 ;-) 13:57 <laberhorst> 希望从明天起，我的 router 不会再参与>3000 条 tunnels 13:57 <tracker> 好吧，那算大。 13:57 <laberhorst> 或者，如果是这样，那网络确实很大 13:57 <jrandom> 呵 laberhorst 13:58 <jrandom> 好，这次会议还有别的事吗？ 13:58 <laberhorst> 顺便问下，参与>3000 是否就等同于在 i2p 里是一个连接很快、很可靠的 router？ 13:58 <+detonate> 我今晚看完 House 就把 boondock saints 放上去 :) 13:59 <+detonate> 那会是足足 4.1GB :) 13:59 * laberhorst 只是想感谢开发者快速消灭 bug 13:59 <+detonate> 看起来需求很大 13:59 <laberhorst> 哦，这里也有一些 DVD 镜像 13:59 <hobbs> detonate：哦，对。House。 :) 13:59 <tracker> cervantes，你已经升级到 phpBB 2.0.12 了吗 13:59 <laberhorst> 不过等 0.5.0.1 出来再说 14:00 <+detonate> 也该好好折腾一下 0.5.0.1 14:00 <+detonate> 嗯 14:00 <+detonate> 我就是这么打算的 14:00 <jrandom> 当然，只有已经合法拥有这些文件副本的人才应该下载。 那只是为了测试 14:00 <jrandom> *咳咳* 14:00 <tracker> 笑翻 14:01 * jrandom 记下 mpaa.i2p 14:01 <+detonate> 呵 14:01 <laberhorst> 哦，我可以制作 debian、fedora、suse 的 ISO 镜像，还有我拍的照片，等等…… 14:01 <laberhorst> 所以有很多合法素材 14:01 <laberhorst> 如果你只是想测试，/dev/random 非常非常大 14:01 <Ragnarok> 也不总是 14:02 <laberhorst> 顺便说下，寂寞的周末可以这样玩：cat /dev/random | grep linux :-) 14:02 <jrandom> 呵 14:02 <frosk> /dev/random 老是读空，我更喜欢 /dev/urandom :) 14:02 <frosk> 或者那个全新改良的 /dev/jrandom 14:02 <jrandom> 不行，那东西老是 core dump 14:03 <jrandom> 而且需要每晚休息 14:03 <Ragnarok> 为 /dev/random 生成熵的最佳方式是什么？ 14:03 <laberhorst> 我们真的该建个“给 jrandom 买几杯啤酒”的基金 14:03 <frosk> 叫休息也好，叫收集熵也行 :) 14:03 <hobbs> Ragnarok：取决于你的具体意思。搞个硬件 RNG 大概是“最好”的办法 :) 14:03 <jrandom> Ragnarok：取决于你的操作系统（以及你有没有硬件 ;)） 14:04 <tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 一直都很“不错” ;) 14:04 <jrandom> 我们其实会在接下来的某个构建里捆绑一个 Fortuna 实现，并且需要去挖掘各种熵源 14:04 <Ragnarok> 没有硬件 :P 14:04 <susi23> . o O ( 我以为用 i2p 的人都知道为什么不该用 /dev/urandom ) 14:05 <cervantes> tracker：2.0.12 修的那些安全漏洞，我的 mod_rocinante 无意间也修住了，所以我还懒得升级 14:05 <hobbs> susi23：要是只是恶作剧，我觉得没关系 ;) 14:05 <ant> <Nolar> 这里谁在做 Python 版的 BT 移植？ 14:05 <jrandom> Nolar：那是 duck 14:06 * duck 吹口哨 14:06 <ant> <Nolar> duck：为什么你们把请求的块大小改成了 128K？ 14:06 <susi23> . o O ( 下一个会建议: while true; do echo $RANDOM>> largefile; done ) 14:06 <ant> <Nolar> 那就是 Azureus 不能给你做种的原因 14:06 <tracker> cervantes：好 14:06 <ant> <Nolar> 我们会阻止> 64K 的请求 14:06 <laberhorst> 天哪，我需要更多 mp3 14:06 <frosk> susi23：在闲暇的夜晚 grep 一下 linux 的话，/dev/urandom 就挺好 :) 14:07 <jrandom> 啊，一直都是这样吗？据我回忆 i2p-bt 已经用 128K 一阵子了 14:08 <ant> <Nolar> 是的，从一开始就这样 :) 14:08 <ant> <Nolar> 有什么使用 128 的理由吗？ 14:08 <ant> * duck 在翻 CVS 日志 14:08 <jrandom> 这样能把管线填满，i2p 有些延迟 ;) 14:08 <jrandom> 用 32KB 的话，本质上就是固定窗口大小为 1 14:09 <jrandom> 因此每条消息都会等待一个 ACK，而 128KB 允许在 RTT 里飞 4 条消息 14:09 <@duck> 对，根据 BT 规范，最大允许的 slice 大小 14:09 <ant> <Nolar> 嗯，有两种处理方式： 1）我们这边把上限提高到 128K；或 2）你们就简单地把请求管线化多发几个 14:09 <cervantes> i2pbt 比以前更灵敏了一点……或许你们可以把它调小…… 14:10 <@duck> schni, schna, schnappi 14:10 <ant> <Nolar> 所以，比如不要发一个 128K 的请求，改成发两个 64K 的 14:10 <hobbs> duck：哈哈……那玩意已经风靡全球了。 14:10 <@duck> 为什么你们要拦 128K？ 14:11 <cervantes> 打个哆嗦，欧陆流行 14:11 <laberhorst> duck：请安静，否则我就击落你！ 14:11 <tracker> 有时候我后悔几年前学了德语…… 14:11 <laberhorst> 不要欧陆流行，真的不是 POP 14:11 * cervantes 命令英国在这种歌登上榜单前就把边界守住 14:11 <laberhorst> tracker：别在意，没事的 14:12 <ant> <duck> 现在是 (2^17)-13 14:12 <ant> <Nolar> duck：嗯，这个上限已经存在一段时间了，但一个充分的理由是 128K 的块上传需要一段时间……16KB（我们的默认值）允许更细粒度的请求控制 14:12 <ant> <duck> 13 字节是 BitTorrent 命令长度 14:12 <ant> <duck> 改成 (2^16)-13 也没问题 14:12 <laberhorst> 有些音乐真的很可笑，但真正的工业音乐，呃，不行 14:13 <ant> <duck> 或者回到默认？ 14:13 <jrandom> 把它降到 64KB 似乎最简单（现在是个 CLI 参数吗？） 14:13 <ant> <duck> --download_slice_size 14:14 <ant> <Nolar> 嗯，我的问题是：你们有没有非用 128K 块不可的充分理由？在我看来有点大，尤其在 i2p 里 14:14 <ant> <Nolar> 为什么不把多个更小的请求做成管线呢？ 14:14 <ant> <duck> 我没有理由。 14:14 <tracker> laberhorst：它的全名好像是“ZDF Theater”。他们说自己播的是高水准文化节目。我真心希望他们播的不是德国文化所能提供的最好水平 ;) 14:15 <ant> <Nolar> 大块的一个问题是，一旦我 choke 了你，我仍然得把那个 128K 块发完 14:15 <jrandom> 我不记得原生 BT 是否会做管线，但应该足够简单（尤其是反正不是我来做 ;)） 14:15 <ant> <Nolar> 这可能要花点时间 14:15 <laberhorst> tracker：VIVA 只有“硬摇滚”时段有意思，其他时间“请忽略”，至于 Theater，我不清楚 14:15 <jrandom> 在 i2p 里，128KB 其实并不算大，因为固有的延迟是以秒计的 14:15 <ant> <Nolar> 这会干扰 choke/unchoke 的节奏 14:16 <@duck> jrandom：为了塞进一个 SAM 消息里，现在还需要减去 BitTorrent 的 13 字节开销吗？ 14:16 <jrandom> duck：不用了，因为流式库已经会进一步把它拆成 16KB 的消息，所以就用 64KB 吧 14:17 <@duck> 好，那就是 2**16 14:17 <jrandom> （然后 tunnels 会把那些 16KB 的消息再切成 996 字节的片段……） 14:17 <ant> <Nolar> 128K 的问题是，如果我上传速度是 12 k/s，那么发完那一块要 10 多秒 14:18 <cervantes> 哇，那几乎和 IRC 的延迟一样长…… 14:18 <jrandom> 也就是 1-10 个 RTT（而在普通网络上是 10-500） 14:18 <+detonate> 我本来打算用 512K 的块 14:18 <ant> <Nolar> 你也可以试试把 16KB 的块做成管线 14:18 <jrandom> 呵 14:18 <+detonate> 所以 64 更推荐？ 14:19 <ant> <Nolar> 据我所知，所有 BT 客户端都用 16KB 块 14:19 <ant> <duck> 已在 CVS 修复； 14:19 <jrandom> 太棒了，谢谢 duck！（也谢谢 Nolar！） 14:19 <ant> <duck> 预计会跟一些 SAM I2CP 的调优一起出现在 0.1.8 版中 14:19 <tracker> laberhorst：它的全名好像是“ZDF Theater”。他们说自己播的是高水准文化节目。我真心希望他们播的不是德国文化所能提供的最好水平 ;) 14:19 <jrandom> 好，呵，我刚想起来我们还在开会 14:19 <jrandom> 还有谁有会议议题？ 14:20 <ant> <Nolar> 所以如果我们想要 128K 的块，就并发发出 8 个请求 14:20 <susi23> . o O ( 那剩下的 448 字节丢掉？ ) 14:20 <jrandom> 对对 14:20 <laberhorst> tracker：哦，那是个小众频道……Arte 或 3sat 更有意思 14:20 <laberhorst> 而且 Arte 是德/法合办的 :-) 14:20 <ant> <Nolar> 如果上传端能满足这样的请求，整整 128K 都应该被推入 i2p 的管道流里 14:20 <jrandom> 好 14:21 <cervantes> . o O ( 纳闷他为什么能听到 susi 想的每件事 ) 14:21 <ant> <Nolar> 所以，值得实验一下 16KB、32KB、64KB 的块大小 14:21 <jrandom> 嗯 14:21 <jrandom> 只要做了管线，i2p 不在乎 14:21 <ant> <Nolar> 太好了 14:22 <jrandom> 不过 16KB 而不做管线的话速度相当差，或者至少以前是这样 14:22 <tracker> laberhorst：好，我这几天试试能不能收到 Arte…… 14:22 <ant> <duck> 我建议把这种微调留到 0.2 14:22 <ant> <duck> 因为它会包含 BitTorrent 3.9.1 的改进 14:22 <jrandom> 是啊，DTSTTCPW 14:22 <susi23> . o O ( 哦，那很简单……人们太容易预测了…… ) 14:23 <ant> <duck> 这可能会完全重构网络代码 14:23 <cervantes> http://www.gavelstore.com 14:24 <jrandom> 好，我想目前就这些，大家几个小时后来查看一下列表和网站，0.5.0.1 修订版很快就会发布 14:24 <ant> <Nolar> 是啊，我能理解单个 16KB 请求会很慢 14:24 * jrandom 下单买了个木槌 14:24 * jrandom *baf* 宣布会议结束