안녕, 여러분, 또다시 화요일이 돌아왔네요
- Index
- 네트워크 상태 및 0.6.1.18 2) baz 3) ???
- Net status and 0.6.1.18
또 한 주간의 테스트와 조정을 거쳐 오늘 오후 일찍 새로운 릴리스를 배포했으며, 이를 통해 개선을 진행할 수 있는 보다 안정적인 환경을 마련하게 될 것입니다. 다만 널리 배포되기 전까지는 큰 효과가 나타나지 않을 가능성이 있어 경과를 지켜보려면 며칠을 기다려야 할 수도 있지만, 측정은 물론 계속될 것입니다.
zzz가 며칠 전에 언급했던 최신 빌드와 릴리스의 한 측면은, 병렬 tunnel 수를 줄이는 동시에 백업 tunnel 수를 늘리면 상당한 효과가 있을 수 있다는 점이었다. 우리는 충분한 수의 가동 중인 tunnel이 확보될 때까지 새로운 lease(리스, leaseSet을 구성하는 항목)는 생성하지 않으므로, 가동 중인 tunnel에 장애가 발생할 경우 백업 tunnel을 신속히 투입할 수 있어 클라이언트가 활성 lease 없이 남게 되는 빈도를 줄일 수 있다. 다만 이는 증상에 대한 미세한 조정에 불과하며, 최신 릴리스는 근본 원인 해결에 도움이 될 것이다.
- baz
“baz”, bar가 기증한 새 머신이 마침내 도착했다. amd64 Turion 노트북으로 (부트 디스크에는 winxp가 있고, 외장 드라이브를 통해 몇 가지 다른 OS도 곧 준비할 예정이다). 지난 며칠 동안 이것으로도 작업하면서 몇 가지 배포 아이디어를 시험해 보고 있다. 그런데 겪고 있는 문제 중 하나는 Windows에서 gcj를 동작시키는 것이다. 좀 더 구체적으로는, 최신 gnu/classpath를 사용하는 gcj다. 소문은 꽤 부정적이다 - mingw에서 네이티브로 빌드하거나 linux에서 크로스 컴파일할 수는 있지만, 예외가 dll 경계를 넘을 때마다 세그멘테이션 폴트(segfault)가 발생하는 등의 문제가 있다고 한다. 그래서 예를 들어, java.io.File(libgcj.dll에 있음)이 예외를 던지고 그것을 net.i2p.*(libi2p.dll 또는 i2p.exe에 있음) 쪽에서 잡으면, poof, 앱이 그대로 죽는다.
음, 별로 상황이 좋지 않아 보입니다. gcj 쪽 사람들은 누군가가 참여해 win32 개발을 도와줄 수 있다면 매우 관심을 가질 텐데, 당장 실질적인 지원이 가능해 보이진 않습니다. 그래서 Windows에서는 계속 Sun JVM을 사용하는 방향으로 가야 할 것 같고, 동시에 *nix에서는 gcj/kaffe/sun/ibm/etc를 지원해야 할 것 같습니다. 그래도 그게 그렇게 나쁜 일만은 아닌 것 같네요, 어차피 JVM의 패키징과 배포에 문제가 있는 쪽은 *nix 사용자들이니까요.
- ???
오케이, 회의에 이미 늦었으니 이건 마무리하고 irc 창으로 탭을 옮겨야겠네요… 잠시 후에 봐요 ;)
=jr