I2P 开发者会议 - 2005年4月18日

16:09 <jrandom> 0) 嗨 16:09 <jrandom> 1) 网络状态 和 0.6.1.16 16:09 <jrandom> 2) Tunnel（隧道）创建和拥塞 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) 嗨 16:10 * jrandom 挥手 16:10 <jrandom> 每周状态说明已发布在 http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk 也来啦 16:10 <jrandom>（这次还在会议开始将近两个小时*之前*就发出来了呢 :)） 16:11 <jrandom> 好，既然我确信大家都已经仔细研读了说明，我们就直接进入 1) 网络状态 16:12 <+Complication> 嗨 :) 16:12 * Complication 赶紧去拿说明 16:12 <jrandom> 0.6.1.16 版本修复了我们 PRNG（伪随机数生成器）中一个存在已久的 bug，它导致了大量随机的 tunnel 拒绝 16:13 <jrandom>（根本原因是去年十月引入的，但现在已经修复） 16:13 <+Complication> 我这边的状态：在 1 + 0..1 跳的 tunnels 上还能勉强工作，在 2 + 0..1 或 2 +/- 0..1 上就不行了 16:14 <jrandom> 嗯，可以理解，尤其是在较慢的链路下 16:14 <jrandom>（不幸的是，这里说的“较慢”其实也没那么慢） 16:15 <jrandom> 还有很多工作要做，0.6.1.16 还没达到我们需要的程度，但算是进步 16:17 <+Complication> 关于你称之为“拥塞崩溃”的问题，我有个想法 16:18 <+Complication> 限制其影响的一种方法，也许是实际*要求*一个 router（路由器）接受一定配额的参与请求 16:19 <+Complication>（由用户直接或间接指定？） 16:19 <jrandom> 由哪个用户指定？ 16:19 <+Complication>（例如作为分享百分比的一部分，或者增设一个参数） 16:19 <jrandom> 本地用户，还是我们这些远端用户？ 16:19 <+Complication> 每个人给自己的 router 指定 16:19 <@frosk> 那我们要转到 2) 吗？ :) 16:20 <jrandom> 好啊，就当我们进入 2) 了 :) 16:20 <+Complication> 这样我就可以比如告诉我的 router：“即使你拥塞了，也要保持至少 4 KB/s 的转发速率” 16:21 <jrandom> Complication：这不太可行——如果一个 router 过于拥塞，其他人（希望如此 ;)）会停止请求它参与 tunnels。 16:21 <+Complication>（当然，这意味着某些本地目标可能会离线更久一些） 16:21 <jrandom> 而且如果没人请求，它就/无法/转发别人的数据 16:22 <+Complication> 啊，也许我应该表述得更清楚一些 16:24 <+Complication> 我的想法是：在保证一定参与流量配额的前提下，限制它自身的 tunnel 创建消息，而不是去限制参与的 tunnels 16:24 <+Complication> 例如：“我绝不会把我参与的 tunnels 限到低于 4 KB/s。如果需要限速，我会优先限制我自己的流量。” 16:26 <jrandom> 嗯，这里面有匿名性风险（虽然和选择性 DoS 一样的路子，反正我们也没有对此防御） 16:27 <jrandom> 不过，在拥塞时限制我们自己的本地 tunnel 构建，这是我现在正在测试的——再加上可选地忽略 4KBps 底限的支持，应该很容易 16:28 <spinky> 目前，当你传输大量数据时，完全得不到任何掩护流量。 16:29 <spinky> 为参与带宽设一个底限听起来不错。 16:30 <jrandom> 其实我们确实有一个底限（既体现在分享百分比上，也体现在在分配完所有带宽后内部预留的 4KBps） 16:30 <+Complication> 唉，掉线了……希望我说的东西没丢太多，回复的话我得从日志里看了 :) 16:32 <@frosk> 4KBps 有什么特别的意义吗？ 16:33 <jrandom> 有几点——4KB 大约等于 tunnel 创建消息的大小；而且从经验上看，我从没听说过有 router 在更低带宽下还能成功运行 16:33 <spinky> 也许是某些 bug 导致分享百分比不起作用？ 16:34 <jrandom> 你为什么说分享百分比不起作用？ 16:34 <@frosk> 我明白了 16:34 <+Complication> frosk：不啦，它只是当前代码里的一个数，我在说明我的设想时也引用了它 16:35 <+Complication>（不是因为它有多重要，只是因为我想的东西在某种意义上正好和它相反） 16:35 <spinky> 它被设为 80%，可是一旦本地在产生数据，参与就降到 0。也许我理解错了。 16:36 <jrandom> 啊，对，分享百分比并不是这么个意思 16:36 <+Complication> 它是一个最多能分享多少的上限，前提是你实际可用于分享的带宽 16:37 <+Complication> 如果本地流量占了 70%，你只剩 10% 可用于分享 16:37 <+Complication> 如果本地流量很重，你就会剩 0%，而 80% 的上限永远达不到 16:37 <spinky> 好的。我看到它写的是‘最多’…… 16:38 <+Complication> 另外，还有 4 KB/s 的预留 16:38 <jrandom> 啊，它是对你可用带宽的分享百分比 16:38 <spinky> 也许可以再加一个参与带宽底限的设置，低于它时 router 会接受更多 tunnels？ 16:38 <jrandom> 如果你已经用了 95% 的带宽，它会在剩下的 5% 里最多分享 80% 16:39 <+Complication> 哦，那我也部分误解了 16:40 <fox> <zorglu1> i2p 如何衡量其他本地应用程序使用的带宽量？ 16:40 <spinky>（只是说，如果你认为掩护流量是好事，也许让它在本地带宽使用很重时依然可配置是件好事） 16:40 <+Complication> 我以为它是针对持续限速来应用的 16:40 <jrandom> zorglu1：它衡量的是 i2p 自身的带宽使用，并且知道 i2p 的带宽上限 16:41 <jrandom> 哦，嗯，看回代码，int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> 所以你说得对，Complication 16:42 <jrandom> spinky：掩护流量只在低延迟的混合网络（mixnet）里才有那么点用处 16:42 <jrandom> 它确实会给高带宽的 routers 一些激励，但那些没有多余带宽可用的就没什么办法了 16:49 <jrandom> 总之，tunnel 拥塞问题已经存在一段时间了，只是最近被疯狂的 tunnel 拒绝率给进一步加剧了 16:49 <jrandom> 希望下一个版本能帮我们把它解决掉 16:49 <jrandom> 好，关于 2) tunnel 创建和拥塞，大家还有别的吗？ 16:50 <@frosk> 听起来需要对 tunnel 构建方案做些修改 16:50 <+Complication> 希望它能有所改进 :) 16:51 <+Complication> 哦，顺便提一句…… 16:52 <jrandom> 嗯，我们有一些成本较低的修复，比如降低最大并发、在拥塞时限制我们的构建尝试、降低丢弃频率（而不是明确拒绝），以及调整画像以鼓励明确拒绝而不是丢弃 16:52 <+Complication> ……你是否碰巧发现了什么，能解释原始带宽指标与 tunnel 载荷指标之间巨大差异的？ 16:52 <+Complication>（比如，总带宽 1 GB，而 tunnel 载荷合计 300 MB） 16:52 <jrandom> 不过确实，那些只影响程度大小 16:52 <+Complication>（因为我最近不常上 IRC，不确定你最近有没有看这个问题） 16:54 <jrandom> 我还没太深挖，不过要记得，出站 tunnels 的 tunnel 构建请求并不是 tunnel 消息（而且如果只有 0.1% 成功的话，那会有很多这样的请求。每个 4KB……） 16:54 * Complication 不确定这是指标的问题，还是一种真实效应 16:55 <+Complication> 哦……出站构建请求……确实如此 16:55 <jrandom> 即将到来的 -1 构建增加了一大堆统计，用于按消息类型监控报文 16:55 <+Complication> 那很可能就是原因 16:55 <jrandom>（那些出站构建请求里还包括构建参与请求——转发一个回复） 16:56 <jrandom>（（所以不只是本地的东西）） 17:00 <+Complication>> 谢谢，这解释了很多 :) 17:00 <+Complication>> 那就不是巫术了，而是真实的流量，只是我忘了，因为我查的地方没有专门统计它 17:00 <+Complication> 它确实必然会发生，而且确实会消耗很多字节 17:00 <+Complication> 尤其是在成功率很低的时候 17:01 <jrandom> 嗯，尽管如此，它本不该像现在这样耗那么多，因为我们的成功率本该比现在更高 :) 17:01 <jrandom> 好，关于 2) 还有别的吗？ 17:02 <jrandom> 如果没有，我们转到 3) Feedspace 17:02 <jrandom> frosk：要不要给我们一个更新？ 17:03 <jrandom>（或者告诉我们去 fsck off 然后读 eepsite（I2P 内部网站）？ ;) 17:04 <@frosk> 好吧，对于没关注 frosk.i2p 或 feedspace.i2p 的人来说，feedspace 现在基本能工作了（按照我自己对“基本”的定义） 17:04 <jrandom>（w00t） 17:05 <@frosk> 最近加了一些不错的东西，比如对 i2p 之外传输方式的基础支持（想到的是 tor 和非匿名的 tcp/ip） 17:06 <@frosk> 所以，未来我们计划让 syndie（一个即将到来的、可能非常不错的重写版本）使用 feedspace 作为其聚合方式之一 17:06 <@frosk> 目前，还没有任何客户端应用能真正*使用* feedspace 做什么事 :) 我一直在用一个极其粗糙的 servlet 应用做测试 17:07 <jrandom>（粗糙 + 可用）++ 17:07 <@frosk> 所以当然有一个面向客户端黑客的职位空缺 ;) 17:08 <@frosk> 在公开测试之前，feedspace 仍然需要一些必要的东西，但应该很快了 :) 17:08 <jrandom> 不错！ 17:08 <jrandom> 我们有什么可以帮忙的吗？ 17:08 <@frosk> 另外我也在写一些文档，此前一直比较缺 17:09 <spinky> 你认为 feedspace 能用于大文件吗？ 17:10 <@frosk> 1）使用（仍未文档化的）xmlrpc api 的客户端应用，2）http://feedspace.i2p/wiki/Tasks，3）等到时候参与测试 17:10 <@frosk> 大文件支持现在不是优先级，但也许以后会有 17:10 <@frosk> “1.0”的重点是较小的消息，比如博客和讨论帖，以及各种事件 17:11 <jrandom> 不过把 .torrent 文件送进一个支持 RSS/feedspace 的 BT 客户端并不是问题 17:11 <@frosk> 大文件可能能用，也可能不能用 :) 17:11 <@frosk> 那会非常酷 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> 我希望我们会看到各种这样的“适配器”应用 :) 17:12 <+Complication> 嗯，我相信大家会找到用位……呃，侧信道来传大文件的方法 :) 17:15 <@frosk> 对 feedspace 代码用了各种 java1.5 特性，我有点愧疚。现在在 free java 上可能很难编译/使用，但我相信它会赶上的 :) 17:15 <jrandom> 哎哟 17:16 <jrandom> 嗯，有传闻说 gcj 会采用 ecj 来支持 1.5-isms 17:16 <spinky> Complication：小马驮着塞满硬盘的鞍袋？ 17:16 <@frosk> 是的 17:17 <+Complication> spinky：无人机，在我更偏好的场景里 :P 17:17 * jrandom 仍然勉强才开始用 1.4-isms 17:17 <+Complication> 不过我猜小马也行 :P 17:17 <jrandom> 不过 1.6 确实不错 ;) 17:17 <@frosk> 为了保持与 gcj 兼容？ 17:18 <@frosk> 嗯，我觉得 1.6 对大多数东西来说也没太多“isms” :) 17:18 <+Complication>（或者飞天刺猬空投存储卡） 17:18 <jrandom> gcj/classpath/等等，同时也是为了性能（我发现 1.5 比 1.4 要更臃肿一些） 17:19 <jrandom> 确实，1.6 的改进主要体现在 vm/bytecode 层面 17:19 <@frosk> 嗯，好的 17:20 * jrandom 并不是想劝你别用 1.5isms。我相信你有你的理由，比如 azureus 已经要求 1.5 了 17:21 <@frosk> 嗯，现在已经回不去了 :) 希望不会太颠簸 17:24 <jrandom> 嗯，我肯定一切都会顺利的 :) 17:25 <jrandom> 好的，很酷。关于 3) feedspace，还有别的吗？ 17:25 * frosk 拥抱他的泛型和 java.util.concurrent ;) 17:25 <jrandom> 呵呵 17:27 <jrandom> 好，如果 3 没有别的了，我们转到 4) ??? 17:27 <jrandom> 会议还有其他事项吗？ 17:27 <+Complication> 一个小问题，其实应该在 2) 里问的 17:28 <+Complication> 你知道闲置的参与型 tunnels 通常是怎么形成的吗？ 17:28 <+Complication> 它们主要是不是意味着 tunnel 构建失败，只是只有创建者才知道它失败了？ 17:28 <+Complication> 或者还有其他原因？ 17:28 <+Complication>（当然，撇开显而易见的情况——也就是应用自己在闲着） 17:29 <jrandom> 一个闲置的应用不会有闲置的 tunnels（它们会被测试） 17:29 <jrandom> 闲置的 tunnels 是由于某些原因失败了 17:29 <jrandom>（要么没能完全创建成功，要么在运行中失败） 17:30 <+Complication> 对，所以所有 tunnels 反正都会被测试，而 tunnel 测试应该会产生流量……确实如此 17:30 <+Complication> 这其实引出我问题的第二部分：注意到某个 tunnel 处于闲置状态时，提前把它废弃，会有任何好处吗？ 17:31 <+Complication> 能节省什么宝贵资源吗？ 17:32 <jrandom> 没有——一个不在推送数据的 tunnel 并不占用资源 17:32 <jrandom>（好吧，它会占用一点内存，也许 32 字节） 17:32 <+Complication> 或者，它是否能帮助一个 router 更好地把握其负载和类似参数…… 17:33 <jrandom> 基于 tunnel 历史对带宽使用做预测当然是个开放问题 17:33 <+Complication> 或者这只是无用功，最好等它自然过期？ 17:33 <+Complication>（就像现在这样） 17:34 <jrandom> 我们以前做过一些预测，但没有带来明显好处，所以现在用的是更简单的算法 17:34 <+Complication> 啊哈，也就是说没啥收益…… 17:34 <+Complication> 谢谢，我基本就想问这些 :) 17:34 <jrandom> 不客气，这个担忧很合理 17:34 <jrandom> 好的，会议还有别的事项吗？ 17:35 <+Complication> 是的，如果做预测，tunnels 的空闲比例可能会让估计产生偏差 17:35 <+Complication>（如果变化很大） 17:36 <jrandom> 嗯，我们会希望把空闲百分比作为估计的一部分 17:36 <jrandom>（我们以前就是这么做的——见 RouterThrottleImpl.allowTunnel 方法） 17:37 <+Complication> 哦，不知道这一点 :) 17:37 <jrandom> 并注意新的注释： 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication 仍在浏览找到那个文件，不过谢谢 :) 17:39 <jrandom> w3rd 17:40 <jrandom> 好，如果会议没有其他事项…… 17:40 * jrandom 收尾 17:41 * jrandom *baf* 地宣布会议结束