I2P 开发者会议 - 2005年11月29日

15:25 <jrandom> 0) 嗨 15:25 <jrandom> 1) 网络状态和 0.6.1.6 15:25 <jrandom> 2) Syndie 15:25 <jrandom> 3) I2P Rufus 0.0.4 15:25 <jrandom> 4) ??? 15:25 <jrandom> 0) 嗨 15:25 * jrandom 挥手 15:25 <jrandom> 每周状态说明已发布，地址：http://dev.i2p.net/pipermail/i2p/2005-November/001234.html 15:26 * bar 递给 jrandom 一个 baf 15:26 <c3rvantes> 还不行！ 15:26 * jrandom 开始热身 15:26 <jrandom> 呃… 15:26 <jrandom> 我们先过一下前几个议程项目吧 :) 1) 网络状态和 0.6.1.6 15:27 <jrandom> 最近几个版本更新了很多内容，但网络看起来仍然相当稳定。 15:28 <jrandom> 在少数 router 上我们看到 router 参与数有严重尖峰，不过这基本无害 15:28 <+legion> 酷，我同意网络状态在变好。另外，是的，为什么不在 0.6.1.7 里去掉 TCP 呢 15:28 <jrandom> （呃，是 tunnel 参与数的尖峰，确切地说） 15:29 <@cervantes> 可不是呢 15:29 <jrandom> 不太确定，legion。可能有些用户只能用 TCP，但我记得只有一两个这样的人 15:29 <+legion> 我注意到在 0.6.1.5 上，router 有时会自己重启。 15:29 <+Complication> 我的在合理范围内波动，参与的 tunnel 从 100 到 250 15:29 <jrandom> 我想不出保留它的充分理由，倒是有几个理由要去掉它 15:30 <jrandom> 不错，Complication 15:30 <jrandom> （这些数字按照 stats.i2p/ 来看相当平均，但请记住，这类数字可能损害匿名性，因此不应随便公开，尤其别在会有记录的会议里发出来 ;) 15:30 <+Complication> 我的老赛扬仍然大约每 10 小时自动重启一次 15:30 <+Complication> 否则它的连接状况比以往都好 15:30 <Pseudonym> 为什么要去掉它？ 15:31 <+Complication> TCP 的开销很大 15:31 <@cervantes> 我的 router 已经累坏了 15:31 <+Complication> 就每个连接需要的线程数而言 15:31 <@cervantes> Complication：乘以 10 就是我这台 router 目前的范围 ;-) 15:31 <+legion> 我的在 200-400 个参与的 tunnel 之间波动，所以看起来比以往都好。 15:32 <+Complication> cervantes：哎哟哎哟 15:32 <+Complication> 我见过一次意外，参与的 tunnel 达到 2000，不过那是夏天 15:32 <jrandom> Pseudonym：性能（CPU/内存，由于我们半可靠的要求而带来的更好调度）、可维护性、更有效的黑名单处理 15:32 <+Complication> 一次性的尖峰，再也没出现过 15:32 <+legion> 是啊，以前的某些版本会出现那样的尖峰 15:32 <jrandom> Complication：我们在上一个修订版里出现过 > 2000 的 tunnel 尖峰 15:33 <jrandom> 不过希望 0.6.1.7 能解决这个问题 15:33 <+legion> 嗯，这些都是去掉 tcp 的好理由 :) 15:33 <jrandom> 但是，再说一次，tunnel 参与数的尖峰没关系，因为大多数它们并不会被实际使用 15:34 <@cervantes> Pseudonym：网络上似乎只剩一两台 router 还在用 tcp 15:34 <jrandom> 这个版本也把 tcp 去掉也许是个好主意，因为没有其他重大改动。这样我们就能比较清楚地看到它带来的影响 15:34 <jrandom> （必要时也可以重新启用） 15:35 <Pseudonym> 如果只有两台 router 在用它，我不觉得无论保留还是去掉会有多大影响 15:35 <Pseudonym> （除了网络上会少两台 router） 15:35 <@cervantes> 两个不爽的用户 15:35 <jrandom> 嗯，这个传输在一些奇怪情形下会出现，这也是我想禁用它的原因之一 :) 15:35 <+Complication> 希望他们别太往心里去 15:36 <+Complication> 某些 ISP 过滤 UDP 真是很糟糕。 15:36 <+Complication> 糟糕，而且完全没道理。 15:36 <jrandom> （例如，当某个 router 崩掉时，人们会把他们的 SSU 传输标记为失败，于是就回退到 tcp 传输） 15:36 * Pseudonym 爱死他的 ISP 了。没有任何限制 15:37 <+Complication> 那么没有 TCP，我们就能看到 UDP 单独应对的情况？ 15:37 <+Complication> “不装辅助轮” :P 15:37 <+legion> 呃，那不用 tcp 我们怎么绕过这种糟糕的过滤？ 15:38 <jrandom> 正是这样，Complication :) 15:38 <jrandom> legion：我们不绕过 15:38 <jrandom> （restricted routes，受限路由） 15:38 <+Complication> 嗯，除了文件共享程序之外，不也有不少有用的应用会用到比 DNS 数据包更大的 UDP 包吗？ 15:39 <+legion> :( 听起来不妙 15:39 <+Complication> 大小与 I2P 使用的最小数据包尺寸差不多？ 15:39 <jrandom> 呃，legion，这不是问题 15:39 <jrandom> Complication：流媒体协议 15:39 <+Complication> 不把 DNS 弄残，根本无法直接封掉 UDP。 15:39 <+Complication> 可以限制数据包大小。 15:40 <+legion> 好吧，刚才听起来像是个问题 15:40 <+Complication> VoIP？ 15:40 <jrandom> 如果这种情况很普遍——整个互联网社区普遍禁用 udp——那就会是个问题 15:40 <+Complication> 嗯，VoIP 用大包还是小包？ 15:40 <jrandom> 但如果只是少数 ISP，我们可以把它们当作受限路由来处理 15:40 <+Complication> 或者你是指……视频流？ 15:40 <+legion> 我想两种都会用 15:41 <jrandom> 都会，Complication。RTSP 跑在 UDP 之上，而 real 跑在 RTSP 上（如果我没记错的话） 15:41 <+Complication> s/p/s 15:42 <+legion> 那继续下一个议题？ 15:42 <+Complication> cat /etc/services | grep -c udp 15:42 <+Complication> 227 15:43 <jrandom> 我还不确定我们是否会在 0.6.1.7 里去掉 tcp，不过大概会。 15:43 <jrandom> 好的，关于 1) 还有别的吗？没有的话，我们跳到 2) Syndie 15:43 <+Complication> 也就是说，至少有 227 个应用（其中一些可能已过时或仅限局域网）使用 UDP 15:44 <jrandom> 呸，这可是 intarweb。你只需要经代理的 HTTP 访问就行了 15:44 <jrandom> 关于 2) 我没什么可补充的，邮件里（以及 Syndie 上）都说了 15:44 <+legion> 我被说服了，是的，干掉它。 :) 15:44 <jrandom> 关于 syndie 还有什么想提的吗？ 15:45 <+legion> 我对 2) 也没什么要说的。 15:45 * Complication 正在读 "how Syndie works" 15:46 <+Complication> 有个小小的 UI 效果，总是让我吃惊。:D 15:46 <+Complication> 当我展开一串消息时，现行激活的那条会移到列表最上面，这总让我有点措手不及。:P 15:47 <+Complication> 不过你大可忽略这个。我只是很挑剔，又是个习惯驱动的家伙。:P 15:47 <@cervantes> 主题串联模型正被深入讨论 15:47 <@cervantes> ;-) 15:47 <+Complication> 我会习惯的。:) 15:48 <+Complication> cervantes：在 Syndie 里？我得去找那条讨论帖。:) 15:48 <@cervantes> 我也不喜欢——不过这很可能会改 15:48 <jrandom> 是啊，我想那有点古怪 15:48 <+legion> 是啊 15:48 <@cervantes> "subject: syndie threading" 15:49 <+Complication> 此外，如果展开的是最底下那条，它无论如何也不得不移动。 15:49 <+Complication> 不然它就会被卡在那里。 15:50 <jrandom> 底部的导航一次显示的是 10 个线程/主题串（threads），不是 10 条消息。所以它可以展开最底下那个主题串 15:50 * cervantes 目前正在测试一些不同的主题串联 UI 风格实现 15:51 <jrandom> 给力 15:51 <jrandom> 是啊，理想情况下我们能通过 CSS 切换它们，如果不行就从服务器端切换 15:52 <@cervantes> 或者更确切地说是“threading navigation styles” 15:53 <@cervantes> 嗯，我的测试默认使用纯 HTML 的嵌套无序列表 15:53 <@cervantes> 你可以按需叠加任意多的 CSS 和 JavaScript 15:53 <jrandom> 什么时候能看到一些模型稿，有预估吗？ 15:53 <@cervantes> （不过它只是一个概念验证，不是真正的 UI 实现） 15:54 <@cervantes> 我大部分编码都是在 I2P 会议期间完成的 ;-) 15:54 <jrandom> 呵 15:54 <@cervantes> 也许第一个模型稿今晚就能准备好 15:54 * jrandom 安排起了每日会议 15:54 <jrandom> 给力 15:54 <@cervantes> 可恶 :) 15:55 <jrandom> 好，关于 2) syndie 还有别的吗？ 15:55 <jrandom> 没有的话，我们继续 3) I2P Rufus 0.0.4 15:56 <jrandom> 除了邮件里的内容，我没什么可补充的——Rawn/defnax，你们在吗？ 15:56 <+legion> 那 0.0.4 表现如何？还剩下哪些问题？ 15:57 * jrandom 毫无头绪 15:58 <+legion> 也许它的某位用户能回答。看起来表现良好且稳定吗？ 15:58 <jrandom> 好吧，看来 Rawn 和 defnax 现在不在。如果有人对 I2P Rufus 有任何问题/意见/担忧，去论坛发帖吧 15:58 <+legion> 唉，那我们只好这样了。 15:59 <+legion> 进入 4)？ 15:59 <jrandom> 嗯，看起来是这样。好，4) ??? 15:59 <+Complication> 不巧的是，我还没试过 I2P Rufus。 16:00 <jrandom> 还有其他想提的吗？ 16:00 <jrandom> （来嘛，我们得把时间拖长点，让 cervantes 多干点活！） 16:00 <+legion> 对了，接下来有哪些有趣的东西要来了？ 16:00 <+bar> 有哪里可以让我多了解一下“restricted routes”吗？ 16:00 <+bar> （我确实搜过了） 16:01 <+legion> 也许我们甚至可以讨论一下 i2phex？ 16:01 <jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD 16:01 * cervantes 把鼠标指向了关闭按钮 16:01 <jrandom> 呃，#future.restricted 16:02 <jrandom> 还有 how_* 页面和 todo 16:02 <jrandom> （在网页上） 16:02 <+Complication> 嘿，I2P 好像跳过了一个 build :D 16:02 <+Complication> :D 16:02 <+bar> 谢啦 16:02 <+Complication> - public final static long BUILD = 1; 16:02 <+Complication> + public final static long BUILD = 3; 16:03 <jrandom> legion：会在 netDb 上做些 hacking、性能修改、受限路由、流式传输改进、eepproxy 改进、tunnel 改进等。很多东西，但都还没准备好 16:03 <+legion> 咦，怪了 16:03 <jrandom> 关于 i2phex 有什么要提的吗，legion？ 16:03 <jrandom> Complication：对，有意为之。我忘了把 BUILD = 2 提上去 16:03 <+Complication> （倒也没什么影响，只是想知道我以前有没有见过这种少见的情况 :) 16:04 <+legion> 棒，听起来很不错，谢谢！ 16:04 <jrandom> 哦，这让我想起……如果有人愿意着手重做我们的网站就太酷了 16:05 * jrandom 不想去想，但迟早得做 16:05 <+legion> 是的，有一个 16:05 <+legion> 现在把 i2phex 更新到 phex 最新的 CVS 代码值得吗？ 16:06 <+Complication> 不确定，最近没听到 Redzara 的消息 16:06 <jrandom> 我记得上次 redzara 在等 gregorz 对 phex 的更新 16:06 <jrandom> （这样我们就能做一个相当干净的更新/扩展） 16:08 <+legion> 咦，那为什么要有 i2phex？ 16:08 <+Complication> 以防万一？ 16:08 <jrandom> 嗯？ 16:08 <jrandom> i2phex 是 phex 的一个扩展 16:08 <+legion> 看起来他们是想只有一个带 I2P 扩展的 phex 16:09 <jrandom> 所谓扩展，是指只修改很少的一小部分 16:09 <jrandom> 呃，s/bits/components/。这样一来，每当 phex 开发者修复问题时，我们就能很容易地更新代码 16:10 <+legion> 如果这样，我要把它更新到最新的 CVS 代码应该不费事，虽然我知道现实中不会这么顺利。 16:10 <jrandom> 我在论坛上最后听说的计划是让 I2Phex 和 Phex 成为两个独立的应用，但共享大部分代码 16:10 <jrandom> 对，legion，那会很棒，但据我所知，Gregor 还没完成对 Phex 的修改 16:11 <jrandom> （这就是 redzara 在等的东西） 16:11 <+legion> 啊我懂了 16:11 <jrandom> 所以，要么去帮 Gregor，一起完成，要么继续改当前的 I2Phex 代码库 16:12 <+legion> 那如果我不等，直接用新代码更新 i2phex，就不需要 redzara 继续了 16:12 <jrandom> 嗯，也不尽然。 16:12 <jrandom> 把 I2Phex 更新到当前的 Phex 代码当然很棒 16:13 <jrandom> 但只要 Phex 开发者更新了他们的代码，我们又会不同步 16:13 <+legion> 好，我大概今晚或这两天就会着手做。 16:13 <jrandom> 给力 16:13 <+legion> 没关系。 16:14 <+legion> 其实我并不打算让 i2phex 始终与 phex 代码保持同步，只是听说 CVS 里有些修复是 i2phex 确实需要的。 16:15 <+legion> 另外我确实想剔除 i2phex 不需要的 phex 代码和功能。 16:15 <jrandom> 不错 16:16 <+legion> 至于新特性，以及修掉还没正常工作的部分，比如上传队列……嗯，我已经开始研究让 webcache 工作了，但还有很多要做。 16:17 <jrandom> 说得对。是啊，phex 以前的 gwebcache 支持是可用的，但 sirup 把它关了，因为一开始没必要 16:17 <+legion> 我确实打算最终把 jeti 加进 i2phex。 16:17 <jrandom> 不错 16:18 * jrandom 从没用过 jeti，我希望它保持为可选组件，不过支持更多东西挺酷的 16:18 <+legion> 是的，它可以是可选的，用户可以下载一个 jeti2phex ;) 16:19 <jrandom> 同感 16:19 <+legion> i2phex 还有很多可以做的事，尽管它现在已经运行得很好。 16:20 <+legion> 到目前为止，让客户端 7×24 不间断连接、运行是可行且容易的。 16:21 <jrandom> 是啊，我用它也很顺利……“备份我已授权的录音” 16:21 <+legion> 呵 :) 16:22 <jrandom> 好，这次会议还有其他事项吗？ 16:23 * cervantes 推来了一面中国锣 16:23 <+legion> 我好像忘了什么……嗯 16:24 <+legion> 哦对了，有没有什么办法能减少 i2p 和 i2phex 的内存占用？ 16:25 <+Complication> 嗯，TCP 传输占用不少 16:25 <jrandom> 可以把两者跑在同一个 JVM 里 16:25 <+Complication> 如果那个去掉，会释放一些 16:26 <@cervantes> 把你机器里的内存条拔几根 16:26 <cat-a-puss> 有谁用过 javolution，知道它是否有帮助吗？http://javolution.org/ 16:26 <jrandom> （i2p 安装目录下的 clients.config 定义了启动客户端的主类和参数） 16:26 <+legion> 那么如果我们把二者跑在同一个 JVM 里，而且去掉 TCP，是否能把占用降到 50MB 以下？ 16:27 <jrandom> 不清楚，legion。还取决于你说的 50MB 是什么指标。RSS/VSS/等等 16:27 <jrandom> 不过我确实不建议把两者跑在一个 JVM 里，除非你让两者一直同时运行，因为关掉其中一个会把另一个也带死 16:27 <@cervantes> legion：限制带宽并限制参与的 tunnel 数也可能有帮助 16:27 <jrandom> 对，就像 cervantes 说的 16:28 <cat-a-puss> 在我看来，如果我们确切知道某类对象最终可能用到的数量，就能避免 JVM 过度分配 16:28 <+Complication> 对，内存有不同的度量/分配方式，我一直没弄明白 16:28 <jrandom> 对，我们做了一些这样的事情（见 net.i2p.util.ByteCache） 16:29 <+Complication> （不过如我所说，Java 对我来说还很新） 16:29 <jrandom> 我之前瞥过 javolution，但它似乎进步不少。我会再看看 16:30 <cat-a-puss> jrandom：我知道单位里有人在用而且很满意，尽管他们不关心内存分配 16:31 <jrandom> 嗯，它其实不会省内存，但能减少 GC 抖动 16:31 <+legion> 我个人不太在意内存分配，不过很多人很在意。 16:31 <jrandom> 哦，而且它还是 BSD 许可 16:31 <cat-a-puss> 对 16:31 <jrandom> legion：内存分配关系到性能 16:32 <+legion> 呃，哦，那我说的是内存占用 16:33 <+legion> 很多人之所以喜欢 uTorrent，是因为它的内存占用非常小。 16:33 <jrandom> 啊，对。我们后面可以再调。既然 i2p 在默认 JVM 大小内就能跑，我不太担心（我们还有大量可调空间） 16:34 <jrandom> 好，这次会议还有别的吗？ 16:35 <+legion> 没有了，我这边 OK…… 16:37 * jrandom 准备收尾 16:37 * jrandom 用 *baf* 一声把会议结束了