I2P 개발자 회의 - 2006년 1월 17일

15:40 <jrandom> 0) 하이 15:40 <jrandom> 1) 네트워크 상태와 0.6.1.9 15:40 <jrandom> 2) tunnel creation crypto(터널 생성 암호화) 15:40 <jrandom> 3) Syndie 블로그 15:40 <jrandom> 4) ??? 15:40 <jrandom> 0) 하이 15:40 * jrandom 손을 흔듭니다 15:40 <jrandom> 주간 상태 노트가 @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html 에 게시됨 15:41 <@cervantes> 퓨, 다행히 i2p가 NASA보다 더 신뢰할 만하군요 15:41 <jrandom> 헤헷 15:41 <tethra> 하하 15:41 <jrandom> (제가 20분 늦긴 했지만... ;) 15:41 <jrandom> 아무튼, 1) 네트워크 상태와 0.6.1.9 로 들어가죠 15:42 <wmpq> NSA든 NASA든, 별로 다르지 않죠? 15:42 <@cervantes> 나는 jrandom이 아니라 I2P라고 했어요 ;-) 15:42 <jrandom> 좋은 지적이네요, cervantes ;) 15:42 <tethra> 바보 같은 소리 마요, jrandom이 곧 i2p죠! ;D 15:42 <@cervantes> 오, 저는 그게 일종의 사고방식인 줄 알았는데 15:42 <wmpq> [redact] 15:43 <jrandom> 헤헷 아무튼, 0.6.1.9가 배포되어, 네트워크의 70%가 업그레이드됐습니다(모두들 감사해요) 15:43 <Pseudonym> 음, 감칠맛 나는 새 릴리스 15:44 <+zzz> 클라이언트 tunnel 구축 성공률이 여전히 30% 미만 15:44 <jrandom> end-to-end 처리량이 크게 늘었다는 보고는 많이 못 들었습니다만, 일부 router는 T1 회선을 넘어 포화시키고 있어요 15:44 <+zzz> ~40%에서 내려옴 15:44 <+Complication> 대역폭은 정상으로 보이고, 릴리스 전 마지막 CVS 때보다 약간 높습니다. 피어 수는 좀 더 많은 것처럼 보이네요. 15:45 <jrandom> 흠, 네, zzz, 그건 크게 걱정하지 않아요. 어차피 0.6.2에서 전면 재작업될 테니까요 15:45 <+zzz> 평균 대역폭이 ~12K에서 ~20K로 상승 15:45 <jrandom> 0.6.1.9는 동의 가능성이 더 높은(즉, 고용량) 피어를 고르지 않고, 대신 처리량이 더 높은 피어에 집중하도록 되어 있어요 15:46 <+Complication> 재전송 비율(릴리스 당일 밤에 7%로 기록됨)이 6%대까지 내려왔습니다 15:46 <jrandom> 그래요, router들이 1~300KBps까지 밀어붙이다 보니 편차가 생길 수밖에요 15:46 <jrandom> 흠, 꽤 미친 수치네요, Complication. 저는 2~3%밖에 못 봤어요 15:46 <jrandom> (하지만 당신 관측을 의심하진 않아요) 15:47 <+Complication> 거의 아웃바운드를 끝까지 쓰고 있어요 15:47 <+Complication> (즉 회선 용량을 꽉 채운다는 뜻이에요) 15:47 <jrandom> 아, 그럼 그렇죠 15:47 <+zzz> 여전히 GET 전에 NULL이 들어와서 405 Bad Method가 발생합니다. 발생률은 줄어드는 듯한데, 확실하진 않아요 15:48 <jrandom> 맞아요 zzz, streaming lib(스트리밍 라이브러리)에 손볼 게 좀 있지만, 아마 0.6.2의 tunnel 개편 이후에나 다루게 될 듯해요 15:48 <jrandom> (하지만 그 전에 누가 더 파보겠다면야, 대환영이죠) 15:49 <jrandom> Complication: 대역폭 제한을 회선 용량의 70% 정도로 낮추면 실패율이 다시 합리적인 수준으로 돌아오나요? 15:49 <+zzz> 연말 직전에 코드에 들어간 무언가였다고 여전히 생각해요. 최근 변경을 잊기 전에 보는 게 좋겠죠 :) 15:50 <+zzz> 최초 발견 12월 29일 15:50 <jrandom> 맞아요 zzz, 확실히 그럴 겁니다. 지금은 타임아웃을 더 엄격히 존중하는 방식과 관련이 있을 듯해요 15:51 <+Complication> jrandom: 사실 지금 막 그걸 시도 중이에요 :) 15:51 <+Complication> 당신이 물어보기 몇 초 전에 조정했는데, 곧바로 알긴 어렵겠죠 15:51 <jrandom> 하지만 그걸 정리하려면 꽤 많은 작업이 필요하고, 새 tunnel 생성 코드 구현이 더 중요해요(이는 tunnel 구축 성공률을 크게 높이고 익명성 개선도 대폭 추가할 거예요) 15:51 <jrandom> 좋아요 Complication, 네, 3~6시간은 두세요 15:51 <jrandom> (기존 값/연결이 정리되도록) 15:52 <+zzz> 현재 GET의 약 1%~3%가 손상돼요 15:54 <jrandom> 그럼 streaming lib 변경을 되돌리자고 제안하는 건가요(그러면 i2psnark가 12~48시간 안에 모든 사용자에게 OOM을 일으킬 텐데요)? 그리고 streaming lib 재작업은 0.6.2의 tunnel 작업 이후로 미루고, 아니면 streaming lib를 손보는 동안 0.6.2의 tunnel 작업을 1~2주 미루자는 건가요? 15:55 <+zzz> 되돌리진 말아야죠 15:56 <+zzz> 당신 판단에 맡길게요 15:56 <+Complication> 꽤 교묘한 버그라고밖에 말 못 하겠네요 15:58 <jrandom> streaming lib에는 다른 버그들도 있어서, 일단 소매를 걷으면 한꺼번에 처리하고 싶어요(남은 버그들은 겉으로 잘 드러나지 않거든요). 15:59 <jrandom> 반면, tunnel 작업을 먼저 하면 대역폭 사용량을 크게 줄이고, 구축 성공률이 올라가며, 익명성도 개선되고, 라이브 네트워크에서 부하 분산을 모니터링하는 능력도 향상됩니다 15:59 <Pseudonym> 웹서핑에서 실패율이 1~3% 정도라면 미뤄도 되겠다고 봐요. 제 개인 의견이지만요. 16:00 <jrandom> 저도 tunnel 작업을 먼저 하려는 쪽입니다. 배포한 뒤에는 네트워크를 수동으로 모니터링하면서 streaming lib는 적극적으로 개편할 수 있으니까요 16:01 <jrandom> (Syndie 편집/게시용 GUI도 만들고 싶지만, 그건 둘 다 정리된 다음으로 미루죠 ;) 16:01 <+Complication> 여기도 그 정도 비율이에요 16:02 <+Complication> (제 eepsite에서) 16:04 <jrandom> 좋아요, 여러분도 그 비율이 변하는지 계속 지켜봐 주시면 좋겠고, 그동안 저는 tunnel 개편을 이어가겠습니다. 그 다음에 streaming lib 개편이 올 거예요(둘 다 0.6.2 전에 반영될 겁니다) 16:05 <jrandom> (또는 누가 streaming lib를 파보거나 [i2ptunnel과 이상한 상호작용이 있는지] 확인해 보고 싶다면 알려 주세요!) 16:06 <+Complication> jrandom: 그냥 궁금한데, 테스트 앱으로 i2ptunnel을 배제해 볼 수 있을까요? 16:07 <+Complication> 예를 들어 jnymo의 샘플 앱 같은 것이 null도 받는다면, 그건 i2ptunnel을 용의선상에서 지울 수 있겠죠? 16:07 <jrandom> 그렇게 하려면 얇은(in-VM) I2PSocket 구현을 붙이면 되긴 해요 16:07 <+Complication> 제 기억이 맞다면, 그 샘플은 streaming lib를 직접 썼으니까요... 16:08 <+Complication> (혹은 거의 직접적으로) 16:08 <jrandom> 맞아요, streaming lib를 쓰는 무언가로 재현된다면 i2ptunnel은 무죄겠죠 16:10 <+Complication> 흠, 누가 먼저 하지 않는다면(전 먼저 웹캐시 작업을 끝내 볼게요) 그런 걸로 HTTP를 에뮬레이션해 볼 수도 있겠네요... 16:10 <jrandom> 끝내주네요, 고마워요 Complication 16:10 <jrandom> 좋아요, 1) 네트워크 상태와 0.6.1.9에 대해 더 있을까요? 16:11 <jrandom> 없다면, 2) Tunnel creation crypto로 슬슬 넘어가죠 16:11 <+Complication> 아뇨, 별 소득이 없을 수도 있고, 중간에 넘어진 채 끝날 수도 있지만... 흥미로운 가능성이긴 해요 16:11 <jrandom> 맞아요, 탐구는 반드시 긍정적 결과를 내야만 가치 있는 건 아니죠 :) 16:12 * cervantes, 연말 직전 소스 변경에서 'moo' 예외를 발견... 혹시 그게 문제? :) 16:13 <jrandom> 좋아요, 메일에 참조된 새 tunnel creation crypto 명세가 있어요. 작년 10월에 toad, Michael, 그리고 제가 메일링 리스트에서 논의한 내용을 바탕으로 했습니다 16:14 <jrandom> 한번 살펴보시고 의견을 알려 주세요. 먼저 구현해야 할 것들이 있어서 당분간 라이브 네트워크에는 배포되지 않겠지만, 곧 오긴 합니다 16:14 <+Complication> 'moo'가 자바 예약어였나요? ;P 16:14 <+zzz> 2) 관련해서 상태 메일의 참고자료를 검토하는 걸 돕겠습니다 16:14 <+Complication> tunnel 암호화 주제에 대해, 아래 바꿔 쓴 설명이 괜찮은지 확인해 주시겠어요? 제가 제대로 이해했는지만 확인하고 싶습니다... 16:14 <jrandom> 고마워요 zzz 16:15 <+Complication> "각 홉은 자신의 레코드에서 ElGamal 개인키로 복호화해 얻은 reply key로 모든 레코드를 암호화하며, 이렇게 암호화함으로써 tunnel 소유자가 수행한 복호화(혹은, 암호화라고 해야 할까요)의 한 층을 역전시켜, 다음 참가자의 레코드가 다음 참가자의 ElGamal 개인키로 읽히도록 만든다?" 16:15 <jrandom> Complication: 네 16:15 <+Complication> 아니면 제 재서술이 완전히 틀린 건가요? 16:16 <+fox> <jme___> 그리고 너무 복잡해요, 제 생각엔 16:16 <jrandom> 맞는 것 같아요. 다만, 문장이 너무 장황하네요 :) 16:16 <+Complication> 그걸 더 잘 시각화할 방법이 떠오르지 않았어요. 그렇게 하는 것도 충분히 어렵더라고요. :P 16:16 <jrandom> (아니면 jme___, 알고리즘이 너무 복잡하다는 말인가요?) 16:17 <+fox> <jme___> 아니요, 문서를 급히 읽어보려다 기초 지식이 필요한 부분이 너무 많아서 포기했어요 16:17 <+fox> <jme___> 반면에, 많이 시도해 보진 않았습니다 :) 할 일이 있어서요 16:17 <jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD 16:18 <+fox> <jme___> 이 동료 검토는 형식적인 건가요, 아니면 정말 걱정되거나 확신이 없는 건가요? 16:19 <+Complication> 음, 밑단 메커니즘이 뭘 하는지 아는 건 언제나 좋죠... 16:19 <jrandom> 제 의도대로 동작한다는 데는 자신 있지만, 누가 문제를 발견한다면 정말로 관심이 있어요 16:19 <+fox> <jme___> 후자라면 시간을 낼 수 있겠지만, 제 지식이 오래돼서 당장 떠오르진 않네요 16:20 <+fox> <jme___> 아니라면 믿겠습니다 :) 16:20 <jrandom> 노트 섹션에 몇 가지 질문이 있어요 - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.notes 16:22 <jrandom> 급할 건 없어요. 이 새 암호화가 실제로 router에서 사용되기까진 아마 일주일이나 이주 정도 걸릴 거예요 16:22 <@cervantes> jrandom: 그와 관련해, 홉 사이에 임의 지연을 넣으면 성능 저하가 크지 않을까요? 16:22 <@cervantes> 타이밍 공격을 막기엔 그게 가장 그럴싸해 보여서요 16:23 <jrandom> 그건 tunnel 생성 단계라 지연이 큰 문제는 아니겠지만, 대형 장애 시에는 lease set이 너무 일찍 만료될 수 있어요 16:25 <jrandom> 음, 그 지연이 얼마나 효과적일지는 모르겠어요. 크게 도움이 될 수도, 아닐 수도 있죠. 하지만 라이브 tunnel은 어차피 blending을 써서 그 tunnel에서 담합하는 피어를 찾아낼 수 있으니, 크게 중요하지 않을 수도 있어요 16:25 <+fox> <jme___> 좋아요, 다시 읽어볼게요 16:27 <jrandom> 고마워요. 서두를 건 없지만, 누가 생각이 떠오르면 제게 보내 주세요(아니면 목록이나 여러분 블로그 등으로) 16:27 <jrandom> 좋아요, 2에 대해 더 없으면 3) Syndie 블로그로 넘어갈까요? 16:29 <jrandom> (넘어간 걸로 치죠) 16:29 <jrandom> 좋아요, Syndie에 멋진 블로깅 기능이 새로 들어갔으니 파보세요 ;) 16:29 <@cervantes> 아주 쿨 16:30 <jrandom> 왼쪽의 그룹에는 임의의 URL에 대한 링크뿐 아니라 블로그, 블로그 내 게시물, 블로그 게시물의 첨부 파일로의 링크를 넣을 수 있어요 16:30 <jrandom> 게시물 스타일이나 아이콘 등을 블로그별/태그별로 지정하는 등 가능한 개선이 아주 많습니다. 누가 거기에 파고들고 싶다면 최고예요(그리고 눈에 확 띄는 효과가 있을 거예요 :) 16:31 <@cervantes> 그런데 댓글에 정의된 외부 링크에도 대상 URL을 title 속성으로 설정해야 해요(왼쪽 패널에서 하신 것처럼) 16:31 <@cervantes> 댓글/게시물 16:32 <jrandom> 아, 좋은 생각이네요 16:33 <jrandom> (net.i2p.syndie.sml.BlogPostInfoRenderer의 renderLinks(...) 메서드 :) 16:34 <@cervantes> *메모메모* 16:35 <jrandom> 정보 제공용 eepsite의 실질적 대안이 되려면 Syndie 블로그에 또 무엇이 필요할까요? 물론 Syndie는 정적 콘텐츠라서 못 하는 일도 있지만, 콘텐츠를 배포하고 사람들이 댓글을 달 수는 있죠 16:36 <jrandom> 특별히 하고 싶은 커스터마이징이 있나요? 그렇다면 알려 주세요 16:37 <DoubtfulSalmon> jrandom: 스크립트로 기존 콘텐츠를 업데이트하기요? 16:37 <@cervantes> 날짜별 아카이브 16:37 <jrandom> DoubtfulSalmon: 스크립트로요? 16:37 <jrandom> cervantes: 아, '이전 글 5개' 링크 대신 작은 캘린더 위젯 같은 거요? 16:38 <@cervantes> 네 16:38 <DoubtfulSalmon> jrandom: 예를 들어 이 파일/텍스트가 저 파일/텍스트를 대체하게 하고 싶어요. 어떻게 하나요? 16:38 <jrandom> 좋아요, 그건 정말 쉬울 거예요(누가 HTML만 뚝딱 만들어주면 :) 16:38 <@cervantes> 아니면 더 단순하게 '지난달 게시물 보기' 16:39 <@cervantes> jrandom: 숫자만 들어간 7x6 테이블 하나면 되죠 ;-) 16:40 <jrandom> DoubtfulSalmon: 이미 게시된 콘텐츠를 바꾸는 건 흥미로운 방향입니다. 전반적으로 항상 통하진 않을 거예요. 유즈넷 제어 메시지(이전 글 취소 등)처럼 동작해야 하니까요 16:40 <jrandom> DoubtfulSalmon: 반면, 그냥 새 파일/항목을 게시하고 왼쪽의 링크를 새 파일/항목을 가리키도록 바꾸면 됩니다 16:40 <jrandom> (그렇게 하면 이전 콘텐츠는 남아 있고, 사람들은 새 콘텐츠로 안내됩니다) 16:41 <DoubtfulSalmon> jrandom: 네, 모두가 자신의 콘텐츠를 바꾸지 않아도 링크가 새 콘텐츠를 가리키기만 하면, 예전 콘텐츠가 남아 있어도 괜찮아요. 16:41 <jrandom> 본질적으로 diff를 게시하고 Syndie가 결과를 렌더링하게 해서 위키를 제대로 만드는 것도 가능하지만, 과할 수 있어요 16:41 <jrandom> 음, 알겠어요 무슨 말인지 16:42 <jrandom> 즉, 현재처럼 특정 버전의 콘텐츠로 가는 링크가 아니라, 리디렉션 가능한 링크를 원하시는 거군요 16:43 <jrandom> 아마 블로그의 북마크로 링크하고, 그 블로그의 현재 북마크를 불러와 가리키는 곳을 따라가면 정확한 버전을 찾는 식으로 할 수 있을 겁니다 16:44 <jrandom> 반대로, 새 버전을 이전 글에 대한 답글로 표시해서, 사람들이 링크를 따라가면 콘텐츠를 대체하는 답글로 이어지게 할 수도 있죠 16:44 <jrandom> (아마 그렇게 매끄럽진 않겠지만요) 16:44 <DoubtfulSalmon> 네: 예를 들어 현재 레이더 이미지처럼 10분마다 업데이트되는 무언가로 링크를 두고 싶어요. 그 콘텐츠가 네트워크 전역으로 퍼지지 않아도 괜찮지만, 누군가 제 페이지에 링크하면 사용자는 최신 이미지를 봐야 해요. 16:45 <jrandom> 그건 그들이 무엇을 원하느냐에 달렸죠. 참조 당시의 이미지를 가리키길 원하나요, 아니면 독자가 볼 때 이미지를 렌더링하는 서비스로 링크하길 원하나요? 16:45 <+Complication> cervantes: 오늘의 기이함 :D 마지막 글: http://forum.i2p/viewtopic.php?t=1199&start=15 16:46 <+Complication> 또 다른 로봇 지배자님 같더라고요 :P 16:46 <jrandom> 하지만 두 개념을 모두 지원하는 건 좋은 생각이고, 그게 큰 수고는 아닐 듯해요 16:46 <@cervantes> thnx 16:46 <jrandom> 다만 SML에 약간의 확장이 필요하긴 하죠(예: [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.webp"]) 16:47 * cervantes, 그런 게 많아지면 포럼 방어를 업그레이드할게요 16:47 <@cervantes> (그건 막는 법 이미 알아요) 16:47 <DoubtfulSalmon> jrandom: 콘텐츠 배포자가 콘텐츠를 삭제하지 않았다면 정적 버전에도 링크할 수 있어야 하고, 최신 버전을 가리키는 일반 URL에도 링크할 수 있어야 합니다 16:47 <jrandom> (이는 ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=의 현재 메타 포스트에서 북마크를 보고, 이름이 'radar.webp'인 항목에서 정확한 URI를 가져오는 방식) 16:48 <DoubtfulSalmon> jrandom: 그걸 지금 '태그 <이상한 문자열>에서 가장 최근 게시물 1개 보기' 같은 걸로 할 수 있을까요? 16:48 <jrandom> 아, 좋은 지적이에요 - 네, 가능합니다 16:49 <jrandom> 그걸 '$author가 쓴 $tag 태그의 가장 최근 게시물 보기'로 제한할 수도 있어요 16:49 <jrandom> (그래서 다른 사람들이 스푸핑하지 못하게요) 16:49 <DoubtfulSalmon> 그럼 사용자에게 이상한 태그 같은 게 보이지 않도록, 어떤 형태로든 UI를 제공하면 되겠네요 16:50 <jrandom> 그게 어떻게 보이는지 위에 예제가 있어요. 당장 URI는 기억 안 나지만... 어쨌든 링크된 텍스트를 감싼 링크입니다 16:50 <DoubtfulSalmon> 그 정보는 전부 URL 형태로 올 수 있다고 생각했어요. 16:51 <jrandom> 하지만 원본 SML을 직접 쓰는 건 확실히 번거롭기 때문에, SML을 만드는 GUI가 유용할 거예요 16:51 <jrandom> 그건 URL이 아니라 SML 태그의 속성이에요 16:52 <@cervantes> 그리고 SML GUI는 JavaScript 없이 만들기 까다롭죠 16:52 <DoubtfulSalmon> 그런데 검색 결과는 북마크할 수 있죠? 16:52 <jrandom> 검색 결과가 뭔가요? 16:52 <jrandom> 그리고 북마크가 무슨 뜻인가요? 16:52 <@cervantes> (아니면 브라우저 확장 ;-)) 16:52 <jrandom> 아, 브라우저 측 북마크요, 네 16:52 <+Complication> 필터 결과를 말하나요? 16:53 <jrandom> 하지만 그런 북마크는 일반적으로 공유되지 않아요 16:53 <DoubtfulSalmon> 음: '태그 Y가 달린 X의 가장 최근 게시물 1개 가져오기' 16:53 <jrandom> (사실 대부분은 가능하긴 한데, URL이지 URI가 아니라 보편적이진 않아요)) 16:53 <DoubtfulSalmon> 네, 다른 블로그에서도 그런 것들에 링크할 수 있으면 좋겠어요 16:54 <jrandom> DoubtfulSalmon: SML로 할 수 있어요 16:54 <jrandom> [blog tag="Y" bloghash="X"] 16:54 <DoubtfulSalmon> 오, 좋네요 16:55 <jrandom> JavaScript, XUL, Java, 혹은 OS별 클라이언트 앱 같은 것들 16:57 <@cervantes> 아, 좋네요. 그러면 스크립팅이나 플러그인 의존성이 있어도 괜찮다는 거군요 16:57 <jrandom> (우리 웹사이트가 0.6.2에 맞춰 개편되면, Syndie가 도대체 뭔지, 그리고 접시 닦기 빼고는 뭘든 할 수 있는지 설명하는 웹사이트도 반드시 만들 거예요 ;) 16:57 <@cervantes> (점진적 저하만 잘 되면요) 16:57 <jrandom> Syndie는 lynx로도 기능해야 하지만, 리치 클라이언트로 할 수 있는 게 아주 많아요 16:58 <jrandom> (s/function/functional/) 16:58 <@cervantes> 맞아요.. 그래서 lynx 사용자는 SML 레퍼런스 차트 정도만 보게 되겠죠, 그 이상은 없고요 16:58 <jrandom> 네, 지금도 그렇죠 16:58 <jrandom> 다만 아마 단순화된 SML일지도요, 잘 모르겠네요. 17:01 <+Complication> jrandom: 혹시 아주 미미하게라도... null 버그가 gzip 인코딩과 관련 있을 가능성이 있을까요? 17:01 <+Complication> 제 eepsite tunnel에서 gzipping을 어떻게 끌지 생각하고 있었어요... 17:01 <+Complication> 아니면 완전히 말도 안 되는 걸까요? 17:01 <@cervantes> 연말 직전에 i2ptunnel에 HTTP 압축기 관련 코드가 좀 추가되긴 했어요 17:03 <jrandom> 네, 그럴 수도 있어요 - 클라이언트 쪽에서는 i2ptunnel.gzip=false로 끌 수 있어요(/configadvanced.jsp). 다만 지금은 i2ptunnelhttpserver에서는 끌 수 없는 것 같네요 17:03 <+zzz> 압축이 없는 요청(Request) 측의 문제예요 17:03 <+zzz> 클라이언트가 false로 설정하면 서버는 압축하지 않아요 17:03 <+Complication> zzz: 아, 맞다, 그걸 잊었네요 17:04 <jrandom> (하지만 큰 어려움 없이 I2PTunnelHTTPServer에 추가할 수 있어요[310행 등]) 17:04 * Complication은 바보였네요, 사과드립니다 17:04 <@cervantes> (아니면 일반 tunnel을 쓰셔도 돼요) 17:04 <+Complication> 아하, 고맙습니다... 17:05 <jrandom> 흠, 다만 i2ptunnelhttpserver가 GET을 받을 때쯤엔 이미 null이 들어와 있겠네요 17:05 <+zzz> 네, orion을 HTTP tunnel로 다시 옮겼더니 페이지 로드 시간이 크게 개선됐어요. 다시 압축되니까요 17:05 <+Complication> 클라이언트와 서버가 gzipping에 동의해야만 시작된다는 걸 완전히 잊고 있었네요 17:05 <jrandom> 그래서 클라이언트 측일 순 있어도, 서버 측은 확실히 아니죠 17:05 <jrandom> 맞아요 zzz, 지금은 엄청나게 빨라요 :) 17:05 <+zzz> 그건 _응답_ 측이 아니라 _요청_ 측이에요 - 클라이언트나 서버 어느 쪽에서도 일어날 수 있어요 17:06 <jrandom> 맞아요 17:09 <jrandom> 좋아요, 3) Syndie 블로그에 대해 더 있을까요? 17:09 <jrandom> 없으면, 4) ???로 넘어가죠 17:09 <jrandom> 회의에서 더 제기할 사항 있나요? 17:10 <cat-a-puss> Complication: 자바의 gzip 스트림 + I2P tunnel. 작동하지 않습니다. Sun의 버그예요 17:10 <jrandom> 흠, cat-a-puss? 정말요? 17:10 <+zzz> HTTP 지속 연결 업데이트: 클라이언트 측은 대부분 완료, 서버 측도 순조롭게 진행 중, 견고화와 테스트가 많이 남았고, 완료 예상 2~4주 17:10 <jrandom> 잘했어요 zzz! 17:11 <cat-a-puss> jrandom: 예전에 그 얘길 했었죠. 왜 그런지에 대한 긴 설명을 찾을 수도 있겠지만, 어차피 그럴 이유가 없으니 어딘가에 그냥 문서화하는 게 제일일 거예요. 17:12 <jrandom> 흠, 맥락을 놓쳤네요. 정확히 무엇이 작동하지 않죠? Sun의 버그가 뭐죠? 17:14 <dust> 이런 이상한 로그가 떠요: 21:21:59.816 WARN [%d0%a2%d1%4f] net.i2p.util.EepGet : ERR: status <html> 17:14 <jrandom> 음, 흥미롭네요 17:15 <jrandom> 어떤 트래커요? 17:15 <cat-a-puss> jrandom: 제 기억으론 Sun은 헤더 없는 zip을 쓰고, 어떤 매직 넘버로 zip 스트림인지 식별합니다. 그런데 그 숫자가 우연히 음수라서, 어떤 이유로든 zip 스트림 안에 zip 스트림을 만들게 되면, 스트림에서 데이터를 부호 없는 바이트 시퀀스로 읽어버려서 그 매직 넘버가 다른 양수로 바뀌어 버립니다. (세부를 몇 가지 놓쳤을 수도 있지만, 요지는 이겁니다) 17:16 <dust> 예를 들어 OSDevWithCVS_3E.pdf.torrent 17:17 <dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ... 17:17 <jrandom> 흠, 그건 모르겠고, 그게 i2ptunnel 위의 gzip 스트림에 어떤 영향을 줄지는 잘 모르겠네요(만약 영향을 줬다면 전부 실패했을 거예요. 우리는 모든 걸 gzip하니까요) 17:19 <jrandom> 좋아요 dust, 그러면 postman의 트래커군요. 흠, dust, 0.6.1.9 쓰고 있나요? 17:20 <cat-a-puss> jrandom: 네, 그 문제를 겪은 게 거의 1년 전이라 잘 기억나진 않고, 1.5에서 고쳐졌는지도 모르겠어요. 하지만 일반적인 스트림은 다 잘 되다가, 압축 스트림으로 감싸는 순간 전부 실패하는 이유를 찾느라 정말 고생했었죠. 17:20 <dust> 네 17:20 <jrandom> cat-a-puss: 지난 1년간 I2P 위의 압축 방식은 대대적으로 바뀌었어요 ;) 17:21 <jrandom> (그리고 저는 개인적으로 1.5를 쓰지 않아요) 17:21 <jrandom> 하지만 우리는 그쪽 패키지 스트림을 쓰지 않고, 우리 방식으로 zip 인코딩을 명시적으로 합니다(호환성 때문이 아니라 익명성과 효율성 때문이죠) 17:22 <@cervantes> zzz: 요청에서 null이 정확히 어디서 발생하죠? GET 바로 뒤인가요? 17:22 <+Complication> 제 기억으론 그 전에요 17:23 <+fox> <lordalbert> 안녕하세요 17:23 <+Complication> 곁다리로: Celeron 300이 Sempron보다 재전송 비율이 두 배 낮게 나옵니다 17:23 <jrandom> 안녕하세요, lordalbert 17:23 <jrandom> 좋아요 Complication, 2~3%면 합리적이죠(물론 더 낮으면 좋겠지만) 17:23 <@cervantes> HEAD 요청을 잔뜩 날려보면 흥미로울 텐데요... 17:24 <jrandom> 네, 로컬 테스트 세트를 돌리면 좋겠어요. 다만 제 기억엔 Complication이 예전에 시도했는데 오류가 없었죠 17:24 <+fox> <lordalbert> 익명 트래커를 누가 만들 수 있나요? 제가 해보려는데 tunnel을 어떻게 쓰는지 모르겠어요 17:24 <+Complication> cervantes: 제 노드 두 개 사이에서 재귀 wget으로 유발해 보려 한 적 있어요 17:24 <+Complication> 일어나기 전에 지쳐버렸죠 17:25 <@cervantes> 헤헷 17:26 <+fox> <lordalbert> 'lo b0unc3 ;) 17:26 <+fox> <b0unc3> lordalbert, :D 17:26 <+Complication> lordalbert: 어느 부분에 조언이 필요하신가요? 17:27 <+Complication> 트래커 설정은, 불행히도 제가 몰라요. 17:27 <+Complication> I2PTunnel에 관해서라면 설명해 보죠... 17:27 <+fox> <lordalbert> BTtracker를 설치했고, 아주 잘 됩니다 17:28 <+Complication> 또한 트래커가 계속 익명을 유지하려면 꽤 신중한 설정으로 운영해야 한다는 점도 언급해야겠죠 17:28 <+fox> <lordalbert> 이제 익명화하고 싶어요 17:28 <+fox> <lordalbert> 그래서요 17:28 <jrandom> 회의 후에 함께 해결해 볼 수 있을 거예요. 일반 트래커를 쓰면 안 되고, 익명성을 위해 만들어진 걸 써야 해요 17:28 <+fox> <lordalbert> 방금 i2ptunnel을 만들었어요 17:29 <jrandom> (예: i2p 트래커들에서나 CVS에서 찾을 수 있는 bytemonsoon 수정판) 17:29 <+fox> <lordalbert> 이제 이 tunnel을 어떻게 쓰는지 알고 싶어요. tunnel은 만들었습니다 17:29 <jrandom> 좋아요, 회의에서 더 다룰 게 있을까요? 17:30 <jrandom> lordalbert: http://localhost:7657/i2ptunnel/ 에서 웹서버/트래커를 가리키는 'http server tunnel'을 만들 수 있어요. 하지만 익명용으로 수정되지 않았다면 트래커는 작동하지 않을 겁니다 17:30 <+fox> <lordalbert> 어떤 트래커를 써야 하죠? 17:31 <+Complication> postman은 수정된 ByteMonsoon 버전을 쓰는 걸로 알아요 17:32 <jrandom> i2p-bytemonsoon은 익명용으로 수정됐어요 - http://i2p-bt.postman.i2p/ 에 zip이 있고, http://dev.i2p.net/cgi-bin/cvsweb.cgi/bytemonsoon/ 에 CVS가 있어요. 다만 자세한 건 잘 몰라요 17:32 <+fox> <lordalbert> bytemonsoon은 구식 아닌가요? 17:32 <jrandom> 작동하면 구식이 아닙니다. 작동해요 17:33 <+fox> <lordalbert> 오케이 XD 17:33 <jrandom> 세상에 트래커는 많고, 어떤 개발자가 안전하고 익명으로 작동하도록 수정해 준다면 아주 좋죠 17:33 <+Complication> 좀 오래됐을 수는 있지만... IP 대신 destkeys로 확실히 동작해요... 17:33 <+Complication> 보안성과 누출 방지까지는 장담 못 하겠지만요 17:34 <jrandom> (익명성과 보안을 위해 duck 등이 수정했어요) 17:34 <+Complication> 하지만 꽤 오랫동안 돌아왔고, 그럭저럭 버티는 듯해요... 17:35 <jrandom> 좋아요, 회의에 더 없으면... 17:36 * jrandom 마무리합니다 17:36 * jrandom *baf*S 회의를 마칩니다