大家好，是时候更新一下进展了。
索引：
- Net status
- Streaming lib
- 0.4.2
- Addressbook.py 0.3.1
- ???
1) 网络状态
在上周经历了持续 2-3 天的相当拥塞之后，网络已经重回正轨 (很可能是因为我们停止了对 BitTorrent 端口的压力测试 ;)。自那以后，网络一直相当可靠 - 我们确实有一些 router（路由节点）已连续运行了 30-40+ 天，但 IRC 连接仍偶有波动。另一方面…
2) Streaming lib（流式传输库）
在过去大约一周里，我们在网络上对 streaming lib（流式传输库）进行了更多的实时测试，效果看起来相当不错。Duck 用它搭建了一个 tunnel，供大家访问他的 IRC 服务器，在几天的时间里，我只遇到两次不必要的断线（这也帮助我们定位了一些 bug）。我们还运行了一个 i2ptunnel 实例，指向一个 squid outproxy（出口代理），供大家试用；与旧的库并行对比后，吞吐量、延迟和可靠性都有了显著提升。
总的来说，这个流式传输库看起来已经足以发布首个版本。还有一些事项尚未完成，但相较于旧库，它有了显著的改进，而且我们总得给你以后升级一个理由，对吧？ ;)
其实，先卖个关子（或者说希望能激发你提出一些解决方案），我认为 streaming lib（流式库）接下来要做的主要事情有： - 一些在不同流之间共享拥塞和 RTT（往返时延）信息的算法（按目标目的地？按源目的地？针对所有本地目的地？） - 进一步优化交互式流（当前实现的大部分关注点在批量传输流上） - 在 I2PTunnel 中更明确地使用新的 streaming lib 的特性，降低每个 tunnel 的开销。 - 客户端级带宽限制（对某个流的单向或双向，或者在多个流之间共享）。当然，这将是对 router 的整体带宽限制的补充。 - 为目的地提供各种控制，以限制它们接受或创建的流的数量（我们有一些基础代码，但基本上处于禁用状态） - 访问控制列表（仅允许来自或发往某些其他已知目的地的流） - Web 控制以及对各个流健康状况的监控，并能显式地关闭或对其进行限流
大家可能也还能想出其他点子，不过这只是我希望在 streaming lib（流式库）中看到的一些内容的简要清单，但我不会因此耽误 0.4.2 的发布。如果有人对其中任何一项感兴趣，请告诉我一声！
3) 0.4.2
那么，如果 streaming lib（流式传输库）状况良好，我们什么时候发布？当前计划是在本周末之前把它发布出去，甚至最快明天就行。还有一些其他事情我想先处理好，当然那些也需要测试，诸如此类。
0.4.2 版本中的重大变化当然是新的 streaming lib（流式库）。从 API 的角度看，它与旧的库完全相同 - I2PTunnel 和 SAM 的流会自动使用它，但从数据包的角度，它不向后兼容。这让我们陷入一个有趣的两难境地 - I2P 内并没有任何要求我们把 0.4.2 设为强制升级的东西，然而不升级的人将无法使用 I2PTunnel - 没有 eepsites(I2P Sites), 没有 IRC, 没有 outproxy, 没有电子邮件。我不想通过强迫他们升级而疏远我们的长期用户，但我也不想因为所有有用的东西都坏掉而让他们感到被疏远 ;)
不管采用哪种做法，我都持开放态度，欢迎说服。只要改一行代码就能让 0.4.2 版本不与更旧的版本通信；或者我们也可以顺其自然，让大家等到跑去网站或论坛吐槽一切都坏了的时候再升级。大家怎么看？
4) AddressBook.py 0.3.1
Ragnarok has come out with a new patch release for his address book app - see http://ragnarok.i2p/ for more info (or perhaps he can give us an update in the meeting?)
5) ???
我知道还有很多事情在进行中——比如 bittorrent 端口、susimail、slacker 的新托管服务等等。还有其他需要提出来的吗？如果有的话，约 30 分钟后来常用的 IRC 服务器上的 #i2p 频道参加会议！
=jr