여러분 안녕하세요, 늦어서 죄송합니다…

색인:

  1. 0.4
  2. Capacity and overload
  3. Website updates
  4. I2PTunnel web interface
  5. Roadmap and todo
  6. ???

1) 0.4

이미 다들 보셨겠지만, 며칠 전에 0.4 릴리스가 나왔고 전반적으로 꽤 잘 진행되고 있습니다. 0.3가 나온 지 6개월(그리고 1.0 SDK가 출시된 지 1년)이 지났다는 게 믿기지 않지만, 그동안 우리는 많은 발전을 이뤘고, 여러분 모두의 노력, 열정, 그리고 인내가 엄청난 성과를 만들어냈습니다. 축하드립니다, 그리고 감사합니다!

좋은 릴리스가 늘 그렇듯, 배포되자마자 몇 가지 문제가 드러났고 지난 며칠 동안 우리는 버그 리포트를 모으고 미친 듯이 패치해 왔습니다(고쳐지는 대로 변경 사항을 확인하실 수 있습니다). 다음 리비전을 배포하기 전에 여전히 잡아야 할 버그가 몇 가지 남아 있지만, 그 작업은 하루이틀 내에 마무리될 것입니다.

2) 용량 및 과부하

우리는 최근 몇 차례 릴리스에서 tunnels의 할당이 상당히 편향되어 있음을 보아 왔으며, 그중 일부는 버그와 관련되어 있음(그중 두 가지는 0.4가 나온 이후 수정됨)에도 불구하고, 여전히 일반적인 알고리즘에 관한 질문이 남아 있습니다 - router는 언제 더 이상의 tunnels 수락을 중단해야 할까요?

몇 번의 리비전 전에, router가 과부하 상태일 때(로컬 메시지 처리 시간이 1초를 초과할 때) tunnel에 참여하려는 요청을 거부하도록 스로틀링 코드를 추가했으며, 이는 상당한 도움이 되었다. 그러나 그 단순한 알고리즘에는 아직 다루지 못한 두 가지 측면이 있다: - 대역폭이 포화 상태여도 로컬 처리 시간은 여전히 빠를 수 있어, 더 많은 tunnel 요청을 계속 수락하게 된다 - 한 피어가 “너무 많은” tunnels에 참여할 때, 그것들이 실패하면 네트워크에 더 큰 피해를 준다.

첫 번째 문제는 대역폭 제한 기능을 단순히 활성화함으로써 비교적 쉽게 해결할 수 있습니다(대역폭 제한은 대역폭으로 인한 지연에 따라 메시지 처리 시간을 늦추기 때문입니다). 두 번째 문제는 더 복잡하며, 더 많은 연구와 더 많은 시뮬레이션이 필요합니다. 저는 네트워크에서 우리가 참여 중인 tunnel(터널)과 네트워크로부터 요청되는 tunnel의 비율을 기반으로, 기본 “kindness factor"를 포함해, 확률적으로 tunnel 요청을 거부하는 방식을 생각하고 있으며, 그 기준보다 적게 참여하고 있다면 P(reject) = 0으로 설정하는 것을 고려하고 있습니다.

하지만 앞서 말했듯이, 더 많은 작업과 시뮬레이션이 필요합니다.

3) 웹사이트 업데이트

이제 새로운 I2P 웹 인터페이스가 있으니, 예전 최종 사용자용 문서의 대부분은 사실상 더 이상 유효하지 않습니다. 그 페이지들을 살펴보고 현재 상태를 설명하도록 업데이트하는 데 도움이 필요합니다. duck와 다른 분들이 제안했듯이, http://localhost:7657/ readme를 넘어서는 새로운 ‘빠른 시작’ 가이드가 필요합니다 - 사람들이 시스템을 빠르게 시작하고 진입하도록 돕는 자료 말입니다.

또한 새 웹 인터페이스에는 문맥 인식형 도움말을 통합할 수 있는 충분한 여지가 있습니다. 함께 제공되는 help.jsp에서 볼 수 있듯이, “음. 여기에는 아마 도움말 텍스트가 있어야겠네요.”

각 페이지에 ‘about’ 및/또는 ’troubleshooting’ 링크를 추가하여, 각 요소가 무엇을 의미하는지와 어떻게 사용하는지를 설명할 수 있다면 아마도 좋을 것입니다.

4) I2PTunnel 웹 인터페이스

새로운 http://localhost:7657/i2ptunnel/ 인터페이스를 “스파르타식으로 단출하다"고 부르는 것조차 과소평가일 것이다. 이를 실사용 가능한 상태에 가깝게 만들려면 아직 손볼 일이 많다 - 현재도 기능 자체는 기술적으로 갖추어져 있지만, 그것을 제대로 이해하려면 내부에서 무엇이 어떻게 돌아가는지 알아야 한다. 이와 관련해 회의에서 duck이 추가 아이디어를 제시할 수도 있다고 생각한다.

5) 로드맵 및 할 일

로드맵을 최신 상태로 유지하는 데 그동안 좀 소홀했지만, 현실적으로 앞으로 더 손봐야 할 부분들이 있습니다. 제가 보기에는 ‘큰 문제들’을 설명하는 데 도움이 되도록, 각 항목에 대해 어느 정도의 세부 내용을 담은 새로운 작업 목록을 마련했습니다. 지금 시점에서는 선택지를 폭넓게 검토하고, 필요하다면 로드맵을 다시 손보는 데 열려 있어야 한다고 생각합니다.

그 할 일 목록에서 제가 빠뜨린 한 가지는, 경량 연결 프로토콜을 추가할 때 IP 주소 자동 감지 기능(선택 사항)을 포함할 수 있다는 점입니다. 이는 ‘위험할’ 수도 있습니다(그래서 선택 사항으로 둘 예정이지만), 우리가 받는 지원 요청의 수를 대폭 줄여 줄 것입니다 :)

어쨌든, todo 리스트에 올려둔 이 이슈들은 여러 릴리스에 걸쳐 예정해 둔 것들이고, 분명히 1.0이나 심지어 2.0에 모두 들어가지는 않을 것입니다. 몇 가지 가능한 우선순위 책정/릴리스 계획을 대략 구상해 두었지만, 아직 그것들로 굳히지는 않았습니다. 다만, 앞으로의 로드맵에서 다른 큰 사안을 찾아낼 수 있다면 매우 감사하겠습니다. 일정에 잡히지 않은 이슈는 언제나 큰 골칫거리이니까요.

6) ???

좋아요, 당장은 여기까지예요(몇 분 뒤에 회의가 시작되니 다행이네요). 더 이야기하고 싶으시면 GMT 기준 오후 9시에 다음으로 들러 주세요: irc.freenode.net의 #i2p, www.invisiblechat.com, 또는 irc.duck.i2p.