안녕하세요, 여러분. 또 화요일이 돌아온 것 같네요

  • Index
  1. 네트워크 상태 2) 처리량 프로파일링 3) Syndie 블로그 4) HTTP 지속 연결 5) I2Phex gwebcache 6) ???
    1. Net status

지난주에는 CVS에서 많은 버그 수정과 개선이 진행되었고, 현재 빌드는 0.6.1.8-11입니다. 네트워크는 비교적 안정적이었으나, 여러 I2P 서비스 제공업체의 장애로 인해 간헐적인 문제가 발생하기도 했습니다. 마침내 CVS에서 불필요하게 높았던 router identity churn(router 식별자가 자주 바뀌는 현상)을 없앴고, 어제 zzz가 코어에 제안한 새로운 버그 수정도 꽤 유망해 보이지만, 그 영향은 좀 더 지켜봐야 합니다. 지난주에 진행된 다른 큰 작업으로는 새로운 처리량 기반 속도 프로파일링과 Syndie의 블로그 보기 기능에 대한 대대적인 작업이 있었습니다. 0.6.1.9는 이번 주 후반쯤, 늦어도 주말까지는 공개될 예정입니다. 평소 확인하시는 채널을 계속 주시해 주세요.

    1. Throughput profiling

우리는 처리량을 모니터링하기 위한 몇 가지 새로운 피어 프로파일링 알고리즘을 테스트해 왔지만, 지난 일주일 정도 사이에 꽤 좋아 보이는 하나로 정착한 것으로 보입니다. 본질적으로, 이는 개별 tunnel의 확인된 처리량을 1분 간격으로 모니터링하고, 그에 따라 피어의 처리량 추정치를 조정합니다. tunnel에는 여러 피어가 포함되어 있고 확인된 처리량 측정에도 종종 여러 tunnel이 필요하므로, 피어의 평균 속도를 계산하려고 하지는 않습니다. 그렇게 하는 일은 매우 복잡하기 때문입니다. 대신 평균 피크 속도를 산출합니다 - 구체적으로는, 그 피어의 tunnel들이 전송할 수 있었던 가장 빠른 세 가지 속도를 측정해 그것들의 평균을 냅니다.

요지는, 이 속도들은 1분 전체에 걸쳐 측정되므로 해당 피어가 지속적으로 낼 수 있는 지속 가능한 전송 속도이며, 모든 피어는 최소한 종단 간 측정된 속도만큼은 빠르기 때문에 각각을 그만큼 빠르다고 표시해도 안전하다는 것입니다. 우리는 여기에 또 다른 변형을 시도해 보았는데—서로 다른 기간에 tunnels을 통해 피어의 전체 처리량을 측정하는 방식으로—이는 피크 속도 정보를 더욱 명확하게 제공했지만, 이미 “fast"로 표시되지 않은 피어들에게 크게 불리하게 작용했습니다. 이는 “fast” 피어들이 훨씬 더 자주 사용되기 때문입니다(클라이언트 tunnels는 fast 피어만 사용). 그와 같은 전체 처리량 측정의 결과는, 충분히 부하가 가해진 대상에 대해서는 훌륭한 데이터를 수집했지만, 실제로 충분한 부하가 가해진 것은 fast 피어들뿐이었고 효과적인 탐색은 거의 이루어지지 않았습니다.

그러나 1분 주기와 개별 tunnel의 처리량을 사용하면 더 합리적인 값이 나오는 것으로 보입니다. 다음 릴리스에서 이 알고리즘이 배포될 예정입니다.

    1. Syndie blogs

몇 가지 피드백을 바탕으로 Syndie의 블로그 보기에서 추가 개선이 이루어져, 뉴스그룹/포럼과 같은 스레드형 보기와는 확연히 다른 느낌을 주게 되었습니다. 또한 기존 Syndie 아키텍처를 통해 일반적인 블로그 정보를 정의할 수 있는 완전히 새로운 기능이 추가되었습니다. 예시로 기본 “about Syndie” 블로그 게시물을 확인해 보세요: http://syndiemedia.i2p.net/blog.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800001

이는 우리가 할 수 있는 일의 시작만을 살짝 건드린 것에 불과합니다. 다음 릴리스에서는 자신의 블로그 로고, 자신만의 링크(블로그, 게시물, 첨부파일, 임의의 외부 URL)를 직접 정의할 수 있게 되며, 바라건대 더 많은 커스터마이징도 가능해질 것입니다. 그중 하나의 커스터마이징은 태그별 아이콘입니다 - 표준 태그에서 사용할 기본 아이콘 세트를 제공하고 싶지만, 사람들은 자신의 블로그 내에서 사용할 자신만의 태그 아이콘을 정의할 수 있고, 심지어 표준 태그의 기본 아이콘을 재정의할 수도 있을 것입니다(다시 한 번 말하지만, 물론 사람들이 자신의 블로그를 볼 때에만 해당합니다). 아마도 서로 다른 태그를 가진 게시물을 다르게 표시하기 위한 스타일 설정도 포함될 수 있습니다(물론 아주 구체적인 스타일 커스터마이징만 허용됩니다 - Syndie에서 임의의 CSS 익스플로잇은 사양합니다, 고맙습니다 :)

다음 릴리스에 들어가지 않을 블로그 보기와 관련해 더 하고 싶은 일이 아직 많이 남아 있지만, 그래도 이번에 들어가는 것만으로도 사람들이 그 기능의 일부를 직접 만져 보게 만드는 좋은 계기가 될 것이고, 그렇게 되면 제가 여러분이 원할 거라고 생각하는 것 대신 무엇이 여러분에게 필요한지 여러분이 제게 보여줄 수 있기를 바랍니다. 저는 좋은 코더일지는 몰라도, 사람들의 마음을 읽는 데에는 영 소질이 없습니다.

    1. HTTP persistent connections

zzz는 정말 괴물이에요, 진짜로. 오래전부터 요청돼 온 기능 - persistent HTTP connections(지속적 HTTP 연결) 지원 - 에 약간의 진전이 있었습니다. 이를 통해 단일 스트림으로 여러 HTTP 요청을 보내고, 그에 대한 여러 응답을 받을 수 있습니다. 이건 아마 2년 전쯤 처음 누군가가 요청했던 걸로 기억하는데, 일부 유형의 eepsite(I2P Site)나 outproxy(외부 프록시)를 사용할 때 꽤 도움이 될 겁니다. 아직 작업이 끝난 것은 아니지만, 잘 진행되고 있습니다. 회의 중에 zzz가 진행 상황을 알려 줄 수 있으면 좋겠네요.

    1. I2Phex gwebcache

I2Phex에 gwebcache 지원을 다시 넣는 작업에 진전이 있다는 보고를 들었지만, 현재 상황이 어떤지는 잘 모르겠습니다. 어쩌면 Complication이 오늘 밤 그에 대한 최신 소식을 알려줄 수 있을까요?

    1. ???

보시다시피 진행 중인 일이 많지만, 여러분이 제기해서 논의하고 싶은 다른 게 있으면, 몇 분 뒤 회의에 잠깐 들러 한마디 해 주세요. 여담으로, 요즘 제가 지켜보고 있는 멋진 사이트 하나는 http://freedomarchive.i2p/ 입니다(I2P가 설치되어 있지 않은 게으른 분들은 http://freedomarchive.i2p.tin0.de/ 를 통해 Tino의 inproxy(입력 프록시)를 사용할 수 있습니다). 아무튼, 몇 분 뒤에 다들 뵙죠.

=jr