I2P 开发者会议 - 2006年2月28日

15:11 <jrandom> 0) 嗨 15:11 <jrandom> 1) 网络状态和 0.6.1.12 15:11 <jrandom> 2) 迈向 0.6.2 15:12 <jrandom> 3) 小项目 15:12 <jrandom> 4) ??? 15:12 <jrandom> 0) 嗨 15:12 * Complication 迅速阅读笔记 15:12 * jrandom 挥手 15:12 <jrandom> 每周状态说明已发布在 http://dev.i2p.net/pipermail/i2p/2006-February/001266.html 15:12 <jrandom> （而且这次我在会议开始前超过 15 分钟就贴出了笔记！ ;) 15:13 <jrandom> 好，当各位阅读那些“超激动人心”的内容时，我们先进入 1) 网络状态和 0.6.1.12 15:14 <jrandom> 如前所述，0.6.1.10–0.6.1.12 这些版本的主要目标似乎已经达成，解决了 tunnel（隧道）创建加密的变更，并显著提高了创建的可靠性 15:16 <jrandom> 我们在 0.6.1.10 看到的波动已经消失，IRC 的稳定性似乎又相当不错了 15:16 <jrandom> 关于 1) 网络状态和 0.6.1.12 还有别的要提吗，还是我们移步到 2) 迈向 0.6.2？ 15:17 <+Complication> 我这边的网络状态：不再跌到 20 KB/s 以下了 :) 15:18 <jrandom> 酷，没错，0.6.1.12 修复了 0.6.1.11 中一个相当大的缺陷，之前它不能充分利用可用带宽。现在应该能更好地利用可用资源了 15:20 <jrandom> 好，我们跳到 2) 15:20 <jrandom> 如前所述，在为 0.6.2 加入最后一个功能改动之前，还有几件事需要理顺，不过我们这方面正在推进 15:20 <nymisis> 网络状态很好 :) 15:22 <jrandom> 嗯。新对等节点排序策略的细节在发布前会有更多信息；不过从笔记里的简要提及，大家应该能了解大意 15:23 <jrandom> 关于 2) 迈向 0.6.2，有任何问题/评论/担忧吗？ 15:23 <postman> jrandom：这次会有测试网吗？ 15:24 <postman> （需要任何 routers（路由器）、参与者来测试东西吗） 15:24 <postman> ? 15:24 <+Complication> 这事的本质相当直接——限制对手收集多样统计数据的机会 15:25 <+Complication> 听起来是个非常可取的特性 15:25 <jrandom> postman：新东西应该在线上网络透明运行，只使用本地信息，因此不需要单独的网络来测试 15:25 <jrandom> 是的，正是这样，Complication 15:26 <postman> ok 15:26 <postman> jrandom：你有勇气透露一下 0.6.2 的预计时间吗？ :) 15:27 <blubb> 4 月 1 日 15:27 <jrandom> 嗯，鉴于今天是 2 月末，我猜是 3 月或 4 月 15:27 <postman> 呵呵 15:27 <jrandom> blubb：那时我们已经安排了一个 MI6 后门 ;) 15:29 <@cervantes> 更像是一个 MI6 的猫门 15:29 <@cervantes> （预算削减） 15:29 <postman> 在大象馆里 15:30 <nymisis> 要严格说的话，那是 SIS，不是 MI6。 :) 15:30 <jrandom> 算了，我们就叫他们“他们”吧 ;) 15:31 <jrandom> 好，关于 2) 还有别的吗？ 15:31 <jrandom> 如果没有，我们就挪到 3) 小项目 15:31 <@cervantes> 抱歉，“the firm” 15:34 <jrandom> 好，我只是想指出几件很不错的事情：1) 易于实现，2) 非常有用 15:34 <+Complication> 关于小项目，我不确定我发给 Syndie 的回复是否发出去了，不过我在想能不能抢一个。 15:34 <+Complication> 还不确定选哪一个。目前在多练习一点 Java（在做一个微项目 :D），以增加把握，等我开始时能处理一个 15:35 <DeltaQ> 嗯，如果我在控制台把带宽调高，变化会立即生效还是需要重启？ 15:35 <+Complication> 等我把这个“微项目”准备好（当然前提是清单上还没被挑完），我会试着选一个 15:35 <jrandom> w3wt，太好了，Complication 15:36 <jrandom> DeltaQ：立即 15:36 <@cervantes> 1) Syndie 调度器不就是和 4) 下载管理器 / eepget 调度器关联起来的吗 15:36 <+Complication> DeltaQ：几乎立刻生效（在带宽被平均计算的周期内） 15:37 <@cervantes> 在我看来，一个功能更通用的上传/下载管理器可以同时满足这两种需求 15:37 <jrandom> cervantes：嗯，不一定。 1) 相当聚焦，而且还包含推送，而 4) 相当通用 15:37 <+Complication> cervantes：听起来可以的 15:37 <jrandom> 不过，是的，两者背后的引擎都是 EepGet 15:37 <jrandom> （eepget 以编程方式完成 Syndie 的 HTTP 传输） 15:38 <DeltaQ> 平均值似乎上不去超过 13KB/s 15:38 <DeltaQ> 我设置了 64KB/s，下行突发 192 15:38 <DeltaQ> 上行为 32/64 15:38 <@cervantes> 所以，一个通用的推送和拉取的 eepget，加上调度与管理的 API... 15:39 <@cervantes> 不过，到那时它大概就不再是小项目了 15:39 <+Complication> DeltaQ：平均值还取决于你的客户端 tunnels（以及其他节点的参与型 tunnels）产生了多少负载 15:39 <+Complication> 抱歉，s/average/actual bandwidth 15:39 <jrandom> cervantes：是的，不过 Syndie 的相关内容涉及相当多的逻辑。 15:40 <DeltaQ> 嘿，终于上去了 15:40 <DeltaQ> 1s: 30.82/29.33KBps 15:40 <DeltaQ> 看来我需要把上传带宽再调高 15:40 <jrandom> DeltaQ：平均值还会受别人如何看待你的影响，这取决于你的行为而不是任何宣称的速率，所以需要一点时间 15:40 <+Complication> DeltaQ：对于透传流量（参与型 tunnels），进来多少就得出去多少 15:41 <+Complication> DeltaQ：因此上传/下载速率差异很大时，会把参与型流量限制在两者中较低的那个 15:42 <+Complication> DeltaQ：此外，参与型流量还取决于其他节点如何“感知”你的节点的路由能力 15:42 <DeltaQ> 好 15:43 <+Complication> 如果他们觉得你路由能力强，就会更常来请求 15:43 <jrandom> 好，如果 3) 小项目没有别的了，我们就跳到 4) ??? 15:43 <jrandom> 还有别的要在会议上提出的吗？ 15:43 <DeltaQ> 嗯，我在一个 router 后面，不过我把端口 8887 映射到了这台电脑 15:43 <+Complication> 如果是新节点，或者刚刚增加了容量，他们会有点谨慎 15:44 <DeltaQ> 哦，抱歉，我不是想打断会议 ^^ 15:44 <+Complication> 前几天有人问到基于时钟偏移的可能攻击。我想我看到了你关于 tunneling 部分的回答（创建消息只包含 tunnel 的有效期，而不是创建者视角的时间）… 15:44 <@cervantes> （谢谢在状态说明中提到我） ;-)_ 15:46 <+Complication> 所以我就在想，想问一下……在 I2P 的消息传递中，有哪些点（如果有的话）可能包含发送者视角的时间？ 15:47 <+Complication> 我还没来得及把自己在这方面追到最新，所以有点摸不着头绪 15:47 <jrandom> Complication：没有任何地方会明确地说“我认为现在是 $time”，但借助足够的流量与时序分析，可能会把范围大大缩小 15:48 <jrandom> 我们确实以较大的周期对时间进行量化，但没有大到我们的最大时钟偏移，因此这里还有空间 15:49 <+Complication> 你觉得做一个更“精简”的 NTP 客户端最终会带来好处吗？ 15:49 <+Complication> 能更容易把偏移保持得更小的那种？ 15:50 <jrandom> 嗯，自从 sntp 客户端被引入 I2P 后，它一直在不断改进，所以现在我们不再看到过去那样的波动了 15:51 <jrandom> 也许我们可以把最小偏移限制从 10 秒降到 2 或 3 秒，甚至更低 15:51 <jrandom> 或者，我们可以让它也参考 SSU 的时钟偏移，以避免不必要的偏移 15:52 <+Complication> 或者，从另一面看，是否可以进一步限制推测另一节点可能时钟值的机会？ 15:53 * Complication 不知道哪种更实际，只是在随便提出一些可能性 :D 15:53 <jrandom> 不，我们知道直接连接的对等节点的时钟偏移 15:55 <Magii> 有没有办法判断更新是否成功完成？ 15:55 <+Complication> 啊哈，所以会话协议确实依赖这些信息.. 15:55 <tethra> 看一下你的版本号 15:55 <+Complication> Magii：它应该会在日志里写一条类似 CRIT “update verified, restarting to install” 15:55 <tethra> :/ 15:55 <+Complication> 然后，它会倒计时几分钟进行一次优雅重启 15:56 <+Complication> 最后重启 15:57 <+Complication> 哦，顺便问一句：内部的 NTP 客户端是否知道类似“时钟漂移率”的概念？ 15:58 <jrandom> 是的，http://localhost:7657/index.jsp 左上角的版本号应该就能说明问题 :) 15:58 <jrandom> Complication：不，它不保证时钟跳变是顺序的 15:59 <jrandom> s/sequential/ordered/ 15:59 <+Complication> 也不会形成类似“我们的系统时钟比需要的快 0.00345 倍”这样的认知？ 16:00 <jrandom> 啊，不会，不过把这点加到 net.i2p.util.Clock 里并不难（想要一个小项目吗？ :) 16:00 <+Complication> 我正好也在想类似的事情 16:01 <+Complication> 我想我现在会多想想这件事 :) 16:01 <+Complication> 不过，先做其他小项目 :) 16:02 <jrandom> 好，还有别的会议议题吗？ 16:03 <nymisis> 松饼？ 16:04 <jrandom> 不，煎饼 16:04 <jrandom> （mmMMmm 煎饼） 16:04 <jrandom> 说到这 16:04 * jrandom 收尾 16:04 <nymisis> 哦，该死，说得对。 16:04 * jrandom 用 *baf* 的方式宣布会议结束