안녕하세요 여러분, 주간 업데이트 시간이에요

  • Index
  1. 0.5 2) 다음 단계 3) azneti2p 4) ???
    1. 0.5

여러분도 들으셨겠지만, 마침내 0.5를 출시했고, 대체로 잘 작동하고 있습니다. 업데이트를 빠르게 해주신 점에 정말 감사드립니다 - 첫날 안에 네트워크의 50-75%가 0.5로 올라갔습니다! 빠른 도입 덕분에 여러 변경 사항의 영향을 더 빨리 파악할 수 있었고, 그 과정에서 상당수의 버그도 발견했습니다. 아직 해결해야 할 이슈가 몇 가지 남아 있지만, 가장 중요한 것들을 해결하기 위해 오늘 늦은 저녁에 새로운 0.5.0.1 릴리스를 배포할 예정입니다.

버그의 부수 효과로, routers가 수천 개의 tunnels을 처리할 수 있다는 걸 보니 꽤 멋지더군요 ;)

    1. Next steps

0.5.0.1 릴리스 이후에는 탐색용 tunnel 구축과 관련된 몇 가지 변경을 실험하기 위해 추가 빌드가 하나 더 나올 수 있습니다(예: 모든 피어를 실패하지 않는 피어로 구성하는 대신, 실패하지 않는 피어는 한두 개만 사용하고 나머지는 고용량 피어로 구성). 그 다음에는 0.5.1로 나아갈 예정이며, 이는 여러 개의 작은 메시지를 하나의 tunnel 메시지로 배치해 묶음으로써 tunnel 처리량을 향상시키고, 사용자가 predecessor attack(선행자 공격)에 대한 자신의 취약성에 대해 더 많은 제어권을 가질 수 있도록 할 것입니다.

이러한 제어는 클라이언트별 피어 정렬 및 선택 전략의 형태를 취할 것이며, 인바운드 게이트웨이와 아웃바운드 엔드포인트에 하나, 그리고 tunnel의 나머지 부분에 하나가 적용됩니다. 현재 내가 예상하는 전략의 개요: = random (지금 우리가 사용하는 방식) = balanced (각 피어의 사용 빈도를 명시적으로 줄이려 시도) = strict (한 번이라도 A–>B–>C를 사용했다면, 이후의 tunnel에서도 그 순서를 유지 [시간으로 제한됨]) = loose (클라이언트를 위해 무작위 키를 생성하고, 그 키와 각 피어에 대해 XOR을 계산한 다음, 그 키와의 거리 기준으로 선택된 피어들을 항상 정렬 [시간으로 제한됨]) = fixed (MBTF마다 항상 동일한 피어를 사용)

어쨌든 그게 계획이지만, 어떤 전략이 먼저 도입될지는 잘 모르겠습니다. 제안은 언제든지 환영합니다 :)

    1. azneti2p

azureus 쪽 사람들은 여러 차례 업데이트를 내놓느라 열심히 작업해왔고, 최신 b34 snapshot [1]에는 I2P 관련 버그 수정이 몇 가지 포함된 듯합니다. 제가 마지막으로 제기했던 익명성 문제 이후로는 소스 코드를 검토할 시간이 없었지만, 그 특정 버그는 고쳐졌으니, 모험심이 있으시다면 업데이트를 받아서 한번 써보세요!

[1] http://azureus.sourceforge.net/index_CVS.php

    1. ???

정말 많은 일들이 진행 중이고, 제가 아직 다 다루지 못했을 거예요. 몇 분 뒤 회의에 잠깐 들러서 무슨 일이 있는지 확인해 보세요!

=jr