嗨，大家，又是星期二了
索引
- 0.4.1.3
- Tunnel test time, and send processing time
- Streaming lib
- files.i2p
- ???
1) 0.4.1.3
0.4.1.3 版本在一两天前发布了，看起来大多数人已经升级了（谢谢！）。网络运行得相当好，但可靠性还没有出现革命性的提升。不过，0.4.1.2 中的 watchdog（看门狗）相关 bug 已经消失了（至少目前没人再提到它们）。我的目标是让这个 0.4.1.3 版本成为 0.4.2 之前的最后一个补丁，不过当然，如果出现需要修复的重大问题，我们还会再发一个。
2) Tunnel test time, and send processing time
0.4.1.3 版本中的最重要变更在于 tunnel 测试：我们不再使用固定的（30 秒！）测试周期，而是采用由实测性能推导出的更为激进的超时设置。这样很好，因为当 tunnel 慢到无法完成任何有用工作时，我们现在会将其标记为失败。不过，这也有不利之处，因为有时 tunnel 会暂时拥塞，如果我们恰好在那段时间进行测试，就会把本来可以正常工作的 tunnel 判定为失败。
最近的图表，展示在单个router上完成一次tunnel测试所需的时间：
这些 tunnel 测试时间总体上还可以——它们会经过 4 个远程对等节点（使用 2 跳 tunnels），因此大多数情况下每跳约 ~1-200 毫秒。不过，情况并非总是如此，正如你所见——有时每跳会达到秒级。
这正是下一张图所要说明的——从某个特定 router 想要发送一条消息的时刻，到该消息被刷新到套接字时为止的排队时间：
大约95%都低于50毫秒，但那些尖峰要命。
我们需要消除这些尖峰，并设法在出现更多对等节点失败的情况下加以规避。就目前而言，当我们“了解到”某个对等节点导致我们的 tunnels 失败时，我们其实并没有了解到任何与其 router 特有的内容——如果我们正好碰上，这些尖峰甚至会让高容量的对等节点看起来很慢。
3) 流式传输库
绕过失效的 tunnels 的第二部分工作将部分通过 streaming lib（流式传输库）来实现 - 从而为我们提供更为健壮的端到端流式通信。这个话题并不新鲜 - 该 lib 将实现我们讨论已久的所有高级功能（当然，它也会有自己的一些 bug）。在这方面已经取得了很大进展，实现可能已经完成了约60%。
有更多消息时我们会再更新。
4) files.i2p
好的，最近我们涌现了很多新的 eepsites(I2P Sites)，这真是太棒了。我想特别提一下这一个，因为它为我们其他人提供了一个相当巧妙的功能。要是你还没去过 files.i2p，它基本上是一个类似 Google 的搜索引擎，并且会缓存它爬取到的站点（所以当该 eepsite(I2P Site) 离线时，你既可以搜索也可以浏览）。真酷。
5) ???
本周的状态笔记相当简短，但事情很多——在会议前我实在没时间写更多。再过几分钟到 #i2p 来一趟，我们可以讨论我愚蠢地遗漏的任何内容。
=jr