I2P 개발자 회의 - 2005년 10월 18일

16:10 <jrandom> 0) hi 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet, I2P, 그리고 다크넷들 (오!) 16:10 <jrandom> 3) Tunnel 부트스트랩 공격 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) hi 16:10 * jrandom 손을 흔든다 16:10 <jrandom> 주간 상태 노트가 http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 에 올라가 있습니다 16:10 <dust> 이야, 이제 됩니다. 고마워요 Gregor 16:10 <cervantes> 안녕 16:11 <+fox> <blx> 헬로아 16:11 <jrandom> 좋아요, 1) 0.6.1.3 로 바로 들어갈게요 16:11 <jrandom> 다들 꽤 빠른 속도로 업데이트해 주셨네요, 감사합니다! 16:12 <jrandom> 상태는 괜찮아 보이고, 상태 노트에 있는 것 외에 덧붙일 게 많지는 않아요 16:12 <jrandom> 0.6.1.3 관련해서 질문/코멘트/우려 사항 있나요? 16:13 <jrandom> 없으면 2) Freenet, I2P, 그리고 다크넷들(오!)로 넘어가죠 16:13 <cervantes> 609명의 알려진 피어! 16:14 <cervantes> (w00t) 16:14 <jrandom> 네, 네트워크가 성장하고 있죠 16:14 <+fox> <blx> 오! 16:14 * cervantes 천 명 돌파까지 얼마나 걸릴지 맞추기 내기 중 16:14 <jrandom> 헤헷 16:14 <tethra> ㅎㅎㅎ 16:15 <tethra> 디지털 현금으로 내기하나요? ;) 16:15 <cervantes> 그런데 최근 i2p 코어가 얼마나 탄탄해졌는지를 보여주는 게, 사용자 증가 속도가 빨라졌다는 점이죠 16:16 <cervantes> 아니요… jrandom은 이미 올해 맥주값 전부를 자신도 모르게 기부했어요 16:16 <jrandom> ㅎㅎ 16:16 <jrandom> 자, 2)와 관련해서는, 더 할 말이 있는지 잘 모르겠어요(충분히 두들긴 말이죠). 그 주제에 관한 질문/코멘트/우려 있나요? 16:18 <cervantes> 당신이 말했듯, 최소한 흥미로운 관련 보안 논의를 촉발했죠. 즉 3) 16:18 <jrandom> 없다면 빠르게 3) Tunnel 부트스트랩 공격으로 넘어가죠 16:18 <jrandom> 네, 그렇죠 16:19 <jrandom> Michael이 제기한 이슈는 제가 갖고 있던 일반적인 관점을 수치화해 줘요. 명시적으로 만들 수 있어서 좋습니다 16:20 <jrandom> 오늘 밤 늦게(답글을 작성할 수 있게 되면) 더 새로운 공격에 대한 추가 논의가 있을 텐데, 전자의 건은 큰 문제가 아닌 것 같아요 16:21 <jrandom> 이해가 되시나요, 아니면 이에 대해 질문이나 우려가 있나요? 16:22 <cervantes> 헤… 그 말은 모두가 괜찮다고 생각하든지 아니면 문제의 핵심을 전혀 모르겠다는 뜻이죠 16:23 <cervantes> 전 모르는 게 약이다 쪽으로 할래요 16:23 <jrandom> ㅎㅎ 본질적으로는 나쁜 사람들이 당신이 지금까지 만든 모든 tunnel의 아웃바운드 엔드포인트가 되는 공격이에요 16:23 <jrandom> 이제 막 시작할 때는 “지금까지 만든 모든 tunnel”의 수가 매우 작죠(예: 0, 1, 2) 16:24 <jrandom> 하지만 몇 초 지나면 그 수가 충분히 커져서 (c/n)^t가 정말정말 작은 수가 됩니다 16:25 <tethra> (c/n)^t가… 16:25 <jrandom> (그래서 startup 직후에는 i2cp listener—즉, i2ptunnel/기타—를 바로 시작하지 않는 이유 중 하나죠) 16:25 <jrandom> c == 담합하는 피어 수(나쁜 놈들), n == 네트워크의 피어 수, t == 당신이 만든 tunnel 수. 16:25 <cervantes> 그렇죠… 16:25 <tethra> 아 16:26 <jrandom> 그래서 t가 커질수록 성공적인 공격의 확률은 정말 작아져요 16:26 <cervantes> 그러면 말 그대로 가능한 수준이 되려면, startup 후 몇 분 안에 민감한 작업에 router를 쓰기 시작해야 한다는 건가요? 16:26 <jrandom> (혹은 어쨌든, 하나의 tunnel의 모든 홉을 장악할 확률보다 작아집니다) 16:26 <tethra> 아하, 알겠어요 16:27 <jrandom> cervantes: 즉시요, 세 번째 tunnel이 만들어지기 전에 16:27 <jrandom> (3-hop tunnel을 쓴다고 가정하면) 16:27 <cervantes> 그건 꽤 가능성이 낮네요 16:28 <cervantes> 사용 사례 관점에서도요 16:28 <jrandom> 맞아요. 16:28 <jrandom> 게다가 우리는 startup 때 클라이언트를 실행시키기 전에 3개 이상 tunnel을 만들기 때문에, 확률 문제이기만 한 건 아니에요 16:28 <jrandom> 그래도 공격을 정량화해 두는 건 좋죠 16:29 <cervantes> 그 어떤 가능성에도 대비하려고 router가 좀 더 오래 “웜업”하도록 두는 게 가치가 있을까요? 16:30 <cervantes> 아니면 더 강하게 돌아가게… 16:30 <jrandom> 어쩌면요. 연결 수립 시간과 비무작위 피어 선택을 무시하면, 가능성은 없다고 볼 수 있어요 16:31 <tethra> 그건 “우왕!”할 만한 소식인가요? 16:32 <jrandom> 네, 하지만 엔지니어링 관점에서는 그런 특성을 무시하면 안 되죠 ;) 16:32 <jrandom> 그래서 0.6.2에서는 개편된 tunnel 피어 선택/순서 구현을 하면서 이 부분을 살펴보고, 제대로(Sanely) 동작하는지 확인할 필요가 있을 거예요 16:34 <jrandom> 좋아요, 3) 관련해서 더 없으면 4) I2Phex로 넘어가죠 16:34 <jrandom> sirup은 없고, irc에서 striker도 못 봤네요 - redzara, 있나요? 16:36 <+redzara> 네 16:36 <+redzara> 1차는 거의 완료: Sirup의 모드를 최신 phex CVS로 포팅 16:36 <jrandom> 멋져요! 16:36 <+redzara> 다음: 2차: Sirup 코드와 최초 릴리스에 사용된 기본 phex 코드 간의 diff를 내서, 제가 아무것도 빠뜨리지 않았는지 확인 :) 16:37 <+redzara> 아마 이번 주말(W.E.)에 끝날 수도 있어요 16:37 <jrandom> 와, 그럼 정말 좋죠 16:37 <+redzara> 3차: GregorK와 통신 레이어 리팩토링 16:37 <+fox> <GregorK> 최신 Phex CVS에서는 다운로드 코드가 안정적이지 않고 다운로드 파일이 이전 릴리스와 호환되지 않는다는 걸 알고 있길 바랍니다 16:38 <jrandom> 여긴 i2p라, 불안정한 건 익숙합니다 :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> 마지막 단계는, 현재 GregorK와 연락이 없어서 꽤 어려울 것 같아요 :( 16:38 <jrandom> GregorK: 통합은 어떻게 추천하나요? 16:39 <+fox> <GregorK> 이제 저하고 연락이 닿은 셈이네요 ;) 16:39 <jrandom> 아 그러면 됐네요 redzara, 어쨌든 처음 두 단계만으로도 충분히 크죠 :) 16:39 <+redzara> GregorK : 하이 16:40 <+redzara> GregorK : 코드를 전부 꼼꼼히 읽었어요 16:40 <+fox> <GregorK> 레이어를 어떻게 만들지 아이디어가 있어요… 최대한 잘 준비해 볼 테니, 얼마나 잘 맞는지, 무엇을 바꿔야 하는지 함께 보죠 16:40 <+fox> <GregorK> 전부?? 와… 16:40 <+redzara> Gregork : 네, 전부요!! 16:41 <cervantes> 속옷 사이즈까지 알고 있을 걸요 16:41 <Rawn> :D 16:41 <+fox> <GregorK> 좋아요… 다음에 쇼핑할 땐 당신한테 물어봐야겠네요… 16:43 <+fox> <GregorK> 가능하다면 i2phex 팀에서 phex 팀에도 누가 한 명 들어오면 좋겠네요.. 16:43 <jrandom> redzara: 그러면 메인라인 Phex에 플러그인 레이어로 전부 합치기 전에, 2차 작업 결과로 0.1.2 I2Phex 릴리스를 낼 수 있을까요? 아니면 한 번에 다 가나요? 16:43 <+redzara> 미안하지만, 영어를 잘 못해서 당신이 쓴 농담을 이해/말하기/읽기/쓰기 힘들어요 16:43 <+fox> <GregorK> 그게 양쪽에 모두 있는 버그 해결에도 도움이 될 거예요 16:44 <jrandom> GregorK: 가능하면 I2P 쪽은 Phex에서 얇은 플러그인으로만 만드는 길을 찾으면 좋겠죠? 16:44 <jrandom> 아니면 둘을 분리해 두는 게 낫다고 보나요? 16:44 <+redzara> jrandom : Phex 2.6.4를 I2P 위에서 돌릴 수 있을 것 같아요, 제게 I2Phex는 끝났어요 16:45 <jrandom> 끝났다고요? 16:45 <+fox> <GregorK> 처음부터 완전히 그렇게 만들 수 있을지는 모르겠지만, 주요 부분은 플러그인으로 분리할 수 있다고 봅니다. 16:45 <jrandom> 좋아요, 작업이 많겠죠 16:46 <jrandom> 특히 java.net.URL 같은 것들(인스턴스화 시 DNS 요청이 새는 등)을 보면요 16:46 <+redzara> jrandom : 끝, 종료(endded) 16:46 <+Ragnarok> 그르르 16:47 <jrandom> 알겠어요 redzara, Phex 2.6.4를 I2P 위에서 모두 잘 돌릴 수 있게 되면, I2Phex가 따로 필요하진 않겠네요 16:47 <+fox> <GregorK> 맞아요… Phex는 일부에서 apache URI 클래스를 사용해 이런 걸 우회하죠.. 다만 꼭 필요할 때만 16:48 <jrandom> 아 맞아요, 그 라이브러리 만져본 기억이 있네요, 좋아 보이더군요 16:49 <jrandom> i2p에서 최종 사용자에게 내놓기 전에 익명성/보안 쪽을 확실히 좀 더 검토해서 도울게요 16:49 <jrandom> (Phex에 문제가 있다고 하려는 건 아니고, 모든 앱에는 문제가 있으니, 우리가 도와서 정리할 수 있길 바란다는 뜻이에요) 16:50 <+fox> <GregorK> Socket 사용 같은 것들은 매끄럽게 통합하는 아이디어가 있어요… 하지만 다른 기능들, 예컨대 UDP 같은 데서는… 아직 최선의 해결을 모르겠네요 16:50 <+fox> <GregorK> 음 Phex에는 문제가 많을 거라고 확신합니다. :) 16:50 <jrandom> 아, 소켓은 쉬울 텐데, 다른 것들은 비활성화해야 할 수도 있겠네요. UDP는 뭘 위해 쓰나요 - 빠른 쿼리? 16:51 <+fox> <GregorK> 현재는 부트스트래핑에만 16:51 <+fox> <GregorK> UDP Host Cache… GWebCache의 대체 16:52 <jrandom> 아하, 알겠습니다. 16:52 <+redzara> 그렇다면 괜찮은 GwebCache가 있다면 필요 없겠네요? 16:53 <+fox> <GregorK> 네… 하지만 표준 GWebCache에도 보안 문제가 있어요… 16:53 <+redzara> GregorK : I2P 내부라면 그런 문제는 없을 것 같아요 16:54 <jrandom> 오, 그 부분은 극복 가능해요 - I2PSocket은 인증돼요 - 반대편 피어의 'destination'을 알 수 있으니, 상대가 “저는, 어… whitehouse.gov.. 맞아요!”라고 할 수 없죠 16:54 <jrandom> 하지만 맞아요, 검증이 필요한 부분이긴 해요 16:54 <+fox> <GregorK> 또 방화벽-대-방화벽 전송도 UDP 주제인데, 자원자가 생기면 구현하고 싶어요 :) 16:54 <jrandom> 아, I2P는 방화벽-대-방화벽 전송이 필요 없어요 - I2P는 완전히 개방된 end-to-end 주소 공간을 노출하거든요 :) 16:55 <jrandom> 하지만… 오, 쓸모가 있을 수도 있겠네요 16:55 <jrandom> Phex 사용자가 “0 hop tunnels”를 쓰면, 꽤 괜찮은 속도로 NAT 트래버설/방화벽-대-방화벽 전송을 공짜로 얻을 수 있어요 16:55 <+fox> <GregorK> 또 하나는 개인 네트워크에서 쉬운 공유를 위해 쿼리 등의 LAN 브로드캐스트… 16:56 <jrandom> (0 hop tunnels는 중간 피어가 트래픽을 운반할 필요 없이 그럴듯한 부인 가능성을 제공합니다) 16:57 <jrandom> 흠, LAN 브로드캐스트는 좋지만, i2p에서는 꼭 필요하진 않을 것 같아요(상대 피어가 어디 있는지 아는 건 익명성 위험이라서 :), 그러니 I2P 플러그인을 쓸 때는 그 기능을 비활성화해도 되겠죠? 16:58 <cervantes> *기본값으로 비활성화 16:58 <+fox> <GregorK> 아직 제공되진 않아요.. 하지만 이런 경우엔 어차피 사용자들이 서로를 알고 개인 네트워크를 구성하겠죠.. 16:58 <jrandom> 맞아요 cervantes 16:58 <jrandom> 네네 GregorK 16:59 <+fox> <GregorK> 사용자 인터페이스 관련 변경 사항이 있나요?? 17:00 <+bar> 음, 우린 flags는 필요 없겠죠 :) 17:00 <jrandom> 최소한, I2P 관련 몇 가지 설정 옵션이 가능하면 좋겠어요. 17:01 <jrandom> sirup은 표시를 IP+포트 대신 I2P 'destinations'로 일부 바꾸는 데 성공한 것 같아서, 괜찮았던 걸로 기억해요 17:01 <+redzara> 그럼 bitzy는요? 지금은 아니지만, flags와 countries는 사용하지 않아요 17:01 <jrandom> bitzy? 17:01 <+redzara> 미안, 잘못 복붙했어요 :( 17:02 <+fox> <GregorK> 필요한 설정 옵션과 선택적 기능 목록을 제공해 줄 수 있나요? 17:03 <jrandom> 물론이죠. I2P가 돌아가는 host+port와 성능/익명성 조정 관련 드롭다운 몇 개면 될 거예요 17:03 <jrandom> 자세한 건 전달드릴게요 17:02 <cervantes> [x] 슈퍼 전송 속도 모드 17:02 <+fox> <GregorK> 음 Bitzi는 파일 식별에 쓰여요.. 익명성 문제인가요? 17:03 <vulpine> <redzara> GregorK : 준비 중인데, 기본적으로 변경사항은 없어요 17:03 <+fox> <GregorK> :) 공급자에게 문의해 보세요 cervantes… 17:03 <redzara> GregorK : 그럴 수도 있어요, 작업 중입니다 17:04 <cervantes> GregorK: 전 영국 거주자라서요… 희망 없음 ;-) 17:04 <+fox> <GregorK> 같은 PC의 두 Phex 인스턴스 간에 파일을 전송하면… 번개처럼 빨라요 ;) 17:05 <cervantes> 멋지네요… 저랑 제 자신이 멋진 영화 많이 공유하겠네요 :) 17:05 <cervantes> * 그건 회의록에서 빼 주세요 * 17:06 <bar> jrandom이 전에 언급했지만, 그 미친 아이디어 다시 한 번: 17:06 <+bar> 일반 사용자가 0-hop tunnels를 갖도록 Phex에 i2p를 통합하는 건 어때요? 17:07 <+fox> <GregorK> flags와 IP+port 표시가 HostAddress 객체에서 오는데요.. 새 레이어에선 그걸 숨길 수 있으니 다른 걸 표시할 수 있어요 17:07 <+bar> (그럴듯한 부인 가능성과 UDP 방화벽 홀 펀칭을 위해) 17:08 <+fox> <GregorK> 정확히 무슨 뜻인지 잘 모르겠네요 ;) 17:08 <+bar> 아마 저도요 ;) 17:09 <jrandom> GregorK: 본질적으로, Phex 사용자가 서로 직접 통신하되, 간접 통신일 수도 있으니 그럴듯한 부인 가능성을 얻는다는 뜻이에요 17:09 <+bar> jrandom, 제 의도를 아실 것 같으니, 좀 더 설명해 줄래요? 17:09 <jrandom> 또한 I2P의 NAT 트래버설을 공짜로 얻고, ISP 등으로부터의 스니핑으로부터 데이터 보안/보호도 얻죠 17:09 <+redzara> GregorK : 그래서 host+port + IsLocalIP + Is PrivateIP + … 관련 코드를 전부 제거해야 해요 17:10 <jrandom> 반면에, (아주 큰 반면에), I2P 위에서 돌아가지 않는 gnutella 클라이언트와는 통신할 수 없게 돼요 17:10 <jrandom> (물론 언젠가는 전부 그렇게 되겠지만 ;) 17:10 <+fox> <GregorK> 첫 단계는—그리고 그 단계만으로도 충분히 큽니다—i2p와 phex를 더 가깝게 만드는 거죠. 17:10 <jrandom> 동의해요 17:10 <+bar> (젠장, 그 생각을 못 했네) 17:11 <+bar> 네, 확실히요 17:11 <jrandom> 이건 날아다니는 조랑말 급의 이야기예요. 먼저 실용적인 것부터 하죠 17:11 <+fox> <GregorK> 그게 얼마나 잘 되는지 본 다음에, 어떻게 더 나아갈지 결정할 수 있겠죠.. 17:11 <jrandom> 바로 그거예요 17:12 <+fox> <GregorK> redzara: HostAddress의 두 구현을 갖고 싶어요, 하나는 i2p용, 하나는 현재 것처럼. 17:14 <+redzara> Gregork : 문제없어요, 제 모드에서 관련 코드를 전부 주석 처리해 두었으니 두 구현을 쉽게 만들 수 있을 거예요. 초기 작업만 마치게 해 주세요 17:14 <+fox> <GregorK> 물론이죠.. 문제없습니다.. 17:14 <jrandom> :) 좋아요, 그럼 redzara, 다음 주쯤 Phex-2.4.2 기반 새 버전의 알파 테스트를 해볼 수 있을까요? 17:15 <jrandom> (2단계 부분 말이에요. 3단계는 메인라인 통합에 더 많은 작업이 필요하겠죠) 17:15 <+redzara> jrandom : next sems to be ok for me 17:16 <jrandom> 좋아요, 훌륭해요 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> 멋집니다, 부드럽게 돌아가도록 하는 게 기대돼요 17:17 <jrandom> 4) I2Phex에 관해 더 얘기할 게 있나요, 아니면 5) Syndie/Sucker로 잠깐 넘어갈까요? 17:17 <cervantes> I2P는 그런 킬러 앱들로 분명 혜택을 볼 거예요 17:18 <+fox> <GregorK> 참고로 Phex CVS 변경사항을 위한 Phex CVS 메일링 리스트가 있어요… 도움이 된다면 17:18 <jnymo> *크흠*.. 당연하죠 17:18 <jrandom> 좋아요, 고마워요 GregorK 17:18 <jrandom> 맞아요 cervantes 17:19 <jrandom> 자, 5)와 관련해서는, 거기 있는 것 외에 덧붙일 게 없어요 17:19 <jrandom> dust: 있나요? 17:19 <+redzara> GregorK : 감사합니다만, 버전 하나만 다루기도 충분히 벅차요 :) 17:19 <jrandom> ㅎㅎ redzara 17:19 <dust> 요즘 여유 시간이 많지 않았는데, 시간이 나면 addresses.jsp를 파악해서, 프로토콜 드롭다운에 'RSS'를 추가하고, 그다음 Updater, Sucker를 거쳐 BlogManager로 가는 경로를 만들 생각이에요. 17:20 <dust> 더 좋은 아이디어가 없다면요 17:20 <jrandom> 끝내주네요 17:20 <jrandom> 완벽해 보여요. 17:21 <jrandom> 다만, 흠, 추가 필드가 필요할 수도 있겠어요(“어느 블로그에 게시할지”와 “어떤 태그 접두사로 할지”)… 17:21 <jrandom> 별도 폼/테이블이 의미 있을지도, 아닐지도 17:22 <dust> 아, addresses.jsp는 하나의 블로그용인 줄 알았어요(거기 가려면 로그인해야 하니까요?) 17:22 <jrandom> 아, 맞아요, 좋은 지적 17:23 <jrandom> updater 부분이 좀 흐릿하지만, 맞아요 17:23 <dust> (가서 부딪히며 알아내죠) 17:23 <jrandom> 네 17:24 * jnymo www.i2p.net이 ‘머천다이즈 카페’ 같은 걸 시작하면 좋겠다고 생각함 17:24 <jnymo> “I am Jrandom”이라고 적힌 eyetoopie 셔츠랑 함께 ;) 17:24 * mrflibble 아직 “플레임 워”를 따라잡는 중, 제대로 된 플레임 워로 번지는 중 같음 :) 17:24 <jrandom> ㅎㅎ jnymo 17:25 <jrandom> 네, 그 스레드에 내용이 많아요 17:25 <jrandom> 좋아요, 그럼 6) ???로 가볼까요 17:25 <jrandom> 회의에서 더 얘기할 거 있나요? 17:25 <+bar> 네, symmetric NAT 이슈에 대해 짧게 한마디만(좀 살펴봤어요): 17:25 <+nickless_head> jrandom: 진실을 알아냈어요! 17:25 <+fox> <blx> kaffe? 17:25 <mrflibble> 아, 미안 jr 17:26 <jnymo> 하지만 진지하게… 규모 있는 모든 오픈소스 프로젝트는 자체 머천다이즈 섹션이 있죠 17:26 <+nickless_head> jrandom: 당신이 last.fm 홈페이지를 해킹했다는 확실한 증거가 있어요! 17:26 <+nickless_head> (가입하면 받는 항목 목록에 ‘조랑말’이 있었음) 17:26 <jrandom> jnymo: 맞아요, 그 방향도 검토해야겠어요, 모금 수단으로도 좋겠고요 17:27 <jnymo> jrandom: 바로 그거죠 17:27 * mrflibble 티셔츠 산다에 한 표 17:27 <+bar> 좋아요, symmetric NAT에 관해, 17:27 <+bar> 제 생각엔 이미 지원되는 NAT들과 달리, 마법 같은 트릭은 없어요. 제대로 하려면 각 대칭 NAT의 동작을 연구/분석하고 introducer를 써서 프로빙해야 합니다. 17:28 <jrandom> blx: 최신 kaffe CVS는 완전 b0rked 됐어요. crypto 패키지가 소스에 없고, prng는 초기화에 실패하며, url 핸들러는 file://을 처리 못 해요 :( 17:28 <jnymo> i2p 사용자가 호스팅 서버에서 i2p를 쓰고 싶다면, 자유로운 정책의 저렴한 호스팅 업체로 어디가 좋을까요? 17:28 <+bar> (예를 들어 Hamachi와 Skype가 대칭 NAT 뒤에서 UDP 홀 펀칭을 하는 방식이 이렇다고 합니다) 17:28 <+nickless_head> jnymo: 컵도 좋죠 :) 17:28 <+bar> 제가 읽은 바에 따르면, 대칭 NAT 예측 알고리즘은 꽤 형편없습니다. 17:28 <jrandom> 흠 bar 17:28 <mrflibble> ㅎㅎ, 닉은 안 적을래요. 아, 그리고 IIP 티셔츠를 가지고 있지만 아직 살아 있고/체포 안 됐어요 17:28 <jrandom> 네, 저도 그렇게 읽었어요 17:29 <+bar> 관련해서 더 좋고 적절한 읽을거리들을 모아 보겠습니다. 17:29 <+redzara> 작은 질문: 0.6.1.3에서 재전송된 바이트의 평균 비율은 얼마였나요? 17:29 <jrandom> 고마워요 bar 17:29 <+fox> <jme___> bar, 그들이 얻은 예측은 일관되나요? 17:29 <+fox> <jme___> bar, 다시 말할게요 :) 17:29 <+fox> <blx> jrandom, 슬픈 소식이네요 17:30 <jrandom> redzara: 그걸 netDb에 넣는 걸 불행히도 잊었어요. 지금은 2.6과 3.8을 보고 있네요 17:30 <jrandom> blx: 저도요 :( 17:30 <+fox> <jme___> bar, NAT 박스의 동작을 분석해서 예측 공식을 찾았을 때, 그 NAT 박스에서 항상 통하나요? 아니면 어떤 때는 되고 어떤 때는 실패하나요? 17:30 <jrandom> blx: 지금 classpath와 병합을 좀 하고 있다고 들었으니, 그게 정리되면 좋겠어요 17:30 <+fox> <blx> 아마 파티엔 못 끼겠네요 17:30 <jrandom> blx: kaffe만 고집하시는 건가요, 아니면 OSS/DFSG를 고집하시는 건가요? 17:31 <+fox> <blx> free software 17:31 <+fox> <blx> dfsg라고 할 수도 있죠 17:31 <jnymo> 만약 i2p 사용자가 i2p용으로 호스팅 서버를 쓰고 싶다면, 어디가 관대한 규정에 저렴한가요? 17:31 <+bar> jme___: hamachi는 전체 연결 시도의 97%를 중개할 수 있다고 알려져요. 포트를 할당할 때 거의 랜덤에 가까운 동작을 보이는 NAT도 있는 듯해요 17:32 <jrandom> 좋아요, blx. 뭔가 방법을 찾을 수 있을 거예요. kaffe는 예전엔 잘 됐고, 우리는 sun specific한 것에 의존하지 않아요 17:32 <jrandom> jnymo: 전 sagonet.net을 씁니다만, 가격이 65/월에서 99/월로 올랐어요(빠른 링크에 월 1250GB 포함) 17:32 <jrandom> 독일에도 저렴한 곳들이 있는 걸로 알아요 17:33 <+fox> <jme___> bar, 97%면 엄청나네요 17:33 <jrandom> redzara: 재전송률은 얼마로 보이나요? 17:33 <+bar> jme___: 네, 그래서 대부분의 대칭 NAT는 예측 가능하다고 생각해요 17:33 <+fox> <blx> jrandom, 정말 이쪽에 관심 많아요 :) 17:33 <+fox> <jme___> bar, 뭘 하실 건가요? 릴레이, UDP 홀 펀칭, cnx reversal… 다른 기술도 있나요? 17:33 <jnymo> 99가 평균적으로 비싼가요? 17:34 <+redzara> jrandom 3;8과 4.2 사이 17:34 <jrandom> jme___: 우리는 udp라, connection reversal은 필요 없어요 :) 17:35 <+bar> jme___: 제가 전문가까진 아니고, 아마 다음 주 회의에 더 많은 정보를 가져올 수 있을 듯해요(하지만 냄새로는 프로파일링 + UDP 홀 펀칭 ;) 17:35 <jrandom> jnymo: 1250GB 기준이면 비싼 편은 아니죠. 50-100GB/월에 60-120달러/월을 본 적 있어요 17:35 <jrandom> bar: UPnP가 더 나은 방법일 수도 있지 않을까요? 17:35 <+fox> <jme___> jrandom, UDP여도 유용하긴 해요 :) 17:35 <+redzara> jrandom : 그런데 일부 노드만 큰 영향을 주네요, 아마 오래된 노드들 17:35 <+fox> <jme___> vulpine: 알겠어요 17:35 <jrandom> 다만 그건 자기 NAT를 제어할 수 있는 사람들만 도움 되죠 17:36 <+fox> <jme___> UPnP는 지원해야 하지만 다른 수단을 배제하진 않아요 17:36 <jrandom> 뭐, 우리는 지금까지도 UPnP 없이 모든 걸 하고 있어요 17:36 <+fox> <jme___> 왜냐면 UPnP를 지원하지 않는 NAT가 많거든요 17:36 <jrandom> 맞아요, 예를 들어 ISP의 NAT 같은 17:36 <+bar> jrandom: UPnP에 보안 이슈가 없다면, 나쁠 건 없죠. 다만 hamachi는 UPnP를 쓰지 않아요 17:36 <+fox> <jme___> 여기서 ‘must’ = 최대 연결성을 제공하기 위해 17:37 <+fox> <jme___> 자, 다시 C++로 돌아갑니다 :) 17:38 <jrandom> 맞아요 jme___, 우리가 cone/restricted 홀 펀칭에 더해 symmetric 홀 펀칭도 할 수 있다면, 아주 좋죠 17:38 <jrandom> 이따 봐요 jme___ 17:38 <jrandom> 네, UPnP 없이 할 수 있으면 이상적이죠 17:39 <jrandom> 좋아요, 회의에서 더 얘기할 거 있나요? 17:41 <jrandom> 없으면… 17:41 * jrandom 마무리 준비 17:41 * jrandom 회의를 *탁* 닫는다