I2P 개발자 회의 - 2006년 2월 28일

15:11 <jrandom> 0) 안녕하세요 15:11 <jrandom> 1) 네트워크 상태와 0.6.1.12 15:11 <jrandom> 2) 0.6.2로 가는 길 15:12 <jrandom> 3) 미니프로젝트 15:12 <jrandom> 4) ??? 15:12 <jrandom> 0) 안녕하세요 15:12 * Complication 메모를 재빨리 읽는다 15:12 * jrandom 손을 흔든다 15:12 <jrandom> 주간 상태 노트를 http://dev.i2p.net/pipermail/i2p/2006-February/001266.html 에 올려두었습니다 15:12 <jrandom> (그리고 여기서는 회의 시작 15분도 넘게 전에 노트를 올렸죠! ;) 15:13 <jrandom> 좋아요, 여러분이 그 아주 흥미진진한 글들을 읽는 동안 1) 네트워크 상태와 0.6.1.12로 바로 들어가죠 15:14 <jrandom> 앞서 말했듯이, 0.6.1.10–0.6.1.12 릴리스의 주요 목표는 달성된 것으로 보입니다. tunnel 생성 암호화 변경을 다루고 생성 신뢰성을 크게 개선했어요 15:16 <jrandom> 0.6.1.10에서 겪었던 문제들은 사라졌고, IRC 안정성도 다시 꽤 좋아진 듯합니다 15:16 <jrandom> 1) 네트워크 상태와 0.6.1.12에 대해 더 이야기할 게 있나요, 아니면 2) 0.6.2로 가는 길로 슬슬 넘어갈까요? 15:17 <+Complication> 여기 네트워크 상태: 이제 20 KB/s 아래로는 안 떨어져요 :) 15:18 <jrandom> 좋네요. 0.6.1.12에서 0.6.1.11의 큰 버그 하나를 고쳤습니다. 사용 가능한 대역폭을 제대로 활용하지 못하던 문제였죠. 이제 가용 자원을 더 잘 써야 합니다 15:20 <jrandom> 좋아요, 그럼 2)로 넘어가죠 15:20 <jrandom> 말씀드렸듯이, 0.6.2에 마지막 기능 변경을 적용하기 전에 정리해야 할 것들이 몇 가지 있지만, 그 부분도 진척되고 있습니다 15:20 <nymisis> 네트워크 상태 괜찮아요 :) 15:22 <jrandom> 좋아요. 새 피어 정렬 전략의 세부사항은 공개 전에 더 많은 정보를 제공하겠지만, 노트에 간단히 언급된 것만으로도 요지는 이해되실 겁니다 15:23 <jrandom> 누구든 2) 0.6.2로 가는 길에 관해 질문/의견/우려가 있나요? 15:23 <postman> jrandom: 이번에는 테스트넷이 있나요? 15:24 <postman> (무언가를 테스트할 routers, 참가자가 필요한가요) 15:24 <postman> ? 15:24 <+Complication> 핵심은 꽤 단순해 보였습니다 — 공격자가 다양한 통계 데이터를 수집할 기회를 제한하는 것이죠 15:25 <+Complication> 상당히 바람직한 기능 같네요 15:25 <jrandom> postman: 새 기능은 로컬 정보만 사용해 라이브 네트에서 투명하게 동작할 것이므로, 별도의 테스트 네트가 필요하지는 않을 겁니다 15:25 <jrandom> 맞아요, 바로 그거예요 Complication 15:26 <postman> 알겠어요 15:26 <postman> jrandom: 0.6.2의 ETA(예상 일정)를 공개할 만큼 대담하신가요? :) 15:27 <blubb> 4월 1일 15:27 <jrandom> 음, 오늘이 2월 말이니 3월이나 4월쯤이라고 보겠네요 15:27 <postman> 헤헤 15:27 <jrandom> blubb: 그때를 위해 이미 mi6 백도어를 예약해 놨어요 ;) 15:29 <@cervantes> mi6 고양이문에 더 가깝죠 15:29 <@cervantes> (예산 삭감) 15:29 <postman> 코끼리 집에다가 15:30 <nymisis> 정확히 하려면 MI6가 아니라 SIS죠. :) 15:30 <jrandom> 뭐, 그냥 그들을 '그분들'이라고 부르죠 ;) 15:31 <jrandom> 좋아요, 2)에 대해 더 있을까요? 15:31 <jrandom> 없다면 3) 미니프로젝트로 살짝 넘어가죠 15:31 <@cervantes> 미안, "the firm" 15:34 <jrandom> 좋아요, 1) 하기가 간단하고 2) 정말 유용한 멋진 것들을 몇 가지 짚고 넘어가려 합니다 15:34 <+Complication> 미니프로젝트 쪽으로, 제 Syndie 회신이 제대로 전달됐는지 모르겠는데, 하나 맡아도 될지 궁금합니다. 15:34 <+Complication> 어떤 걸 할지는 아직 모르겠어요. 지금은 Java를 좀 더 연습하는 중이에요(마이크로 프로젝트 진행 중 :D). 시도할 때 하나를 감당할 수 있다는 확신을 조금 더 갖기 위해서요 15:35 <DeltaQ> 흠, 콘솔에서 bw를 올리면 변경이 즉시 적용되나요, 아니면 재부팅이 필요하나요? 15:35 <+Complication> 그 '마이크로 프로젝트'가 준비되면(물론 목록이 아직 비워지지 않았다면) 하나 골라보겠습니다 15:35 <jrandom> w3wt, 굿이에요 Complication 15:36 <jrandom> DeltaQ: 즉시요 15:36 <@cervantes> 1) Syndie 스케줄러가 4) Download Manager / eepget 스케줄러와 연계되는 거 아닌가요 15:36 <+Complication> DeltaQ: 거의 즉시 적용됩니다(대역폭 평균 계산 주기 안에서요) 15:37 <@cervantes> 보다 범용적으로 동작하는 업/다운로드 관리자가 두 요구를 모두 충족할 것 같은데요 15:37 <jrandom> cervantes: 흠, 꼭 그렇진 않아요. 1)은 꽤 특정 목적에 집중되어 있고, 푸시도 포함하지만, 4)는 꽤 일반적이에요 15:37 <+Complication> cervantes: 그럴 수도 있겠네요 15:37 <jrandom> 하지만 네, 둘의 엔진은 EepGet입니다 15:37 <jrandom> (eepget이 Syndie의 HTTP 전송을 프로그램적으로 처리합니다) 15:38 <DeltaQ> 평균이 13kb/s 위로는 안 올라가는 것 같네요 15:38 <DeltaQ> 나는 64kb/s에 down 버스트 192로 설정했어요 15:38 <DeltaQ> up은 32/64 15:38 <@cervantes> 그러니까 스케줄링과 관리 API가 있는, 푸시/풀을 모두 지원하는 범용 eepget을... 15:39 <@cervantes> 그래도, 그 정도면 아마 미니프로젝트는 아니게 되겠죠 15:39 <+Complication> DeltaQ: 평균은 당신의 client tunnels과 다른 피어들의 participating tunnels이 만들어내는 부하에 얼마나 달려 있는지도 좌우됩니다 15:39 <+Complication> sorry, s/average/actual bandwidth 15:39 <jrandom> cervantes: 네, 그래도 Syndie 쪽에는 상당한 로직이 들어 있습니다. 15:40 <DeltaQ> 헤, 드디어 올라갔네요 15:40 <DeltaQ> 1s: 30.82/29.33KBps 15:40 <DeltaQ> 아마 ul bw를 더 올려야 했나 보네요 15:40 <jrandom> DeltaQ: 평균은 다른 사람들이 당신을 어떻게 보느냐에도 영향을 받습니다. 이는 광고된 속도가 아니라 당신의 행동에 달려 있으므로, 조금 시간이 걸릴 거예요 15:40 <+Complication> DeltaQ: 통과 트래픽(participating tunnels)의 경우, 들어온 건 반드시 나가야 합니다 15:41 <+Complication> DeltaQ: 그래서 ul/dl 속도가 크게 다르면 participating traffic은 둘 중 더 낮은 쪽에 의해 병목됩니다 15:42 <+Complication> DeltaQ: 또한 participating traffic은 다른 노드가 당신 노드의 라우팅 용량을 어떻게 '인지'하느냐에 달려 있어요 15:42 <DeltaQ> 오키 15:43 <+Complication> 잘 라우팅할 수 있다고 생각하면 더 자주 요청할 겁니다 15:43 <jrandom> 좋아요, 3) 미니프로젝트에 더 없다면 4) ???로 넘어가죠 15:43 <jrandom> 회의에서 더 다룰 사항 있나요? 15:43 <DeltaQ> 음, 저는 router 뒤에 있지만 이 PC로 포트 8887을 매핑해 두었어요 15:43 <+Complication> 새로운 노드이거나, 용량이 최근에야 늘었다면, 그들은 조금 소극적입니다 15:44 <DeltaQ> 아, 미안해요 회의를 방해하려던 건 아니었어요 ^^ 15:44 <+Complication> 며칠 전에 누군가 clock skew(시계 오차)에 기반한 잠재적 공격에 대해 물었습니다. 터널링 부분에 관한 당신의 답변을 본 것 같아요(생성 메시지는 생성자의 관점에서의 시간 대신 tunnel 유효 기간만 담는다)... 15:44 <@cervantes> (상태 노트에서 언급해줘서 고마워요) ;-)_ 15:46 <+Complication> 그래서 사실 물어보려고 했어요... I2P 메시징에서, 발신자의 관점에서 본 시간이 들어갈 수 있는 지점이 있다면 어디인가요? 15:47 <+Complication> 아직 이 부분을 최신 상태로 파고들지 못해서, 조금은 잘 몰라요 15:47 <jrandom> Complication: 명시적으로 "지금은 $time이라고 생각해"라고 말하는 건 없지만, 충분한 트래픽과 타이밍 분석이 있으면 상당히 좁힐 수 있을 겁니다 15:48 <jrandom> 우리는 시간을 큰 주기로 양자화하지만 최대 clock skew만큼 크지는 않아서, 여지는 있습니다 15:49 <+Complication> 좀 더 "간결한" NTP 클라이언트에서 궁극적으로 얻을 이점이 있을까요? 15:49 <+Complication> skew를 더 작게 유지하기 쉬운/가능한 그런 것? 15:50 <jrandom> 음, sntp 클라이언트가 i2p에 도입된 이후로 점점 좋아져서, 이제 예전처럼 변동이 보이지는 않습니다 15:51 <jrandom> 아마 minimum-skew 제한을 10초에서 2~3초, 혹은 그 이하로 줄일 수도 있겠네요 15:51 <jrandom> 또는 불필요한 skew를 피하기 위해 ssu clock skew도 참조하도록 할 수 있겠고요 15:52 <+Complication> 또는, 다른 피어의 가능한 시계 값을 추정할 기회를 더 줄이는 것도 가능할까요? 15:53 * Complication 어느 쪽이 더 실용적일지는 몰라서요, 그냥 무작위로 가능성을 제안해 보는 겁니다 :D 15:53 <jrandom> 아니요, 직접 연결된 피어들의 clock skew는 알고 있어요 15:55 <Magii> 업데이트가 성공적으로 완료되었는지 확인할 방법이 있나요? 15:55 <+Complication> 아하, 그러면 세션 프로토콜이 정말 그 정보에 의존하는군요.. 15:55 <tethra> 버전 번호를 보세요 15:55 <+Complication> Magii: 로그에 "update verified, restarting to install" 같은 CRIT가 기록될 거예요 15:55 <tethra> :/ 15:55 <+Complication> 그 다음, 우아한 재시작까지 분 단위로 카운트다운할 겁니다 15:56 <+Complication> 그리고 마지막으로 재시작하죠 15:57 <+Complication> 아, 참고로: 내부 NTP 클라이언트가 "clock drift rate(시계 드리프트율)" 같은 개념을 알고 있나요? 15:58 <jrandom> 네, http://localhost:7657/index.jsp 좌상단의 버전 번호가 힌트가 될 거예요 :) 15:58 <jrandom> Complication: 아니요, 순차적인 시계 틱을 보장하지는 않습니다 15:59 <jrandom> s/sequential/ordered/ 15:59 <+Complication> 또 "우리 시스템 시계가 필요한 것보다 0.00345배 더 빠르다" 같은 지식을 축적하지도 않나요? 16:00 <jrandom> 아, 아니요. 다만 그걸 net.i2p.util.Clock에 추가하는 건 그리 어렵진 않을 거예요(미니프로젝트 하나 해볼래요? :) 16:00 <+Complication> 저도 비슷한 걸 생각하고 있었어요 16:01 <+Complication> 이제 그걸 좀 더 생각하게 되네요 :) 16:01 <+Complication> 그래도 다른 미니프로젝트가 먼저죠 :) 16:02 <jrandom> 좋아요, 회의에서 더 다룰 사항 있나요? 16:03 <nymisis> 머핀? 16:04 <jrandom> 아니요, 팬케이크 16:04 <jrandom> (음MM음 팬케이크) 16:04 <jrandom> 말이 나와서 말인데 16:04 * jrandom 준비한다 16:04 <nymisis> 오, 이런, 좋은 지적이에요. 16:04 * jrandom *baf*s 하며 회의를 종료합니다