I2P 개발자 회의 - 2006년 4월 4일

16:21 <jrandom> 0) 안녕 16:21 <jrandom> 1) 네트워크 상태와 0.6.1.14 16:21 <jrandom> 2) Syndie 구상 16:21 <jrandom> 3) 로컬 jbigi 최적화 16:21 <jrandom> 4) ??? 16:21 <jrandom> 0) 안녕 16:21 * jrandom 손을 흔든다 16:21 <jrandom> 주간 상태 노트를 http://dev.i2p.net/pipermail/i2p/2006-April/001275.html 에 올렸어요 16:21 * Complication 읽는 중 16:22 <jrandom> 여러분이 그 (간단히 정리한) 글을 읽는 동안, 1) 네트워크 상태부터 들어가죠 16:23 <@cervantes> (포럼 복구됨) 16:23 <jrandom> 0.6.1.13 사용에 영향을 주는 문제가 몇 가지 있는데, 그중 대부분은 원인을 찾아 해결했습니다 16:24 <Complication> 여기서는 '네 번째' CVS 빌드에서 그래프가 달라진 걸 확인했어요 16:24 <jrandom> 아직 테스트·개선 중인 몇 가지 꼬인 부분이 있긴 하지만, 며칠 내로 릴리스가 나올 거예요 16:24 <Complication> 전반적으로 더 안정적이고 덜 들쭉날쭉해졌습니다 16:24 <jrandom> 이런, -4로 올리는 걸 잊었네요, 그죠? 16:24 <jrandom> (좋아요, 오늘 저녁 늦게 -5를 내보낼게요) 16:24 <jrandom> 멋져요, Complication 16:25 <Complication> 하지만 jbigi 영향도 배제하지 않았으니 제 인상이 jbigi 때문일 수도 있어요 16:25 <Complication> 지금은 한동안 지나고 나니 재전송률도 15%까지 내려왔어요 16:28 <jrandom> 흠, 제 평균 SSU RTO도 3초 상한에 가까워지는 게 보이네요 16:28 <jrandom> (그래도 재전송률은 매우 낮아요, 5% 미만) 16:29 * Complication 한 번 더 확인해본다 16:29 <Complication> 대략 원시 평균값이 1500을 약간 넘는다고 해보죠 16:29 <Complication> (여기서는요) 16:30 <+fox> <BrianR___> jrandom: I2P 패킷에 사실상의 'MTU'가 있나요? 16:30 <jrandom> 아, 알겠어요. 그게 조금씩 올라가면 재전송률은 내려갈지도요 16:30 <Complication> 처음에는 더 작은 MTU로 시작하더니, 지금은 1350까지 올라갔더라고요 16:30 <jrandom> BrianR___: 네, 1350 또는 608입니다 (`http://localhost:7657/peers.js` 에 표시됨) 16:31 <jrandom> 큰 MTU에서 실패율이 너무 높으면 더 작은 MTU로 되돌아가고 (작은 MTU에서 실패율이 너무 낮으면 더 큰 MTU로 올라갑니다) 16:31 <+fox> <BrianR___> jrandom: 그게 내부 페이로드 기준인가요, 아니면 바깥의 IP 패킷 기준인가요? 16:31 <+fox> <BrianR___> 즉, I2P 스트림으로 데이터 블록을 보낸다면, 오버헤드를 최소화하기 위한 조각의 이상적인 크기는 얼마인가요? 16:31 <jrandom> 그건 UDP 페이로드 기준이에요 16:32 <jrandom> 스트림은 두 레이어 위에 있어요 16:32 <jrandom> (tunnel에서 한 번 단편화가 있고, 그 다음 stream/i2cp 수준에서 또 단편화가 있어요) 16:32 <+fox> <BrianR___> 네... 단편화를 최소화하는 이상적인 크기가 있나요? 16:32 <jrandom> streaming lib(스트리밍 라이브러리)을 사용하는 앱의 이상적인 블록 크기는 '큰 것'입니다. 그래야 streaming lib이 적절한 크기를 사용할 수 있어요. 16:33 <jrandom> (한마디로, 커튼 뒤 사람은 신경 쓰지 마세요) 16:33 <+fox> <BrianR___> 아아.. 그럼 파이프라이닝 같은 걸 고려해야겠네요.. 16:34 <+fox> <BrianR___> 요청/응답 트래픽이 많은 앱을 계획 중이에요... 16:34 <jrandom> 그럼 너무 잦은 왕복을 줄이도록 배치 처리하는 걸 권해요 16:34 <Complication> 아마 트래픽을 집중시키면 어느 정도 도움이 될 거예요 16:37 <jrandom> 좋아요, 1) 네트워크 상태에 대해 더 있을까요, 아니면 2) Syndie 구상으로 춤추듯 넘어갈까요 16:38 * jrandom 흔들흔들 춤춘다 16:39 <jrandom> 이건 주로 자리 표시와 CFP입니다. Syndie는 동작과 UI 모두에서 꽤 큰 개편이 있을 예정이니, 반드시 다뤄져야 한다고 생각하는 핵심 기능이나 사용 사례가 있다면 연락 주세요 16:40 <jrandom> (세부 사항이 더 갖춰지면 물론 더 많은 정보를 드릴게요) 16:42 <jrandom> 지금은 그 정도면 될 것 같고, 3) jbigi 최적화로 넘어가죠 16:42 <@frosk> 그리고 저는 'plotting'이 Syndie의 jrobin 관련 그래프 얘긴 줄 알았는데요 :) 16:43 <jrandom> ㅎㅎ 16:43 <jrandom> 하루 게시물 수, 작성자별 게시물 수, 하루 신규 작성자 수 같은 걸 그려보는 것도 재밌겠죠 ;) 16:44 <Complication> 아, Syndie 관련해서 한 가지 (미안, 이제야 생각났어요) 16:44 <Complication> =한 가지 16:44 <@frosk> 어느 쪽으로 할래요, 0 아니면 1? :) 16:44 <Complication> 즐겨찾는 작성자와 블랙리스트된(스팸) 작성자를 두 개의 다른 목록으로 분리하는 게 실용적일까요? 쉽나요/어렵나요? 16:45 <Complication> addresses.jsp에서요 16:45 <jrandom> 오, 네, 큰 어려움 없어요 16:46 <jrandom> 그건 개편에도 좋은 아이디어고, 0.6.1.14 빌드에 넣어볼 수도 있겠네요 16:47 <Complication> 아뇨, 지금 급한 건 아니고, 그때 봤던 걸 방금 떠올랐을 뿐이에요 16:47 <Complication> 어쨌든, Linux/AMD64에서 로컬로 컴파일하고 GMP 4.2를 사용하면 jbigi가 더 빨라집니다 16:48 <jrandom> 좋네요 16:48 <jrandom> 그걸 GMP 4.1.2에서 -O3 -m64와 비교해봤나요? 16:48 <Complication> 그리고 저는 완전 엉뚱한 컴파일 플래그를 쫓아가느라 바보 짓을 했네요 :O 16:48 <@cervantes> 참고 링크는 `http://forum.i2p/viewtopic.php?t=1523&start=30` 였어요 16:48 <jrandom> 아, 고마워요 cervantes 16:48 <Complication> jrandom: 아직 비교는 못 했는데, 해볼게요 16:49 <Complication> 다음 예정된 재부팅 때요 16:50 <jrandom> jbigi 빌드 과정은 본질적으로 "GMP를 빌드하고, jbigi.o를 빌드한 다음, 둘을 링크한다"이므로, GMP에 대해 하고 싶은 최적화는 1단계에서 모두 적용할 수 있어요 16:50 <@cervantes> 제가 예전에 한 테스트들에선 -O3와 -O2의 차이를 거의 못 봤어요. x86_64에선 다를지는 모르겠지만요 ... *shrug* 16:50 <jrandom> 맞아요, 컴파일러 버전에 따라 다를 수도 있죠 16:50 <jrandom> (특히 3.3/3.4/4.0/4.1 관련 이슈들 때문에요) 16:51 <@cervantes> 그 스레드에서 제가 말했던 걸 다시 한 번... 당분간은 Windows64 최적화 jbigi를 보긴 어려울 거예요 16:51 <+fox> <BrianR___> i2p stream lib이 페이로드 압축을 하나요? 16:52 <Complication> BrianR: 네 16:52 <@cervantes> 누군가 M$ VC 2005에 64비트 SDK까지 갖추고 gmp를 컴파일하려고 고생 좀 해주지 않는 한요 16:52 <Complication> 적어도 제 지식으로는요 16:53 <@cervantes> (gmp를 VC 프로젝트로 포팅하는 게 어딘가에 있긴 했어요) 16:53 <jrandom> cervantes: 음, amd64/win에서 /동작하는/ 게 하나 있긴 한데, 하드웨어를 최대한 활용하진 못해요 ;) 16:53 <jrandom> (새 머신이 오면 손볼 수 있을지도요. amd64거든요) 16:53 <+fox> <BrianR___> 비트를 아끼려고 바이너리 프로토콜을 써야 할지, 아니면 zlib 같은 걸로 ASCII 프로토콜을 잘 압축해도 충분할지 고민 중이에요.. 16:54 <@cervantes> 좋네요 - 안타깝게도 Mingw64나 cygwin64는 가까운 시일 내엔 나올 것 같지 않지만요... 16:54 <jrandom> BrianR___: 성급한 최적화는 모든 악의 근원이라죠, 뭐 그런 거예요... 16:55 <Complication> 적어도 부분적으로 사람이 읽을 수 있는 프로토콜이 보통은 디버그하기 더 쉬워요. 하지만 결국 무엇을 하느냐에 달렸겠죠 16:56 <Complication> (암호화 같은 건 어쨌든 사람이 읽을 수 있는 걸 싫어하니까요 :) ) 16:57 <Complication> 하지만 I2P가 암호화도 하고 압축도 한다면, 그 위에서 이루어지는 많은 일들은 사람이 읽을 수 있는 프로토콜로도 충분히 할 수 있을 가능성이 커요 16:58 <jrandom> 네 16:58 <jrandom> 좋아요, 3) jbigi 관련해서 더 있을까요? 16:58 <jrandom> 없다면 4) ??? 로 넘어가죠 16:59 <jrandom> 회의에서 더 얘기할 거 있는 분? 17:01 <+tethra> 최근에 익명 협업 도구에 대한 얘기를 들은 것 같아요 17:01 <+tethra> 어떤 종류인지, 그리고 Syndie와 비슷한 형태인지 좀 더 자세히 말씀해 주실 수 있나요? 17:02 <@cervantes> irc와 syndie는 익명 협업 도구죠 :) 17:02 <jrandom> 음, 어떤 걸 말씀하시는지 잘 모르겠네요 - 아니면 계획 중인 syndie 개편을 말하는 건가요? :) 17:02 <+tethra> 그렇네요. 17:02 * tethra도 잘 몰라서 물어본 거예요 17:02 <+tethra> 포럼에서 그런 얘기가 있었어요 - 익명이 필요한 이유 같은 것들 17:03 <+tethra> 인용하려면 스레드를 찾아볼게요 17:03 <jrandom> 아 그렇군요 17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 17:03 <jrandom> 사용 사례 스레드군요 17:03 <+tethra> - 익명으로 호스팅되면서도 공개적으로 접근 가능한 포럼/게시판/위키 17:03 <+tethra> 맞아요 17:04 <+tethra> Syndie 같은 걸 기반으로 한 i2wiki 유형의 프로젝트가 생길까요, 아니면 사용자에게 맡길 건가요? 17:04 <jrandom> 거기에 좋은 아이디어와 피드백이 꽤 있었어요 17:05 <jrandom> syndie 게시물을 편집할 수 있는 기능은 자주 요청돼 왔고, 그게 있으면 리치 에디터로 위키를 해낼 수 있겠죠 17:05 <jrandom> 하지만 당연히 아무것도 진공 속에서 존재하진 않아요 - 누군가 그게 필요하다고 믿는다면, '있잖아, 위키는 필수야, 이유는 이거야'라고 말해줘야 하죠 17:06 <jrandom> 만들 /수 있는/ 앱은 무한히 많지만, 우리는 강한 익명성과 강한 보안을 목표로 하므로 무엇을 만들지 신중해야 합니다 17:07 <+tethra> 맞아요 17:07 <+tethra> 그렇다면, 익명성과 보안을 유지하기 어려운 것일수록 그걸 잘하는 사람이 맡는 게 더 낫지 않을까요? 17:08 <jrandom> 그럴 가능성이 크죠. 다만 비밀 결사 같은 건 없어요 - 누구나 배울 수 있어요 17:08 <+tethra> (핵심적인 것들요. 딱히 뭘 지목하는 건 아니지만요.) 17:08 <+tethra> 맞아요 17:09 <+tethra> 하지만 자기와 다른 사람들의 익명성을 희생해가며 배우는 건 최선의 방식은 아니죠 17:10 <jrandom> 물론 누구나 어딘가에서 시작해야 하니까요 17:10 <+tethra> (아마 누군가 샌드박스 같은 걸 만들어서 사람들이 $software를 돌려보고, 다른 사람들이 공격해보는 식이면 초보/미경험자에게 좋지 않을까요?) 17:10 <+tethra> 네 17:14 <jrandom> 좋아요, 회의에서 더 얘기할 거 있는 분? 17:15 <jrandom> 없다면 17:15 * jrandom 마무리하려 한다 17:15 <@cervantes> *에헴* 17:15 * jrandom 잠깐 멈춘다 17:16 <jrandom> 무슨 일 있어요, cerv? 17:16 <Complication> 오, 멋져요, baf를 찾았어요 ;P 17:17 <jrandom> baf-차단 ;) 17:17 <@cervantes> 헙 미안, 계속 baf 하세요 17:17 * jrandom 마무리를 재개한다 17:18 * jrandom 회의를 *baf* 하며 종료한다