大家好，又到了每周更新时间啦
索引:
- 0.4.1.1 status
- Pretty pictures
- 0.4.1.2 and 0.4.2
- Bundled eepserver
- ???
1) 0.4.1.1 状态
在一次颇为波折的 0.4.1 版本发布（以及随后迅速推出的 0.4.1.1 更新）之后，网络似乎已恢复正常——目前有五十多个对等节点处于活跃状态，irc 和 eepsites(I2P Sites) 都可以访问。大部分问题源于在非实验室条件下对新传输层的测试不足（例如套接字在奇怪的时机断开、过高的延迟等）。下次我们需要在该层进行更改时，我们一定会在发布前更广泛地进行测试。
2) 漂亮的图片
在过去几天里，CVS 中进行了一大批更新，其中新增的一项是一个新的统计日志组件，使我们可以在数据生成时就直接提取原始统计数据，而不是去处理 /stats.jsp 上收集到的粗糙平均值。借助它，我一直在几台 routers 上监控几个关键统计指标，我们正逐步接近定位剩余的稳定性问题。原始统计数据相当臃肿（在 duck 的机器上运行 20 小时就生成了将近 60MB 的数据），不过这也正是我们准备了漂亮图表的原因——http://dev.i2p.net/~jrandom/stats/
其中大多数图的 Y 轴为毫秒，X 轴为秒。有几点值得注意。首先，client.sendAckTime.webp 对单次往返延迟的近似程度相当不错，因为 ack 消息（确认消息）与有效载荷一起发送，随后沿着 tunnel 的完整路径返回；因此，在将近 33,000 条成功发送的消息中，绝大多数的往返时间低于 10 秒。随后将 client.sendsPerFailure.webp 与 client.sendAttemptAverage.webp 结合查看可以发现，563 次发送失败几乎都达到了我们允许的最大重试次数（5 次，每次尝试的软超时为 10 秒、硬超时为 60 秒），而其他大多数尝试在第一次或第二次就成功了。
另一个有趣的图是 client.timeout.webp，它让我的一个假设——消息发送失败与某种本地拥塞相关——大打问号。绘制的数据表明，失败发生时入站带宽使用情况变化很大，本地发送处理时间并未出现一致性的峰值，而且与 tunnel 测试延迟似乎完全没有任何规律。
文件 dbResponseTime.webp 和 dbResponseTime2.webp 与 client.sendAckTime.webp 类似，只是它们对应的是 netDb 消息，而不是端到端的客户端消息。
transport.sendMessageFailedLifetime.webp 展示了在我们因某些原因将一条消息判定为失败之前（例如达到过期时间，或其目标对等节点不可达），该消息在本地被保留了多长时间。有些失败是不可避免的，但该图显示，有相当数量的消息在本地发送超时（10s）后立刻失败。我们可以从几个方面着手应对这一情况： - 首先，我们可以让 shitlist（黑名单）更加自适应——不再为每次固定的 4 分钟，而是按指数方式增加某个对等节点被列入 shitlist 的时长。（这已经提交到 CVS） - 其次，我们可以在看起来无论如何都会失败时预先判定消息失败。为此，我们让每个连接跟踪其发送速率，并且每当有新消息加入其队列时，如果已排队的字节数除以发送速率超过距离过期剩余的时间，就立即将该消息判定为失败。我们也可以在决定是否通过某个对等节点再接受更多的 tunnel 请求时使用这一指标。
总之，来看下一张漂亮的图——transport.sendProcessingTime.webp。在这张图中你会看到，这台特定机器很少会造成较大的延迟——通常为10-100ms，但偶尔会飙升到1s或更高。
tunnel.participatingMessagesProcessed.webp 中绘制的每个点表示该 router 参与的某条 tunnel 中转了多少条消息。将其与平均消息大小结合起来，就可以估算出该对等节点为他人承担的网络负载。
最后一张图是 tunnel.testSuccessTime.webp，它显示通过一条 tunnel（隧道）将消息发送出去，再通过另一条 inbound tunnel 返回本地所需的时间，从而让我们对 tunnel 的质量有一个估计。
好了，这些漂亮的图片就先到这里。你可以在 0.4.1.1-6 之后的任何发行版中自己生成这些数据，只需将 router（路由节点）配置属性 “stat.logFilters” 设为一个以逗号分隔的统计项名称列表（名称可从 /stats.jsp 页面获取）。这些内容会被写入 stats.log，你可以用来处理它
java -cp lib/i2p.jar net.i2p.stat.StatLogFilter stat.log
它会将其拆分为针对每个统计项的独立文件，便于加载到你喜爱的工具中（例如 gnuplot）。
3) 0.4.1.2 和 0.4.2
自 0.4.1.1 发布以来已有大量更新（完整列表请参见历史记录），但尚无关键性修复。我们计划在本周晚些时候的下一个 0.4.1.2 补丁发布中推出这些更新，待与 IP 自动检测相关的一些尚未解决的缺陷得到处理之后。
届时，下一个主要任务将是达成 0.4.2，该版本目前计划对 tunnel 处理进行重大改造。这将是一项繁重的工作，需要修订加密和消息处理，以及 tunnel 池，但这相当关键，因为目前攻击者能够相当容易地对 tunnel 发动一些统计攻击（例如，predecessor（前驱攻击）配合随机的 tunnel 排序，或 netDb 收集）。
不过，dm 提出了一个问题：是否先做 streaming lib（流式库）更为合理（目前计划在 0.4.3 版本中发布）。这样做的好处是网络将变得更可靠，吞吐量也会更好，从而鼓励其他开发者开始动手开发客户端应用。在那到位之后，我就可以回到 tunnel 改造上，解决（对用户不可见的）安全问题。
从技术角度讲，为 0.4.2 和 0.4.3 规划的这两项任务彼此独立，而且无论如何都会完成，所以把它们对调似乎并没有什么坏处。我倾向于同意 dm 的看法，除非有人能提出让 0.4.2 仍然作为 tunnel 更新、0.4.3 作为 streaming 库（流式传输库）的理由，我们就把它们对调。
4) 随附的 eepserver
正如在 0.4.1 发行说明中提到的，我们已经将运行 eepsite(I2P Site) 所需的软件和配置打包为开箱即用——你只需将一个文件放入 ./eepsite/docroot/ 目录，并分享在 router 控制台上找到的 I2P destination（I2P 目标地址）。
不过，也有几个人指出我对 .war 文件的热衷过了头——不幸的是，大多数应用需要的不仅仅是把一个文件放进 ./eepsite/webapps/ 目录，还要多做一些工作。我整理了一份关于运行 blojsom 博客引擎的简要教程，你可以在 detonate 的站点上看看实际效果。
5) ???
目前我就这些了——如果你想讨论，90 分钟后来参加会议吧。
=jr