I2P 개발자 회의 - 2007년 3월 27일

16:02 <jrandom> 0) 안녕 16:02 <jrandom> 1) 네트워크 상태 16:02 <jrandom> 2) zzz의 NTCP/SSU 제안 16:03 <jrandom> 3) Syndie 개발 현황 16:03 <jrandom> 4) DNS/등록기관 현황 16:03 <jrandom> 5) ??? 16:03 <jrandom> 0) 안녕 16:03 * jrandom 손을 흔든다 16:03 <jrandom> 주간 상태 노트를 http://dev.i2p.net/pipermail/i2p/2007-March/001342.html 에 올려뒀어 16:04 <jrandom> 그럼 1) 네트워크 상태로 들어가자 16:04 <jrandom> 상황은 꽤 좋아 보이고, 말했듯이 최근 변경사항과 관련해 더 연구할 게 있어 16:05 <+Complication> IRC 연결성에 대해 좀 불평하려 했는데(다른 건 꽤 괜찮아 보이고), 지난 하루 동안 끊김이 한 6번 정도였으니 그리 나쁘진 않네 16:05 <cervantes> /mute Complication 16:05 <jrandom> ㅎㅎ 16:05 <+Complication> :D 16:06 <+Complication> Tunnel 빌드 성공률은 아주 좋아 16:06 * Complication 혹시 몰라서 다시 확인해 본다 16:06 <jrandom> 그래, 연결 끊김이 좀 들쑥날쑥하더라(솔직히 말해, 난 backlog를 grep -v -\!- 로 읽어서 끊김을 못 봐 ;) 16:06 <cervantes> 최근 IRC 쪽에서 여러 ISP 측의 문제가 있었어 - postman이 대체 호스팅 방안을 검토 중이야 16:06 <jrandom> 통계상 tunnel 빌드 비율은 상승세고, 전반적으로 stats.i2p에 나타난 주기와도 비슷해 보여 16:06 <cervantes> 더 나은 네트워크 이중화를 갖출 수 있으면 좋겠어 16:06 <jrandom> 아, 오케이 cervantes 16:07 * jrandom dev.i2p.net을 도와주고 싶긴 한데, 거기 부하가 4 아래였던 때가 언제였는지 기억이 안 나 16:08 <jrandom> 좋아, 네트워크 상태 관련해서(re:) 더 얘기할 거 있는 사람? 16:10 <jrandom> 없다면, 2) zzz의 NTCP/SSU 제안으로 넘어가자 16:10 <jrandom> zzz는 지금 없는 것 같고, 그 스레드에 답한 내 Syndie 글은 집에 두고 왔어(이런) 16:11 <jrandom> 어쨌든, 의견은 zzz의 블로그에 올려줘(더 자세한 정보도 거기서 읽을 수 있어) 16:11 <jrandom> 그래도 지금 여기서 그걸 두고 얘기할 거 있는 사람? 16:12 <+Complication> 음, 난 거기에 답글을 달아서 UDP에 너무 의존하는 데 대한 우려를 적었어(개인적으로 내 환경에선 UDP 재전송률이 꽤 높았거든) 16:12 <jrandom> 맞아 16:12 <+Complication> 그래도 한 가지 접근법을 생각해 봤어... 16:12 <+Complication> 현재 bids(선택 점수)는 완전히 결정론적이잖아(무작위 요소가 있는 확률적 방식이 아니라), 맞지? 16:13 <jrandom> 응, 완전히 결정론적이야 16:13 <+Complication> 극단을 피한다는 관점에서, 거기에 확률적 요소를 넣으면 이점이 있지 않을까 생각했어 16:14 <+Complication> "NTCP를 선택할 확률 60%, SSU를 선택할 확률 40%" 같은 식으로 16:14 <+Complication> (사전 데이터가 없다는 가정하에 - 실패/성공에 대한 사전 데이터가 있으면, 그 링크에서 더 성능이 좋은 전송 방식 쪽으로 확률을 조정해야겠지) 16:15 <jrandom> 글쎄, 무엇을 달성하려는지에 달렸지 - 내가 이해한 zzz의 제안은 가능하면 언제나 SSU를 쓰자는 거야 16:15 <+Complication> (물론 해당 링크에서 두 전송 방식 모두 사용할 수 있다는 전제하에 - 때로는 분명 불가능하지) 16:15 <jrandom> 무작위화한다고 그 목표에 도움이 되진 않을 거야. 다만 실사용 환경에서 두 전송 방식 모두에 대한 데이터를 더 많이 수집할 여지는 생기겠지 16:16 <+Complication> 그냥 둘 사이의 균형을 잡아보려는 한 가지 아이디어였어(한쪽이 항상 더 높은 bid를 하면, routers가 별로 '실험'하진 않을 테니까) 16:19 <jrandom> 데이터를 더 모으는 데 쓸 수 있는 방법이긴 하니, 기억해 둘 만해 16:19 <jrandom> 좋아, 말했듯이 더 얘기는 그 스레드에 글로 올려줘 :) 16:20 <jrandom> 그럼 3) Syndie 개발 현황으로 넘어갈게 16:20 <jrandom> 메일에 쓴 것 말고 덧붙일 건 별로 없어 16:20 <jrandom> 질문/의견/우려사항 있어? 16:21 <+Complication> 아직은 없어. :) 16:22 <jrandom> 히히 16:22 * Complication I2P나 Syndie 쪽에서 더 많이 돕고 싶다는 희망을 품고 있지만, 먼저 그 웹 캐시 같은 걸 내보내야(배포해야) 해 16:22 <jrandom> 동감, 둘 다 기대할게 :) 16:24 <jrandom> 좋아, 4는 건너뛰고 5) ??? 로 가자 16:25 <jrandom> 회의에서 더 다루고 싶은 거 있는 사람? 16:26 <TrevorReznik> i2p용 hashcash(작업 증명 방식) 생성기에 관심 있나요? 16:26 <TrevorReznik> 브라우저 인터페이스를 통해서요. 16:26 <TrevorReznik> i2p 내부에서 발생 가능한 DoS 시나리오를 줄이는 방법의 하나로 생각해 봤어요. 16:27 <jrandom> 흠, javascript 아니면 c/java로? 16:27 <jrandom> hashcash 생성기가 몇 개 있는 걸로 알아 16:27 <TrevorReznik> java로요. 16:28 <+Complication> 글쎄, hashcash 방식에 대한 연구는 언젠가 필요해질 거야 16:28 <TrevorReznik> www.hashcash.org에 몇 개 있는 것 같아요. 16:28 <TrevorReznik> 이메일 클라이언트를 위한 스팸 방지 수단으로 정착시키려는 이니셔티브예요. 16:28 <+Complication> 아마 엄밀한 의미의 연구라기보다는, 구현과 모범 사례 측면의 sese 16:28 <+Complication> =sense 16:28 <TrevorReznik> 여러 언어로 구현 모음이 있어요. 16:28 <TrevorReznik> java 클래스로 2개, 애플릿도 적어도 하나 있는데, 지금으로선 정확한 라이선스 조건은 모르겠네요. 16:30 <+Complication> 쓸 수 있는 곳: 1) Syndie의 nym(가명) 등록 2) I2P의 이름 등록 16:30 <+Complication> 3) 당연히 이메일 16:30 * TrevorReznik 동의합니다. 16:30 <+Complication> 4) 덜 낙관적인 시나리오에선, Syndie의 일반 메시지 16:31 <+Complication> I2P 네트워크 레벨 자체에서는... 16:31 <+Complication> 흠 16:31 <jrandom> 그걸 tunnel 생성 메시지에 넣을 수도 있겠지만, 그 CPU 측면은 지금도 이미 벅차 ;) 16:39 <jrandom> 좋아, 회의에서 더 할 얘기 있어? 16:41 <jrandom> 없다면 16:41 * jrandom 마무리한다 16:41 * jrandom *baf* 하고 회의를 닫는다