大家好，新年快乐！在停更一周之后，让我们重新回到我们的每周状态更新——
- Index
- 网络状态与 0.6.1.8 2) 负载测试结果与对等节点画像 3) 2005 回顾 / 2006 展望 / ???
- Net status and 0.6.1.8
前几周我们发布了 0.6.1.8，来自一线的报告称 zzz 的修改帮了大忙，尽管最近网络流量大幅增加（根据 stats.i2p，过去一个月的平均值似乎翻了一倍），网络上的情况看起来仍然相当稳定。 I2PSnark 看起来也运行得相当不错——虽然我们遇到了一些小问题，但在后续构建中我们已经定位并修复了其中的大部分。 关于 Syndie 的新博客界面，目前反馈不多，不过 Syndie 的流量有所上升 (部分原因是 protocol 发现了 dust 的 rss/atom 导入器 :)
- Load testing results and peer profiling
过去几周里，我一直在试图定位我们的吞吐量瓶颈。不同的软件组件实际上都能够以远高于我们通常在 I2P 端到端通信中看到的速率推送数据，因此我在真实网络上使用自定义代码对它们进行基准测试和压力测试。第一组测试是通过网络中的所有 router 构建一跳入站 tunnel，并尽快通过该 tunnel 传输数据，结果相当可观：这些 router 的处理速率大致在其应有能力的范围内（例如，大多数的长期平均只有 4–16 KBps，但也有一些能在单个 tunnel 上达到 20–120 KBps）。这一测试为进一步探索提供了良好的基线，并表明 tunnel 的处理本身能够推动的吞吐量远高于我们通常所见。
尝试通过实际运行中的 tunnels 复现那些结果并不那么成功。或者，也可以说更成功，因为它们显示出的吞吐量与我们目前看到的类似，这意味着我们找对了方向。回到 1 跳测试结果，我修改了代码，选择我手动识别为快速的对等节点，并使用这种"作弊式"的对等节点选择，通过实际运行中的 tunnels 重新运行了负载测试；虽然没有达到 120KBps 的水平，但确实显示出了合理的改进。
不幸的是，要求人们手动选择其节点在匿名性以及——嗯——易用性方面都会带来严重问题，不过借助负载测试数据，似乎有了出路。过去几天，我一直在测试一种按速度为节点画像的新方法——与其关注其近期延迟，不如监测其可持续的峰值吞吐量。朴素的实现已经相当成功，尽管它选出的节点并不完全等同于我手动会选的那些，但效果相当不错。不过它仍有一些需要打磨的地方，例如确保我们能够将探索型 tunnels（隧道）提升到快速层级，不过我目前正在这方面做一些实验。
总体来说，我认为我们本轮吞吐量优化已接近尾声，因为我们正在对最狭窄的瓶颈施压并将其拓宽。我确信我们很快会遇到下一个瓶颈，而且这肯定不会让我们达到普通互联网的速度，但应该会有所帮助。
- 2005 review / 2006 preview / ???
说 2005 年取得了巨大突破都有点轻描淡写了 - 我们在去年的 25 个发布中从多方面改进了 I2P，使网络规模增长了 5 倍，部署了数个新的客户端应用 (Syndie, I2Phex, I2PSnark, I2PRufus)，迁移到了 postman 和 cervantes 的新 irc2p IRC 网络，并见证了一些有用的 eepsites(I2P Sites) 蓬勃发展 (例如 zzz 的 stats.i2p、orion 的 orion.i2p，以及 tino 的代理和监控服务，仅举几例)。社区也更加成熟了不少，这在很大程度上要归功于 Complication 以及其他人在论坛和频道中的支持工作，而且来自各个领域的 Bug 报告的质量和多样性都有了显著提升。社区内持续的财务支持令人印象深刻，尽管它尚未达到实现完全可持续开发所需的水平，但我们确实有一笔缓冲资金，足以让我撑过这个冬天。
向过去一年中在技术、社交或财务方面参与的所有人，感谢你们的帮助！
2006 对我们来说将是重要的一年：0.6.2 将在今冬发布，1.0 计划在春季或夏季的某个时候发布，2.0 则在秋季（如果不是更早的话）。今年我们将检验自己的能力，而且在应用层的工作将比以往更加关键。所以如果你有一些想法，现在就是开始行动的时候 :)
总之，我们的每周状态会议再过几分钟就要开始了，所以如果你有想进一步讨论的内容，欢迎到常用的地方的 #i2p 频道 [1] 来打个招呼！