I2P 개발자 회의 - 2005년 11월 29일

15:25 <jrandom> 0) 안녕하세요 15:25 <jrandom> 1) 네트워크 상태와 0.6.1.6 15:25 <jrandom> 2) Syndie 15:25 <jrandom> 3) I2P Rufus 0.0.4 15:25 <jrandom> 4) ??? 15:25 <jrandom> 0) 안녕하세요 15:25 * jrandom 손을 흔든다 15:25 <jrandom> 주간 상태 노트가 올라왔습니다 @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html 15:26 * bar 가 jrandom에게 baf를 건넨다 15:26 <c3rvantes> 아직이야! 15:26 * jrandom 준비한다 15:26 <jrandom> 어... 15:26 <jrandom> 먼저 안건 몇 가지부터 처리하죠 :) 1) 네트워크 상태와 0.6.1.6 15:27 <jrandom> 최근 몇 번의 릴리스에서 많은 것들이 업데이트되었지만, 네트워크는 여전히 꽤 안정적인 편으로 보입니다. 15:28 <jrandom> 일부 router에서 참여가 심하게 튀는(spike) 일이 있었지만, 그건 꽤 무해합니다 15:28 <+legion> 멋지네요, 네트워크 상태가 더 좋아지고 있다는 데 동의합니다. 그리고 0.6.1.7에서 tcp를 빼는 건 왜 안 되겠어요 15:28 <jrandom> (아, 정확히는 tunnel 참여 스파이크요) 15:29 <@cervantes> 농담이 아니네 15:29 <jrandom> 잘은 모르겠어요, legion. tcp만 쓸 수 있는 사용자가 몇 명 있을 수도 있는데, 제 기억엔 한 명, 많아야 두 명 정도였던 것 같아요 15:29 <+legion> 음 0.6.1.5에서는 가끔 router가 알아서 재시작하더군요. 15:29 <+Complication> 제 것은 합리적인 범위 내에서, 참여 tunnel이 100~250 사이로 변동하고 있어요 15:29 <jrandom> 굳이 유지해야 할 만한 좋은 이유는 떠오르지 않고, 없애야 할 이유는 몇 가지 떠오르네요 15:30 <jrandom> 좋아요, Complication 15:30 <jrandom> (그 수치들은 stats.i2p/에 따르면 꽤 평균적이에요. 하지만 그런 숫자는 익명성에 해를 끼칠 수 있으니, 특히 기록되는 회의에서는 밝히지 않는 게 좋아요 ;) 15:30 <+Complication> 제 오래된 셀러론은 아직도 10시간마다 한 번쯤 자동 재시작하네요 15:30 <+Complication> 그 외에는 어느 때보다 연결이 잘 됩니다 15:30 <Pseudonym> 그걸 빼야 하는 이유가 뭔가요? 15:31 <+Complication> TCP는 비용이 큽니다 15:31 <@cervantes> 내 router는 완전히 녹초가 됐어 15:31 <+Complication> 연결당 스레드 수라는 측면에서요 15:31 <@cervantes> Complication: 거기에 10을 곱하면 지금 내 router 범위가 나와 ;-) 15:31 <+legion> 내 것도 참여 tunnel이 200~400 사이에서 변동해서, 어느 때보다 좋아 보입니다. 15:32 <+Complication> cervantes: 아이구 아이구 15:32 <+Complication> 돌발 사고로 참여 tunnel이 2000까지 간 적을 본 적이 있는데, 그건 여름이었죠 15:32 <jrandom> Pseudonym: 성능(cpu/메모리, 우리의 반신뢰 요구사항으로 인한 더 나은 스케줄링), 유지보수성, 더 효과적인 블랙리스트 등록 15:32 <+Complication> 한 번 튄(spike) 것뿐이었고 다시는 반복되지 않았어요 15:32 <+legion> 네, 이전 버전들 중에는 그런 스파이크가 있었습니다 15:32 <jrandom> Complication: 이번 마지막 리비전에서 >2000 tunnel 스파이크를 겪었어요 15:33 <jrandom> 하지만 바라건대 0.6.1.7이 그 문제를 해결해 줄 거예요 15:33 <+legion> 음, 그건 tcp를 빼야 할 좋은 이유들이네요 :) 15:33 <jrandom> 하지만 다시 말하지만, tunnel 참여 스파이크는 대부분이 실제로 사용되지 않기 때문에 괜찮아요 15:34 <@cervantes> Pseudonym: 네트워크에서 tcp를 아직 쓰는 router는 한두 개뿐인 것 같아요 15:34 <jrandom> 이번 리비전에서도 tcp를 빼는 게 좋을 수도 있어요. 다른 큰 변경이 없으니까요. 그래야 영향이 어떤지 더 분명히 볼 수 있거든요 15:34 <jrandom> (필요하면 다시 켤 수도 있고요) 15:35 <Pseudonym> 두 개의 router만 그걸 쓰고 있다면, 어느 쪽이든 큰 영향은 없을 것 같네요 15:35 <Pseudonym> (네트워크에 router가 두 개 줄어드는 것만 빼면) 15:35 <@cervantes> 불만 고객 2명 15:35 <jrandom> 글쎄요, 그 전송이 이상한 상황에서 나타나는 경우가 있어서, 그게 비활성화하고 싶은 이유 중 하나예요 :) 15:35 <+Complication> 그들이 너무 개인적으로 받아들이지 않으면 좋겠네요 15:36 <+Complication> 특정 ISP들이 UDP를 필터링하는 건 정말 못됐죠. 15:36 <+Complication> 못됐을 뿐만 아니라 완전히 말이 안 되고요. 15:36 <jrandom> (예: router가 맛이 갔을 때, 사람들이 자신의 SSU transport를 실패로 표시하면 tcp transport로 되 fallback 되거든요) 15:36 * Pseudonym 은 자신의 ISP를 사랑한다. 제한이 전혀 없다 15:37 <+Complication> 그럼 TCP 없이, UDP가 혼자서 어떻게 처리하는지 보게 되겠네요? 15:37 <+Complication> "보조바퀴 없이" :P 15:37 <+legion> 흠 그러면 tcp 없이 그런 나쁜 필터링은 어떻게 우회하죠? 15:38 <jrandom> 바로 그거예요, Complication :) 15:38 <jrandom> legion: 우회하지 않아요 15:38 <jrandom> (restricted routes(제한된 경로)) 15:38 <+Complication> 음, 파일 공유 프로그램 말고도, DNS 패킷보다 큰 UDP 패킷을 쓰는 유용한 앱들이 여럿 있지 않나요? 15:39 <+legion> :( 별로 좋은 소리는 아니네요 15:39 <+Complication> I2P가 사용하는 최소 패킷 크기와 비슷한 크기인가요? 15:39 <jrandom> 음, legion, 문제 아니에요 15:39 <jrandom> Complication: 스트리밍 프로토콜 15:39 <+Complication> DNS를 망가뜨리지 않고는 UDP를 직접 차단할 수는 없죠. 15:39 <+Complication> 패킷 크기를 제한할 수는 있겠죠. 15:40 <+legion> 알겠어요, 그럴 수도 있겠다는 생각이 들었거든요 15:40 <+Complication> VoIP? 15:40 <jrandom> 그게 광범위하다면 문제겠죠—인터넷 커뮤니티 전반이 udp를 금지한다면요 15:40 <+Complication> 음, VoIP는 큰 패킷을 쓰나요 작은 패킷을 쓰나요? 15:40 <jrandom> 하지만 몇몇 isp만 그렇다면, restricted routes처럼 취급할 수 있어요 15:40 <+Complication> 아니면 더... 비디오 스트리밍을 말한 건가요? 15:40 <+legion> 둘 다 섞어 쓸 것 같네요 15:41 <jrandom> 둘 다예요, Complication, RTSP는 UDP 위에서 돌고, real은 내가 기억하기로(RTSP iirc) RTSP 위에서 돌아요 15:41 <+Complication> s/p/s 15:42 <+legion> 그럼 다음 안건으로? 15:42 <+Complication> cat /etc/services | grep -c udp 15:42 <+Complication> 227 15:43 <jrandom> 0.6.1.7에서 tcp를 뺄지는 아직 확실치 않지만, 아마 그렇게 할 겁니다. 15:43 <jrandom> 좋아요, 1)에 더 할 말 있는 분? 없으면 2) Syndie로 넘어가죠 15:43 <+Complication> 즉, UDP를 쓰는 앱이 최소 227개는 있다는 뜻이죠(몇 개는 구식이거나 LAN 앱일 수도). 15:44 <jrandom> 에이, 여긴 인터넷입니다. 필요한 건 프록시된 HTTP 접근뿐이에요 15:44 <jrandom> 메일(그리고 Syndie)에 있는 것 말고는 2)에 덧붙일 게 많지 않아요 15:44 <+legion> 납득했어요, 네 그럼 빼죠. :) 15:44 <jrandom> syndie 관련해서 얘기하고 싶은 것 있나요? 15:45 <+legion> 2)에 대해서도 할 말은 없습니다. 15:45 * Complication "how Syndie works"를 읽는 중 15:46 <+Complication> 작은 UI 효과 하나가 계속 저를 놀라게 하네요. :D 15:46 <+Complication> 메시지 스레드를 펼치면, 활성 메시지가 목록의 맨 위가 되는 쪽으로 이동하는 게 늘 의외예요. :P 15:47 <+Complication> 하지만 아마 무시하셔도 될 거예요. 제가 깐깐하고 습관의 동물이라서요. :P 15:47 <@cervantes> 스레딩 모델은 지금 길게 논의 중이에요 15:47 <@cervantes> ;-) 15:47 <+Complication> 곧 익숙해질 거예요. :) 15:48 <+Complication> cervantes: Syndie에서요? 그 스레드를 찾아봐야겠네요. :) 15:48 <@cervantes> 저도 그건 마음에 안 들어요 — 하지만 바뀔 수도 있죠 15:48 <jrandom> 맞아요, 좀 괴상하긴 하죠 15:48 <+legion> 네 15:48 <@cervantes> "subject: syndie threading" 15:49 <+Complication> 게다가, 펼친 메시지가 맨 아래라면, 어쨌든 움직여야 *would* 하겠죠. 15:49 <+Complication> 안 그러면 거기 박혀버릴 테니까요. 15:50 <jrandom> 음, 아래쪽 내비는 한 번에 10개의 메시지가 아니라 10개의 *threads*를 보여줘요. 그래서 맨 아래 스레드를 펼칠 수도 있겠죠 15:50 * cervantes 는 현재 몇 가지 다른 스레딩 UI 스타일 구현을 테스트 중 15:51 <jrandom> 끝내주네 15:51 <jrandom> 네, 이상적으로는 css에서 그것들을 바꿔 끼울 수 있으면 좋고, 안 되면 서버 측에서라도요 15:52 <@cervantes> 정확히는 "threading navigation styles" 15:53 <@cervantes> 흠 내 테스트는 기본적으로 순수 html 중첩 비순서 목록을 씁니다 15:53 <@cervantes> 필요한 만큼 css와 javascript를 겹쳐서 입힐 수 있어요 15:53 <jrandom> 언제쯤 시안을 볼 수 있을지 대략 일정이 있나요? 15:53 <@cervantes> (다만 이건 개념 증명일 뿐, 실제 ui 구현은 아닙니다) 15:54 <@cervantes> 저는 I2P 회의 중에 코딩을 대부분 하죠 ;-) 15:54 <jrandom> ㅎㅎ 15:54 <@cervantes> 아마 오늘 저녁에 첫 시안이 준비될 거예요 15:54 * jrandom 이 매일 회의를 잡는다 15:54 <jrandom> 끝내주네 15:54 <@cervantes> 으악 :) 15:55 <jrandom> 좋아요, 2) syndie에 대해 더 있으신가요? 15:55 <jrandom> 없으면 3) I2P Rufus 0.0.4로 넘어가죠 15:56 <jrandom> 메일에 있는 것 말고는 덧붙일 게 별로 없어요 — Rawn/defnax, 계신가요? 15:56 <+legion> 그럼 0.0.4는 얼마나 좋은가요? 문제가 남아 있다면 뭐가 있죠? 15:57 * jrandom 은 전혀 모른다 15:58 <+legion> 사용자 중 누가 답해 줄 수도 있겠네요. 좋아 보이고 안정적인가요? 15:58 <jrandom> 알겠어요, 지금은 Rawn과 defnax가 자리에 없는 것 같네요. I2P Rufus에 대한 질문/의견/우려가 있으면 포럼에 들러서 올려 주세요 15:58 <+legion> 젠장, 그럼 우리가 해야겠네요. 15:59 <+legion> 4)로 계속? 15:59 <jrandom> 그래, 그런 것 같네. 좋아, 4) ??? 15:59 <+Complication> 안타깝게도 I2P Rufus는 아직 안 써봤어요. 16:00 <jrandom> 다른 더 얘기하고 싶은 것 있나요? 16:00 <jrandom> (시간 좀 끌어서 cervantes가 일을 더 하게 해봅시다!) 16:00 <+legion> 네, 앞으로 어떤 흥미로운 것들이 나올 예정이죠? 16:00 <+bar> "restricted routes"에 대해 더 읽을 수 있는 곳이 있을까요? 16:00 <+bar> (이미 *찾아봤어요*) 16:01 <+legion> i2phex 얘기도 해볼까요? 16:01 <jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD 16:01 * cervantes 는 마우스를 닫기 버튼 위에 올린다 16:01 <jrandom> 어, #future.restricted 16:02 <jrandom> 거기에 how_* 페이지들과 todo도요 16:02 <jrandom> (웹에 있어요) 16:02 <+Complication> 헷, I2P가 빌드를 하나 건너뛴 것 같네요 :D 16:02 <+Complication> :D 16:02 <+bar> 고마워요 16:02 <+Complication> - public final static long BUILD = 1; 16:02 <+Complication> + public final static long BUILD = 3; 16:03 <jrandom> legion: netDb 작업 좀 하고, 성능 수정, restricted routes, 스트리밍 개선, eepproxy 개선, tunnel 개선 등등. 할 게 많지만 아직 준비된 건 없어요 16:03 <+legion> 어, 이상하네 16:03 <jrandom> i2phex 관련해서 꺼낼 것 있나요, legion? 16:03 <jrandom> Complication: 네, 의도한 겁니다. BUILD = 2로 올리는 걸 까먹었어요 16:03 <+Complication> (크게 중요하진 않지만, 이런 드문 경우를 전에 본 적이 있나 궁금해서요 :) 16:04 <+legion> 좋군요, 멋지네요, 감사합니다! 16:04 <jrandom> 아, 그러고 보니... 누가 우리 웹페이지 재단장을 추진해 보면 좋겠네요 16:05 * jrandom 은 생각하긴 싫지만, 언젠가는 해야 한다 16:05 <+legion> 네, 있어요 16:05 <+legion> 지금 시점에서 i2phex를 최신 phex cvs 코드로 업데이트할 가치가 있을까요? 16:06 <+Complication> 잘 모르겠어요, 최근에 Redzara 소식을 못 들었어요 16:06 <jrandom> 제 마지막 기억으론, redzara는 gregorz의 phex 업데이트를 기다리고 있었어요 16:06 <jrandom> (그래야 꽤 깔끔한 업데이트/확장이 가능하니까요) 16:08 <+legion> 음, 그렇다면 왜 i2phex가 필요한 거죠? 16:08 <+Complication> 만약을 위해서? 16:08 <jrandom> 흠? 16:08 <jrandom> i2phex는 phex의 확장이에요 16:08 <+legion> phex에 i2p 확장만 있는 형태로 두길 원한 것 같았거든요 16:09 <jrandom> 확장이라 함은, 아주 소수의 구성요소만 수정한다는 뜻이죠 16:09 <jrandom> 어, s/bits/components/. 그래서 phex 개발자들이 무언가를 고칠 때마다 코드를 쉽게 업데이트할 수 있도록요 16:10 <+legion> 그렇다면 최신 cvs 코드로 제가 업데이트하는 데 큰 일은 아닐 텐데요, 뭐 일이 많아질 거란 건 알지만요. 16:10 <jrandom> 포럼에서 마지막으로 들은 바로는, I2Phex와 Phex를 별개의 애플리케이션으로 두되, 코드 대부분을 공유하는 계획이었어요 16:10 <jrandom> 네, legion, 그거야 좋죠. 다만 제가 마지막으로 들었을 땐 Gregor가 아직 Phex 수정 작업을 끝내지 못했어요 16:11 <jrandom> (그걸 redzara가 기다리는 중이었죠) 16:11 <+legion> 아, 알겠어요 16:11 <jrandom> 그러니, 대안은 Gregor를 돕거나 기존 I2Phex 코드베이스를 계속 수정하는 겁니다 16:12 <+legion> 그럼 제가 기다리지 않고 새 코드로 i2phex를 업데이트해버리면, redzara가 계속할 필요가 없겠네요 16:12 <jrandom> 음, 꼭 그런 건 아니에요. 16:12 <jrandom> I2Phex를 현재 Phex 코드로 업데이트하는 건 좋죠, 맞아요 16:13 <jrandom> 하지만 Phex 개발자들이 Phex 코드를 업데이트하는 순간, 우리는 또 불일치가 생겨요 16:13 <+legion> 좋아요, 오늘 밤이나 며칠 안에 해볼게요. 16:13 <jrandom> 끝내주네 16:13 <+legion> 괜찮습니다. 16:14 <+legion> 사실 i2phex를 phex 코드와 계속 동기화하려는 건 아니고, cvs에 i2phex에 확실히 도움이 될 수정이 들어 있는 것 같아서요. 16:15 <+legion> 그리고 i2phex에 필요 없는 phex 코드와 기능은 빼고 싶기도 하고요. 16:15 <jrandom> 좋아요 16:16 <+legion> 아직 작동하지 않는 업로드 큐 같은 것들을 고치고 새 기능을 넣는 문제에 대해서는... 글쎄요, 웹캐시를 동작시키는 건 이미 살펴봤지만 아직 할 일이 많습니다. 16:17 <jrandom> 맞아요. 예전엔 phex에 gwebcache 지원이 있었는데, sirup이 처음엔 필요 없어서 비활성화했죠 16:17 <+legion> 언젠가 jeti를 i2phex에 추가할 계획입니다. 16:17 <jrandom> 좋네 16:18 * jrandom 은 jeti를 써본 적이 없고, 선택 구성요소로 남았으면 하지만, 더 많은 걸 지원하는 건 멋져요 16:18 <+legion> 네 선택적으로요, 사용자는 jeti2phex를 다운로드할 수 있게 될 겁니다 ;) 16:19 <jrandom> 맞아 16:19 <+legion> i2phex로 할 수 있는 게 아직 많아요, 지금도 잘 돌아가긴 하지만요. 16:20 <+legion> 지금까지는 클라이언트를 24/7로 연결 유지하고 계속 돌리는 게 가능하고 쉽습니다. 16:21 <jrandom> 네, 저도 꽤 잘 썼어요... "내가 라이선스 받은 녹음을 백업하는 데" 16:21 <+legion> ㅎㅎ :) 16:22 <jrandom> 좋아요, 회의에 더 이야기할 분 있나요? 16:23 * cervantes 가 중국식 공을 굴려 들여온다 16:23 <+legion> 뭔가 잊은 것 같은데... 흠 16:24 <+legion> 아 맞다, i2p와 i2phex가 소비하는 메모리 양을 줄일 방법에 대한 아이디어가 있나요? 16:25 <+Complication> 음, TCP transport가 좀 차지하죠 16:25 <jrandom> 둘 다 같은 jvm에서 돌릴 수도 있어요 16:25 <+Complication> 그게 빠지면 조금은 줄어들 거예요 16:26 <@cervantes> 기계에서 램 모듈 몇 개 빼세요 16:26 <cat-a-puss> javolution 써본 경험 있는 분, 도움이 될지 아시나요? http://javolution.org/ 16:26 <jrandom> (i2p 설치 디렉터리의 clients.config가 클라이언트 실행을 위한 메인 클래스와 인자를 정의합니다) 16:26 <+legion> 그럼 둘 다 같은 jvm에서 돌리고 tcp도 빠지면, 50mb 이하로 내릴 수 있을까요? 16:27 <jrandom> 모르겠네요, legion. 50MB가 정확히 뭘 뜻하는지도 달렸고요. RSS/VSS/etc 16:27 <jrandom> 다만 둘을 한 JVM에서 돌리는 건 권하진 않아요. 둘 다 항상 실행할 게 아니라면요. 하나를 종료하면 다른 하나도 죽을 테니까요 16:27 <@cervantes> legion: 대역폭을 제한하고 참가자 상한을 두는 것도 도움이 될 거예요 16:27 <jrandom> 네, cervantes 말대로요 16:28 <cat-a-puss> 결국 어떤 종류의 객체를 얼마나 쓸지 정확히 안다면, 지나치게 열성적인 jvm 할당을 막는 데 도움이 될 것 같아요 16:28 <+Complication> 맞아요, 서로 다른 할당들이 있는데, 저는 그걸 제대로 이해해 본 적이 없네요 16:28 <jrandom> 네, 그런 것도 좀 해요, cat-a-puss (net.i2p.util.ByteCache 참고) 16:29 <+Complication> (하지만 말했듯, 저는 Java가 아주 생소해요) 16:29 <jrandom> 예전에 javolution을 훑어봤는데, 많이 발전한 것 같네요. 다시 한 번 살펴볼게요 16:30 <cat-a-puss> jrandom: 제 회사에서도 쓰는 사람들이 있는데 만족해요, 다만 메모리 할당은 신경 안 써요 16:31 <jrandom> 글쎄요, 메모리를 실제로 절약하진 못하겠지만, GC 동작을 줄이는 데는 도움이 되겠죠 16:31 <+legion> 전 개인적으로 메모리 할당엔 큰 관심이 없지만, 많은 사람들이 신경 쓰죠. 16:31 <jrandom> 오, 그리고 BSD 라이선스네요 16:31 <cat-a-puss> 맞아요 16:31 <jrandom> legion: 메모리 할당은 곧 성능이에요 16:32 <+legion> 아, 그러니까 메모리 소비 말이죠 16:33 <+legion> 많은 사람들이 utorrent가 메모리 점유가 아주 작아서 아주 만족하죠. 16:33 <jrandom> 아, 그렇군요. 나중에 조정할 수는 있어요. i2p가 기본 jvm 크기 내에서 돌아가니까, 전 큰 걱정은 안 해요(조정할 여지가 많으니까요) 16:34 <jrandom> 좋아요, 회의에 더 이야기할 분 있나요? 16:35 <+legion> 아니요, 저는 됐어요... 16:37 * jrandom 준비한다 16:37 * jrandom 이 회의를 *baf*하며 종료한다