I2P 开发者会议 - 2004年12月28日

13:06 <@jrandom> 0) 嗨 13:06 <@jrandom> 1) 0.4.2.5 13:06 <@jrandom> 2) 0.5 13:06 <@jrandom> 3) ??? 13:06 <@jrandom> 0) 嗨 13:06 * jrandom 挥手 13:06 <+postman> *挥手* 13:06 <ant> <jnymo> 你好 13:06 <@jrandom> 简要状态说明已发布在 @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html 13:07 <@jrandom> 跳到 1) 0.4.2.5 13:07 <@jrandom> 如前所述，基本都在正常工作 13:08 <+postman> 是的，相当令人印象深刻 13:08 <+postman> 我的系统上完全没有再出现租约超时（lease timeout）了 13:08 <@jrandom> 很多人和你一样，jnymo，看到 0 条参与的 tunnels，这主要是因为效率提升和对等体选择更好了（我们现在知道要去吸 postman 机器的带宽了 ;) 13:08 <ant> <jnymo> 我也是 13:08 <@jrandom> 不错 13:08 <ant> <jnymo> 而且 eepsites 很快 13:09 <+postman> :) 13:09 <ant> <jnymo> 谢谢 postman :) 13:09 <+postman> 总带宽是 29kb / 30.1kb/s 13:09 <frosk> 大家感觉被爱少了，其实只是把爱更高效地用起来了 13:10 <ant> <jnymo> 哇 13:10 <@jrandom> 厉害啊，postman 13:10 <mule2> 我不认为那是理想状态。最好所有节点都能有一些流量 13:10 <ant> <jnymo> 只要大家都爱我，我也能顶住啦 :( 13:10 <+postman> 嗯 13:10 <mule2> 作为某种掩护流量（cover traffic） 13:10 <@jrandom> mule2：这是因为我们的负载远小于网络容量 13:11 <@jrandom> 我不认为我们能长期保持容量大于负载 13:11 <ant> <jnymo> mule2，postman 也充当一个混合器（mixer）……所以很难知道包进去后去了哪里 13:11 <@jrandom> 所以我不太担心不通过较慢的同伴传数据 13:12 <mule2> 也许少一点“完美”优化反而有利于匿名性 13:12 <@jrandom> 另一方面，这也会激励更多人（实现并）使用 i2pcontent，这样他们既能做镜像也能获得掩护流量 ;) 13:12 <jdot__> 如果一台 router 处理几乎所有 tunnel，会是安全问题吗？ 13:13 <@jrandom> mule2：先把它做到尽可能好，再讨论是否主动让它“变差” 13:13 <@jrandom> jdot__：并不是一台 router 处理所有流量，但确实看到在非常快连接（托管机房 colo 等）上的 routers 处理的比拨号/DSL/有线用户更多 13:14 <@jrandom> 再加上 tunnel 失败减少意味着我们在迁移和探索得更少 13:14 <mule2> 只要距离 routers 的极限还很远，可能可以做一些流量分配 13:14 <@jrandom> 对，router 里有概率性的 tunnel 拒绝机制，可以根据该 router 的带宽上限启用 13:15 <ant> <jnymo> 是啊，但 postman 节点的高吞吐让分析他的节点更困难……也许通过他发送更安全，比所有节点都只做 1KB/s 要好 13:15 <@jrandom> （但如果 postman 不设任何限制，我们就无法按其百分比来拒绝；） 13:15 <ant> <jnymo> 更快节点的分组会造成某种混合级联结构（mix cascade），不是吗？ 13:15 <@jrandom> 嗯，可以这么看 13:15 <lektriK> 我可以关闭 Start I2P 窗口吗？ 13:15 * postman 很抱歉没有限制他的带宽 13:16 <@jrandom> lektriK：不太行，除非你把 i2p 作为服务启动（参见 http://localhost:7657/configservice.jsp） 13:16 <@jrandom> 呵，postman 别担心，如果/当我们达到你 router 的容量时，我们会对你的 router 退让 13:17 <lektriK> 好的，它显示 service started 13:17 <lektriK> 现在能关了吗？ 13:17 <@jrandom> lektriK：不行/可以——你可以先关闭你的 router，再通过 start->run->"net start i2p" 启动它 13:18 <mule2> 现在这样的话，少数非常大的 routers 可以处理所有 tunnels，从而使其他 routers 上没有任何掩护流量。不过我们会后再继续这个话题。 13:18 <mule2> 不想抱怨网络表现得太好了 :) 13:18 <@jrandom> 呵呵 13:20 <@jrandom> 0.5 会做进一步的探索，不过扩散太广会有匿名性方面的问题。关于 0.5 还有更多细节需要处理（文档可能下周出第一版草稿） 13:21 <@jrandom> 不管怎样，还有谁要就 0.4.2.5 提点什么？ 13:21 <@jrandom> 还是我们简短地转到 2) 0.5？ 13:21 <+postman> 继续 13:21 <ant> <jnymo> 非常稳定……继续 13:21 <@jrandom> 那就当我们已经进入下一项了 13:22 <@jrandom> 2) 0.5 13:22 <@jrandom> 是的，仍在进行中。准备好会有更多信息。 13:22 <ant> <Quadn-werk> 阿瑟·C·克拉克爵士还活着 :P 13:22 <ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1 13:22 <ant> <jnymo> 0.5 让人兴奋 13:22 <@jrandom> 好了，我就说这些——有人有问题/要讨论的吗？ 13:23 <@jrandom> 嗯，基于过去 16 个月学到的东西，正在进行一些重要的重构 13:23 <@jrandom> （呃，应该是 18） 13:23 <+postman> jrandom：所以 0.5 主要会采用新的 tunnel 管理系统？ 13:23 <ant> <Quadn-werk> 啊，希望我没打断会议 :/ 13:23 <+postman> 哇 13:23 <ant> <Quadn-werk> 抱歉 呵 13:23 <ant> <jnymo> 呵。我有个建议 13:24 <@jrandom> 对，postman：新的管理、池化和构建 13:24 <+postman> quadn：看你干的好事——你的粘贴导致了 netsplit（网络分裂）:) 13:24 <@jrandom> 你个混蛋！ 13:24 <ant> <Quadn-werk> ！ 13:24 <@jrandom> 怎么了，jnymo？ 13:24 <+postman> jrandom：每条 tunnel 仍然会是一个单独的本地 Destination（目标地址）吗？ 13:25 <@jrandom> 啥？ 13:25 <@jrandom> 0.5 不会对 i2ptunnel 做任何改动 13:25 <+postman> jrandom：好的 13:25 <@jrandom> （至少我不打算改） 13:26 <mule> postman 正在发起 intersection attack（交集攻击）？ 13:26 <ant> <jnymo> 对于那些完全没有带宽使用的人……让 routers 构建把它们包含进去的 tunnels 怎么样……比如 ABCABCA 13:26 <+postman> mule：不，是 quadn 的锅 :) 13:26 <ant> <jnymo> 那就是一条伪造的 tunnel 13:27 <@jrandom> jnymo：把一个 router 宣传为“嘿我有多余带宽，用我吧”是个危险的做法 13:27 <+postman> jrandom：那这次重构（简单说）会解决哪些问题？ 13:27 <ant> <jnymo> jrandom：我不太是那个意思 13:27 <@jrandom> 但现在看起来我们会有两组 tunnels——普通的，以及探索性（exploratory）的，后者从随机选择的未失败 peers 构建 13:28 <ant> <jnymo> jrandom：我的意思是创建一条伪造的 tunnel，把我自己放在这条 tunnel 的中间，仅用于模拟一些流量 13:29 <@jrandom> postman：让在同一条 tunnel 中相关联 peers 变得更难，允许客户端有效选择其出站 tunnel 的长度，并提供应对 predecessor attack（前驱攻击）所需的选项（会有各种权衡） 13:29 <@jrandom> （哦，还通过去掉大量 modPow 调用来提升性能） 13:29 <+postman> 好的谢谢 13:29 <ant> <jnymo> postman：而“每跳的 tunnel IDs”是个大改动 13:30 <+postman> modpow? 13:30 <@jrandom> 啊 jnymo。是的，在生成各种填充流量（chaff traffic）方面有很大潜力 13:30 <ant> <jnymo> 这样，两个非相邻的节点就无法知道它们在同一条 tunnel 里了，postman 13:30 <@jrandom> postman：模幂运算（modular exponentiation），非常耗 CPU 且浪费内存 13:31 <ant> <jnymo> jrandom：好，酷 13:31 <+postman> 好 13:31 <scintilla> jrandom，关于让客户端选择 tunnel 长度：会不会有机制防止人把它调到 99（或其他）？ 13:31 <ant> <jnymo> CPU 性能 13:32 <@jrandom> 必要时我们可以加上 hashcash，但过长的 tunnels 反正最终会失败 13:32 <scintilla> 啊，说得也是 13:32 <@jrandom> 我们甚至可以加点小伎俩——要求一条 tunnel 在创建后 60 秒内必须有有效的 tunnel 消息通过，才算“有效” 13:33 <@jrandom> （所以如果一条 tunnel 有 20 跳，构建完所有跳数会花太久） 13:33 <scintilla> 这是个好主意——能防止这种荒唐配置持续太久 13:33 <@jrandom> 不过这些都是针对黑客的。普通用户只会用暴露出来的界面 13:34 <ant> <jnymo> 对，你会把它限制在某个上限，对吧？ 13:34 <ant> <jnymo> 我们会比现在最大 2 更高，对吧？ 13:34 <@jrandom> 对，比如 /configclients.jsp 或 /i2ptunnel/edit.jsp 上的跳数下拉框 13:35 <@jrandom> 哦我以为现在最大是 3？ 好吧，总之会提供高于 2 的选项 13:35 <ant> <jnymo> 3 条 tunnels，2 跳 13:35 <@jrandom> 啊好 13:35 <@jrandom> 是的，0.5 会加入一些重要的新调整，比如是否对这些长度做随机化，以及随机化幅度等 13:36 <frosk> 最大确实是 3 13:36 <ant> <jnymo> 嗯 13:37 <@jrandom> 啊，/configclients 上是 3，i2ptunnel 上是 2 13:37 <frosk> 0.5 仍然按计划在一月发布吗？ 13:37 <ant> <jnymo> 啊 13:37 <@jrandom> 是的，frosk 13:37 <frosk> 太好了 13:37 <@jrandom> 我不会在 streaming 库上再磨蹭太久了，我保证 ;) 13:37 <frosk> 听起来工作量很大 :) 13:38 <@jrandom> 其实没那么糟，难点在于把算法做对 13:38 <@jrandom> （细节啥细节 ;)） 13:39 <+postman> frosk：而且都已经在纸上了 13:39 <+postman> :) 13:39 <ant> <jnymo> 呵 13:39 <frosk> 的确 :) 13:39 <@jrandom> 基本上是的 ;) 13:39 <@jrandom> 好，还有谁有 2) 0.5 的其它事？ 13:39 <ant> <jnymo> 没有 13:39 <frosk> 没了 13:40 <@jrandom> 好，那我们转到老传统的 3) ??? 13:40 <@jrandom> 嗨 13:40 <@jrandom> 还有别的要提的吗？ 13:41 <ant> <jnymo> postman：i2pmail.org 上没有 SMTP/POP3 的 inproxy，对吧？ 13:41 <cat-a-puss> 我在客户端这边仍然看到奇怪的延迟…… 13:41 <+postman> 嗯，没有 13:41 <frosk> 这时候我本该递上一瓶祝贺的葡萄酒，庆祝这一年的出色开发 ;) 13:41 <+postman> jnymo：POP3 只对 i2p 用户开放 13:41 <@jrandom> cat-a-puss：啊，你早些时候在时我错过了那些消息 13:41 <+postman> jnymo：对于域名 i2pmail.org，确实有一个作为 MX 的 SMTP inproxy 13:42 <@jrandom> frosk：干杯 13:42 <ant> <jnymo> 对对……不错…… 13:42 <cat-a-puss> 比如我有两个本地 Destination（目标地址），当一个尝试连接另一个时会有延迟，而且不是 CPU 受限 13:42 <mule> cat-a-puss：你还会把奖金支票也交上来吗？ 13:42 * postman 捐一瓶好威士忌 13:42 <@jrandom> cat-a-puss：对，你看到大约 0.5-1.0 秒的延迟，对吧？ 13:42 <cat-a-puss> mule：啥？ 13:42 <cat-a-puss> jrandom：对 13:43 <@jrandom> cat-a-puss：完全正常，是延迟 SYN 的一部分 13:43 <mule> 抱歉，评论是 frosk 说的 13:43 <ant> * jnymo 拿出那盒廉价葡萄酒 13:43 <mule> frosk：你还会把奖金支票也交上来吗？ 13:43 <@jrandom> （它会稍等再发送 SYN 及相关 ACK，以便看看是否有更多数据可以打包） 13:43 <scintilla> 哦，顺便说下，我很快就会收到那本包含 Fortuna 算法规范的书……同时我一直在尝试在 Java 中收集熵而不把机器拖垮 13:44 <@jrandom> 太棒了 13:44 <ant> <jnymo> 嗯，有人想对 i2p 发起一些攻击 13:44 <ant> <jnymo> 是谁来着？ 13:44 <@jrandom> connelly 13:44 <cat-a-puss> 有办法避免吗，还是我只能尽量避免短连接？ 13:45 <ant> <jnymo> 这事有什么进展吗，jr？ 13:45 <@jrandom> cat-a-puss：是的，创建 I2PSocketManager 时可以传一些选项，我找出来给你 13:46 <@jrandom> jnymo：那是个长期的 intersection attack（交集攻击），所以过一段时间他会有数据来帮助识别特定 eepsites 所在的 routers。我相信他拿到数据后会写些总结给我们 13:46 <ant> <jnymo> scintalla：Fortuna 算法是什么？ 13:46 <ant> <jnymo> jrandom：好 13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100 13:48 <scintilla> 这是一种密码学安全的伪随机数生成器，对可信加密绝对必不可少 13:48 <jdot__> 已经有人自愿参与那种攻击了吗？ 13:48 <@jrandom> cat-a-puss：然后在对 I2PSocket 调用 write() 之后务必调用 flush() 13:48 <@jrandom> jdot__：是的，他有 7 个自愿参与的站点 13:48 <cat-a-puss> jrandom：好的 13:49 <ant> <jnymo> 关于那场盛大的命名之争…… 13:49 <ant> * jnymo 偷笑 13:49 <@jrandom> 哦，还有 i2p.streaming.initialAckDelay=1000 13:49 <@jrandom> 或者甚至设为 =100 13:49 * jrandom 向 jnymo 扔泥巴 13:50 <ant> <jnymo> 我实际上做过 X.500 相关的工作，而且我的工作让我能免费用 Windows Servers 13:50 <ant> <jnymo> 所以也许一两个月后我会搭个中心化 DNS 用于测试 13:51 <@jrandom> 呵，把一个中心化命名服务器放在 .mil 上会相当滑稽 13:51 <ant> <jnymo> 不过把 i2p 地址塞进 WinServer 可能不是件容易的事……不确定 13:51 <ant> <jnymo> 呵……dnsalias 就是办法 13:52 <@jrandom> nano 做了一些很酷的工作，把 dnsjava 与 i2p 集成了 13:52 <ant> <jnymo> 喔—— 13:53 <@jrandom> 详情看看 nano.i2p 13:53 <ant> <jnymo> 你们居然没人告诉我……啊，谢谢 13:53 <@jrandom> 另外，如上次所说，大家应该把关于命名的想法发到 wiki 上 13:54 <@jrandom> 好了，还有谁有会议要提的事吗？ 13:55 <ant> <jnymo> 没有 13:57 <@jrandom> 好，那这样吧 13:57 * jrandom 做好准备 13:57 * jrandom *baf*地把会议关了