안녕하세요, 여러분. 주간 업데이트 시간입니다.

색인:

  1. 0.4.1.1 status
  2. Pretty pictures
  3. 0.4.1.2 and 0.4.2
  4. Bundled eepserver
  5. ???

1) 0.4.1.1 상태

상당히 우여곡절이 많았던 0.4.1 릴리스(그리고 그에 이은 신속한 0.4.1.1 업데이트) 이후에, 네트워크가 정상으로 돌아온 것 같습니다 - 현재 50여 개의 피어가 활성화되어 있고, IRC와 eepsites(I2P Sites) 모두 접속 가능합니다. 대부분의 문제는 실험실 환경 밖에서 새로운 transport(전송 계층)를 충분히 테스트하지 못한 데서 비롯되었습니다(예: 이상한 시점에 소켓이 끊어짐, 과도한 지연 등). 다음에 해당 계층을 변경해야 할 때는, 릴리스 전에 더 폭넓게 테스트하겠습니다.

2) 보기 좋은 그림

지난 며칠 동안 CVS에서 많은 업데이트가 진행되었고, 새로 추가된 것 중 하나는 통계 로깅 컴포넌트로, /stats.jsp에서 수집된 거친 평균값을 다루는 대신 통계가 생성되는 즉시 원시 통계 데이터를 간단히 꺼내올 수 있게 해줍니다. 이를 통해 몇몇 routers에서 몇 가지 핵심 통계를 모니터링해 왔고, 남아 있는 안정성 문제를 추적하는 데 점점 더 가까워지고 있습니다. 원시 통계는 꽤 방대합니다(duck’s box에서 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건의 전송은 거의 모두 허용된 최대 재시도 횟수까지 시도되었음을 알 수 있습니다(각 시도당 10초 soft timeout, 60초 hard timeout, 최대 5회). 반면 다른 대부분의 시도는 첫 번째 또는 두 번째 시도에 성공했습니다.

또 다른 흥미로운 이미지는 client.timeout.webp로, 내가 갖고 있던 가설—메시지 전송 실패가 일종의 로컬 혼잡과 상관관계가 있다는 가설—에 상당한 의문을 제기한다. 그래프로 나타난 데이터에 따르면, 실패가 발생했을 때 수신 대역폭 사용량은 크게 변동했고, 로컬 전송 처리 시간에서 일관된 스파이크는 없었으며, 겉보기에는 tunnel 테스트 지연 시간에서도 어떠한 패턴도 보이지 않았다.

dbResponseTime.webp와 dbResponseTime2.webp 파일은 client.sendAckTime.webp와 유사하지만, 종단 간 클라이언트 메시지 대신 netDb 메시지에 해당합니다.

transport.sendMessageFailedLifetime.webp은 어떤 이유로(예: 만료 도래, 대상 피어에 도달 불가) 메시지를 실패 처리하기 전에 로컬에서 그 메시지를 얼마나 오래 보류하는지를 보여준다. 일부 실패는 피할 수 없지만, 이 이미지는 상당수가 로컬 전송 타임아웃(10초) 직후에 실패한다는 것을 보여준다. 이를 개선하기 위해 할 수 있는 몇 가지가 있다: - 먼저, 차단 목록(shitlist)을 더 적응적으로 만들 수 있다- 각 피어를 차단 목록에 올려 두는 기간을 각각 일률적으로 4분으로 고정하는 대신 지수적으로 늘리는 것이다. (이는 이미 CVS에 커밋되었다) - 둘째, 어차피 실패할 것으로 보이는 메시지는 선제적으로 실패 처리할 수 있다. 이를 위해 각 연결이 자신의 전송 속도를 추적하고, 새 메시지가 큐에 추가될 때마다 이미 큐에 쌓인 바이트 수를 전송 속도로 나눈 값이 만료까지 남은 시간을 초과하면 해당 메시지를 즉시 실패 처리한다. 또한 이 지표를 사용해 특정 피어를 통해 더 많은 tunnel 요청을 수락할지 여부를 결정할 때도 활용할 수 있다.

어쨌든, 다음 멋진 그림으로 넘어가겠습니다 - transport.sendProcessingTime.webp. 여기에서 이 특정 머신이 큰 지연의 원인이 되는 경우는 드물다는 것을 볼 수 있습니다 - 보통 10~100ms 수준이지만, 때때로 1초 이상으로 급증하는 경우도 있습니다.

tunnel.participatingMessagesProcessed.webp에 표시된 각 점은 해당 router가 참여한 tunnel을 통해 전달된 메시지의 수를 나타낸다. 이를 평균 메시지 크기와 결합하면, 다른 사용자를 위해 해당 peer(피어)가 부담하는 추정 네트워크 부하를 얻을 수 있다.

마지막 이미지는 tunnel.testSuccessTime.webp로, 메시지를 하나의 tunnel을 통해 밖으로 보내고 다른 inbound tunnel을 통해 다시 우리 쪽으로 돌아오는 데 걸리는 시간을 보여 주며, 우리의 tunnel이 얼마나 좋은지에 대한 추정치를 제공합니다.

좋습니다, 이제 예쁜 그림은 이 정도면 충분합니다. 0.4.1.1-6 이후의 릴리스에서는 router 구성 속성 “stat.logFilters"를 stat 이름의 쉼표로 구분된 목록으로 설정하여 데이터를 직접 생성할 수 있습니다 (/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 릴리스 이후로 많은 업데이트가 있었습니다(전체 목록은 변경 이력을 참조하세요). 그러나 아직 중대한 수정 사항은 없습니다. IP 자동 감지와 관련된 일부 미해결 버그를 해결한 뒤, 이번 주 후반에 예정된 다음 0.4.1.2 패치 릴리스에서 이를 배포할 예정입니다.

그 시점의 다음 주요 과제는 0.4.2를 달성하는 것이며, 이는 현재 tunnel 처리에 대한 대대적인 개편으로 예정되어 있습니다. 암호화와 메시지 처리, 그리고 tunnel 풀링을 수정해야 하므로 작업량이 상당하겠지만, 이는 매우 중요합니다. 현재로서는 공격자가 tunnel에 대해 비교적 쉽게 몇 가지 통계적 공격을 수행할 수 있기 때문입니다(예: 랜덤 tunnel 순서를 사용하는 predecessor 공격(선행자 공격) 또는 netDb 수집).

그러나 dm은 streaming lib(스트리밍 라이브러리)를 먼저 진행하는 것이 타당한지(현재 0.4.3 릴리스로 계획됨)라는 질문을 제기했다. 그렇게 하면 네트워크의 신뢰성과 처리량이 모두 개선되어 다른 개발자들이 클라이언트 앱 개발에 뛰어들도록 장려할 수 있다. 그게 자리 잡으면, 그때는 tunnel 개편으로 돌아가 (사용자에게 보이지 않는) 보안 이슈를 해결할 수 있다.

기술적으로는, 0.4.2와 0.4.3에 계획된 두 작업은 서로 독립적이며, 어차피 둘 다 진행될 것이므로 그 순서를 바꾼다 해도 큰 단점은 없어 보입니다. 저도 dm의 의견에 동의하는 편이고, 누군가 0.4.2를 tunnel 업데이트로, 0.4.3을 스트리밍 라이브러리로 유지해야 할 이유를 제시하지 않는 한, 그 둘을 맞바꾸겠습니다.

4) 번들된 eepserver

0.4.1 릴리스 노트에서 언급했듯이, eepsite(I2P 사이트)를 바로 실행할 수 있도록 필요한 소프트웨어와 설정을 함께 번들로 제공했습니다 - ./eepsite/docroot/ 디렉터리에 파일만 넣고 router 콘솔에서 확인한 I2P destination을 공유하면 됩니다.

하지만 .war 파일에 대한 제 열정에 대해 몇몇 분들이 지적하셨습니다 - 불행히도 대부분의 앱은 단순히 파일을 ./eepsite/webapps/ 디렉터리에 넣는 것만으로는 충분하지 않고 약간의 추가 작업이 필요합니다. 저는 blojsom 블로깅 엔진을 실행하는 방법에 대한 간단한 튜토리얼을 준비했고, 그것이 어떤 모습인지 detonate의 사이트에서 확인하실 수 있습니다.

5) ???

지금으로서는 이 정도가 전부입니다 - 논의하고 싶다면 90분 후 회의에 잠깐 들러 주세요.

=jr