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

색인:

  1. New transport
  2. 0.4.1 status
  3. ???

1) 새 트랜스포트

0.4.1 릴리스는 예상보다 시간이 더 걸리고 있지만, 새 전송 프로토콜과 구현이 계획된 모든 것—IP 탐지, 오버헤드가 낮은 연결 설정, 연결이 실패할 때 디버깅을 돕는 더 쉬운 인터페이스—을 갖춘 상태로 마련되어 있습니다. 이는 이전 전송 프로토콜을 완전히 버리고 새 것을 구현함으로써 이루어졌지만, 여전히 같은 버즈워드(2048bit DH + STS, AES256/CBC/PKCS#5)는 그대로입니다. 프로토콜을 검토하고 싶다면 문서에 있습니다. 또한 이전 버전이 지난 1년 동안 누적된 업데이트들의 묶음에 불과했던 것과 달리, 새 구현은 훨씬 더 깔끔합니다.

어쨌든, 새로운 IP 감지 코드와 관련해 언급할 만한 몇 가지 사항이 있습니다. 가장 중요한 점은 전적으로 선택 사항이라는 것입니다. 설정 페이지(또는 router.config 자체)에 IP 주소를 지정하면 어떤 경우에도 항상 그 주소를 사용합니다. 하지만 그 값을 비워 두면, router는 처음으로 접촉한 피어가 자신의 IP 주소가 무엇인지 알려주도록 허용하며, 그러면 그 주소를 자신의 RouterInfo에 추가하고 네트워크 데이터베이스(netDb)에 등록한 뒤 해당 주소에서 수신 대기를 시작합니다. 사실, 이것이 전적으로 정확한 건 아닙니다. IP 주소를 명시적으로 설정하지 않은 경우, 피어 연결이 전혀 없을 때마다 어떤 피어든 자신이 도달 가능한 IP 주소를 알려주는 것을 신뢰합니다. 따라서 인터넷 연결이 재시작되어 새 DHCP 주소를 받게 되는 경우, router는 도달 가능한 첫 번째 피어를 신뢰합니다.

네, 이제 dyndns는 더 이상 필요하지 않습니다. 물론 계속 사용하셔도 되지만, 필수는 아닙니다.

하지만 이것만으로는 원하는 모든 것을 할 수 없습니다 - NAT 또는 방화벽이 있다면, 외부 IP 주소를 아는 것만으로는 문제의 절반만 해결될 뿐이며 - 여전히 인바운드 포트를 위한 포트 포워딩을 설정해야 합니다. 하지만 시작은 됩니다.

(참고로, 자신만의 사설 I2P 네트워크나 시뮬레이터를 운영하는 분들을 위해, 새로 설정해야 하는 플래그 쌍인 i2np.tcp.allowLocal 및 i2np.tcp.tagFile가 있습니다)

2) 0.4.1 상태

0.4.1 로드맵에 있는 항목들 외에도, 버그 수정과 네트워크 모니터링 업데이트를 몇 가지 더 포함하고 싶습니다. 현재 과도한 메모리 할당/해제 문제를 추적하고 있고, 네트워크에서 간헐적으로 나타나는 신뢰성 문제에 대한 몇 가지 가설도 검증해 보려 합니다. 그래도 곧 릴리스를 배포할 준비가 될 것이며, 아마 목요일쯤이 될 겁니다. 안타깝게도 이번 버전은 하위 호환되지 않아 다소 거칠 수 있지만, 새로운 업그레이드 프로세스와 더 관대한 transport implementation(전송 계층 구현) 덕분에 이전의 하위 호환되지 않았던 업데이트들만큼 나쁘지는 않을 것입니다.

3) ???

네, 지난 2주 동안은 짧은 업데이트만 있었는데, 그건 여러 고수준 설계보다는 구현에 집중하느라 현장에서 분투하고 있었기 때문입니다. 프로파일링 데이터 얘기를 하거나, 새로운 transport(전송 계층)를 위한 10,000개 규모의 연결 태그 캐시에 대해 말할 수도 있지만, 그게 그렇게 흥미롭진 않죠. 그래도 여러분이 추가로 논의할 내용이 있을 수 있으니, 오늘 밤 회의에 들러서 마음껏 이야기해 주세요.

=jr