大家好，星期二又到了。

  • Index
  1. 网络状态和 0.6.1.18 2) baz 3) ???
    1. Net status and 0.6.1.18

在又进行了一周的测试和微调之后，我们在今天下午稍早发布了一个新版本，这应该能让我们进入一个更稳定的环境，从而在此基础上进行改进。不过，在广泛部署之前我们可能看不到太多效果，因此可能需要再等几天看看情况如何，但各项测量当然会持续进行。

zzz 前几天提到的关于最新构建与发布的一个方面是：在减少并行 tunnel 数量的同时增加备份 tunnel 的数量，目前这样做会产生显著影响。我们在拥有足够数量的可用 tunnel 之前，不会建立新的 lease（租约），因此，一旦某条可用 tunnel 发生故障，备份 tunnel 可以迅速启用，从而降低客户端处于没有有效 lease 的状态的频率。不过，这只是对症状的微调，最新的发布应该有助于解决根本原因。

    1. baz

“baz”，bar 捐赠的新机器终于到了，一台 AMD64 Turion 笔记本电脑（启动盘上装着 Windows XP，通过外置硬盘还准备装上其他几个操作系统）。这几天我也一直在折腾它，尝试在上面测试几个部署思路。不过我遇到的一个问题是，让 gcj 在 Windows 上跑起来。更具体地说，是要一个带有较新 gnu/classpath 的 gcj。坊间的说法并不乐观——据说可以在 mingw 下原生构建，或者从 linux 交叉编译，但存在这样的问题：只要有异常跨过 DLL 边界就会发生 segfault（段错误）。所以，比如，如果 java.io.File（位于 libgcj.dll）抛出一个异常，而该异常被 net.i2p.*（位于 libi2p.dll 或 i2p.exe）中的代码捕获，poof，应用就崩溃了。

嗯，看起来形势不太乐观。如果有人能加入并协助 win32（Windows 32 位平台）开发，gcj（GNU Compiler for Java）那边会非常感兴趣，但可行的支持短期内似乎不太可能到来。所以，我们看来得计划在 Windows 上继续使用 Sun JVM，同时在 *nix（类 Unix 系统）上支持 gcj/kaffe/sun/ibm/etc。倒也不算太糟，毕竟在打包和分发 JVM 时遇到问题的是 *nix 用户。

    1. ???

好吧，我开会已经迟到了，我想该把这边先收个尾，然后切到 irc 窗口了……一会儿见 ;)

=jr