大家好，抱歉迟到了…
索引：
- 0.4
- Capacity and overload
- Website updates
- I2PTunnel web interface
- Roadmap and todo
- ???
1) 0.4
我想大家都已经看到了，0.4 版本在前几天发布了，整体来看进展相当顺利。很难相信自 0.3 发布以来已经过去了 6 个月（距离 1.0 SDK 发布也已有一年），但我们的确取得了长足的进步，而大家的辛勤工作、热情与耐心起到了巨大的作用。恭喜，也谢谢大家！
像任何一次好的发布一样，刚一发布我们就发现了一些问题，过去几天我们一直在收集 bug 报告并疯狂地打补丁（你可以在它们被修复时看到这些变更）。我们在推出下一个版本之前确实还剩下几个 bug 要消灭，不过预计一两天内就能完成。
2) 容量与过载
我们在最近几个版本中看到了一些相当偏斜的 tunnels 分配，尽管其中一些与 bug 有关（自 0.4 发布以来已修复其中两个），但仍然存在一个通用的算法问题——router 应该在何时停止接受更多的 tunnels？
几次修订之前，我们添加了限流代码：当 router 过载（本地消息处理时间超过 1 秒）时拒绝参与某个 tunnel 的请求，这起到了显著的作用。不过，这个简单算法还有两个未被覆盖的方面： - 当我们的带宽饱和时，本地处理时间可能仍然很快，因此我们会继续接受更多的 tunnel 请求 - 当单个节点参与 “过多” 的 tunnel 时，这些 tunnel 失败会对网络造成更大的伤害。
第一个问题相对容易处理，只需启用带宽限制器（因为带宽限制会按带宽延迟减慢消息处理时间）。第二个问题则更为复杂，需要进行更多研究和更多仿真。我在考虑一种方案：根据我们当前参与的 tunnel 数与网络向我们发起的 tunnel 请求数之比，以概率方式拒绝 tunnel 请求；同时引入一个基础的“善意系数”，如果我们参与的数量低于该基准，则设定 P(reject) = 0。
但正如我所说，还需要更多的工作和仿真。
3) 网站更新
既然我们已经有了新的 I2P Web 界面，我们以前的面向终端用户的文档几乎都已经过时了。我们需要一些帮助来梳理那些页面，并将其更新为描述当前的情况。正如 duck 和其他人建议的那样，我们需要一份超越 http://localhost:7657/ readme 的全新 ‘kickstart’（快速入门）指南 - 能帮助人们快速上手并进入系统。
此外，我们新的 Web 界面有充足的空间用于集成上下文敏感帮助。正如你在随附的 help.jsp 中所见，“嗯，我们可能应该在这里放一些帮助文本。”
如果我们能在不同页面添加 ‘关于’ 和/或 ‘故障排除’ 链接，用于说明各项的含义以及如何使用它们，那会非常好。
4) I2PTunnel 网页界面
把新的 http://localhost:7657/i2ptunnel/ 界面称为“简陋”，都算是轻描淡写。我们还需要做大量工作，才能让它更接近可用状态——目前从技术上讲功能都在，但你确实需要了解幕后发生了什么，才能弄明白它。我想 duck 可能还有一些进一步的想法，会在会议上提出。
5) 路线图和待办事项
我在及时更新路线图方面有些懈怠，但事实是，我们前面还需要进行一些进一步的修订。为了更好地说明我所认为的“重大问题”，我整理了一份新的任务清单，并对每一项都做了较为详细的说明。我认为在这个阶段，我们应该以相当开放的态度审视我们的选项，也许还需要重新调整路线图。
有一件事我忘了在那个待办列表上提到：在添加轻量级连接协议时，我们可以加入（可选的）IP 地址自动检测功能。这可能是‘危险的’（这也是它将是可选的原因），但它会显著减少我们收到的支持请求数量 :)
总之，待办列表上列出的那些问题，是我们计划纳入不同发布版本的，而且它们肯定不会全部出现在 1.0，甚至 2.0 中。我已经草拟了几种不同的优先级/发布方案，但尚未最终确定。不过，如果大家能指出后续的其他重大事项，我们将不胜感激，因为未排期的问题总是让人头疼。
6) ???
好了，我暂时就这些（正好，会议再过几分钟就要开始了）。欢迎在 GMT 时间晚上9点到 irc.freenode.net 的 #i2p、www.invisiblechat.com，或 irc.duck.i2p 来进一步交流。