大家好，又到星期二了，该发布我们的每周状态简报了。

  • Index
  1. 网络状态与0.6.1.16 2) Tunnel 创建与拥塞 3) Feedspace 4) ???
    1. Net status and 0.6.1.16

随着网络已有 70% 升级到 0.6.1.16，我们似乎已经看到了相比早期版本的改进；并且，随着该版本中的问题得到修复，我们对下一个瓶颈也有了更清晰的认识。对于尚未升级到 0.6.1.16 的用户，请尽快升级，因为较早的版本会随意拒绝 tunnel 创建请求（即使该 router 具备参与更多 tunnel 的充足资源）。

    1. Tunnel creation and congestion

现在，我们似乎正经历一种或许最恰当可称为拥塞崩溃的情况 - 由于 routers 的带宽不足，tunnel 创建请求被拒绝，于是为了寻找有空闲资源的其他 routers，会发送更多的 tunnel 创建请求，结果只会增加带宽占用。这个问题自从我们在 0.6.1.10 中切换到新的 tunnel 创建加密算法以来就一直存在，并且在很大程度上与这样一个事实有关：在请求和回复穿越两条 tunnel 的全程之前（更准确地说，除非 请求和回复已经穿越了两条 tunnel 的全程），我们得不到逐跳的加入/拒绝反馈。如果这些节点中的任何一个未能继续传递该消息，我们就不知道是哪一个节点失败了、哪些节点同意了、以及哪些节点明确拒绝了。

我们已经限制了在途的并发 tunnel 创建请求数量（测试表明增加超时时间并无帮助），因此 Nagle 的传统方案并不足够。现在我正在对我们的请求处理代码做一些调整，以降低请求被静默丢弃（相对于显式拒绝）的频率；同时也在请求生成代码上做改动，以在负载下降低并发度。我还在尝试一些其他改进，它们能够显著提高 tunnel 构建成功率，不过这些尚未达到可安全使用的程度。

我们已经在 tunnel（隧道）尽头看到了曙光，感谢大家在我们推进过程中保持耐心并一路相随。我预计我们会在本周晚些时候再发布一个版本，以推送部分改进，之后我们将重新评估网络的状态，以确定拥塞崩溃是否已得到缓解。

    1. Feedspace

Frosk 一直埋头于 Feedspace 的开发，并在 Trac 站点上更新了几页内容，包括一份新的概览文档、一组待办任务、一些数据库细节等。顺道去 http://feedspace.i2p/ 看看，了解最新的变化，也许还能在你方便的时候尽情向 Frosk 抛出问题 :)

    1. ???

目前我能讨论的大概就这些，不过请到 #i2p 参加我们今晚稍晚（8pm UTC）的会议，再多聊聊！

=jr