안녕 여러분, 또 화요일이네
색인
- 0.4.1.3
- Tunnel test time, and send processing time
- Streaming lib
- files.i2p
- ???
1) 0.4.1.3
0.4.1.3 릴리스가 하루나 이틀 전에 나왔고, 대부분의 사용자가 업그레이드한 것으로 보입니다(감사합니다!). 네트워크는 꽤 잘 작동하고 있지만, 신뢰성에서 혁신적인 향상은 아직 없습니다. 다만 0.4.1.2의 watchdog(감시 타이머) 버그는 사라졌습니다(적어도 아무도 언급하지 않았습니다). 제 목표는 이번 0.4.1.3 릴리스를 0.4.2 이전의 마지막 패치로 만드는 것이지만, 물론 수정이 필요한 큰 문제가 생기면 한 번 더 내놓을 것입니다.
2) Tunnel 테스트 시간 및 전송 처리 시간
0.4.1.3 릴리스에서 가장 중요한 변경 사항은 tunnel 테스트에 관한 것이었습니다 - 고정된 (30초!) 테스트 기간을 두는 대신, 측정된 성능을 바탕으로 한 훨씬 더 공격적인 타임아웃을 사용하게 되었습니다. 이는 좋습니다. 이제는 tunnel이 유용한 작업을 수행하기에는 너무 느릴 때 실패로 표시하기 때문입니다. 그러나 이는 나쁠 수도 있습니다. 때때로 tunnel이 일시적으로 적체되고, 그 기간에 테스트하면 원래라면 정상 동작할 tunnel을 실패로 처리할 수 있기 때문입니다.
단일 router에서 tunnel 테스트에 소요되는 시간을 보여주는 최근의 그래프:
이는 일반적으로 양호한 tunnel 테스트 시간입니다 - 2 홉 tunnel의 경우 4개의 원격 피어를 거치므로, 대부분은 홉당 ~1-200ms 정도가 걸립니다. 하지만 보시다시피 항상 그런 것은 아닙니다 - 때때로 홉당 수 초가 걸리기도 합니다.
바로 다음 그래프가 이를 보여 줍니다 - 특정 router가 메시지를 보내려 했던 시점부터 그 메시지가 소켓으로 플러시되어 나갈 때까지의 큐 대기 시간:
대략 상위 95%는 50ms 이하이지만, 스파이크가 치명적이다.
그런 스파이크를 없애야 하며, 더 많은 피어가 실패하는 상황에서도 우회하여 동작할 수 있어야 한다. 현재로서는, 어떤 피어가 우리의 여러 tunnel을 실패하게 만든다는 사실을 ‘알게 될’ 때에도, 사실 그들의 router에 특정한 무언가를 배우는 것은 아니다 - 운 나쁘게 그 타이밍을 맞닥뜨리면 그런 스파이크 때문에 고용량 피어조차 느려 보일 수 있다.
3) 스트리밍 라이브러리
실패하는 tunnel(익명 통신 경로) 문제를 우회하는 두 번째 부분은 스트리밍 라이브러리에 의해 부분적으로 해결되며, 이를 통해 훨씬 더 견고한 종단 간 스트리밍 통신을 제공하게 됩니다. 이 논의는 새로운 것이 아니며, 그 라이브러리는 우리가 한동안 이야기해 온 온갖 멋진 기능들을 수행할 것입니다(물론 그만큼 버그도 있을 겁니다). 이와 관련해 상당한 진전이 있었고, 구현은 아마 60% 정도까지 진행되었습니다.
추가 소식은 있는 대로 알려드리겠습니다.
4) files.i2p
좋아요, 요즘 새로운 eepsites(I2P 사이트)가 많이 생겼는데, 정말 끝내줍니다. 그중에서도 특히 이걸 언급하고 싶은데, 우리 모두에게 꽤 멋진 기능이 있거든요. 아직 files.i2p에 가보지 않았다면, 기본적으로 Google 같은 검색 엔진이고, 크롤링한 사이트들의 캐시가 있습니다(그래서 eepsite(I2P 사이트)가 오프라인일 때도 검색하고 둘러볼 수 있습니다). 아주 멋져요.
5) ???
이번 주 상태 메모는 꽤 짧지만, 진행 중인 일은 많습니다 — 회의 전에 더 쓸 시간이 없을 뿐이에요. 그러니 몇 분 뒤에 #i2p에 들러 주시면 제가 부주의하게 놓친 것이 무엇이든 함께 논의해 봅시다.
=jr