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

16:09 <jrandom> 0) 안녕하세요 16:09 <jrandom> 1) 네트워크 상태와 0.6.1.16 16:09 <jrandom> 2) tunnel 생성과 혼잡 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) 안녕하세요 16:10 * jrandom 손을 흔든다 16:10 <jrandom> 주간 상태 노트를 http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 에 올렸습니다 16:10 * frosk도 16:10 <jrandom> (회의 *전에* 거의 두 시간이나 올렸어요 :) 16:11 <jrandom> 자, 여러분이 이미 노트를 샅샅이 읽어보셨을 테니, 1) 네트워크 상태로 들어가죠 16:12 <+Complication> 안녕하세요 :) 16:12 * Complication 재빨리 노트를 집어든다 16:12 <jrandom> 0.6.1.16 릴리스에서 우리의 PRNG(의사 난수 생성기)에 매우 오래된 버그 하나를 수정했습니다. 그 버그 때문에 임의적인 tunnel 거부가 상당히 많이 발생했었습니다 16:13 <jrandom> (근본 원인은 지난 10월에 들어갔지만, 지금은 수정되었습니다) 16:13 <+Complication> 여기 상태: 1 + 0..1 홉 tunnel에서는 그럭저럭 동작하지만, 2 + 0..1 또는 2 +/- 0..1에서는 잘 동작하지 않습니다 16:14 <jrandom> 맞아요, 특히 느린 링크에서는 그럴 수 있죠 16:14 <jrandom> (불행히도 여기서 말하는 "느린" 게 그다지 느린 것도 아닙니다) 16:15 <jrandom> 아직 할 일이 많고, 0.6.1.16이 우리가 원하는 수준은 아니지만, 진전은 있습니다 16:17 <+Complication> 당신이 "혼잡 붕괴"라고 부른 것과 관련해 제가 생각해본 것이 있습니다 16:18 <+Complication> 영향을 줄이는 한 방법은 router가 참여 요청을 일정 할당량만큼은 반드시 수락하도록 요구하는 것일 수 있습니다 16:19 <+Complication> (사용자가 직접 또는 간접적으로 지정하는 방식?) 16:19 <jrandom> 어떤 사용자가 지정하나요? 16:19 <+Complication> (예: 공유 비율의 일부로 하거나 추가 매개변수로) 16:19 <jrandom> 로컬 사용자인가요, 아니면 우리처럼 원격 사용자인가요? 16:19 <+Complication> 각자가 자기 router에 대해 지정하는 겁니다 16:19 <@frosk> 그럼 2)로 넘어갈까요? :) 16:20 <jrandom> 좋아요, 2)로 간주합시다 :) 16:20 <+Complication> 예를 들어 제 router에 "혼잡해도 최소 4 KB/s는 라우팅을 유지해"라고 지시할 수 있게요 16:21 <jrandom> Complication: 그건 사실 어렵습니다 — router가 너무 혼잡하면 다른 사람들이 (부디 ;) 그들에게 tunnel 참여를 요청하지 않게 되니까요. 16:21 <+Complication> (물론 이건 어떤 로컬 destination이 더 오래 오프라인일 수 있다는 뜻이겠죠) 16:21 <jrandom> 그리고 요청받지 않으면, 다른 사람의 데이터를 /못합니다/ 16:22 <+Complication> 아, 아마 더 명확히 표현했어야 했겠네요 16:24 <+Complication> 저는 참여 트래픽이 일정 할당량에 이를 때, 참여하는 tunnel을 제한하는 대신 자신의 tunnel 생성 메시지를 제한하도록 할 수 있다고 상상했습니다 16:24 <+Complication> 예: "참여하는 tunnel의 속도를 4 KB/s 아래로는 절대 제한하지 않는다. 그게 필요하다면 대신 내 로컬 트래픽을 제한하겠다." 16:26 <jrandom> 흠, 그런 방식에는 익명성 위험이 있습니다(어차피 우리가 방어하지 않는 선택적 DoS와 같은 부류이긴 하지만) 16:27 <jrandom> 하지만 혼잡 시에 로컬 tunnel 빌드를 스스로 제한하는 것은 지금 테스트 중입니다 — 4 KB/s 하한을 선택적으로 무시하는 옵션을 추가하는 건 비교적 간단할 겁니다 16:28 <spinky> 현재는 많은 데이터를 전송할 때 위장 트래픽(cover traffic)이 전혀 나오지 않습니다. 16:29 <spinky> 참여 대역폭에 하한을 두는 건 좋아 보이네요. 16:30 <jrandom> 음, 하한은 있습니다(공유 비율에도 있고, 모든 대역폭을 할당한 뒤 내부적으로 4 KB/s를 예약하기도 합니다) 16:30 <+Complication> 쳇, 끊겼네요... 제가 한 말이 많이 날아가지 않았길. 답변은 로그에서 읽어야겠어요 :) 16:32 <@frosk> 4 KB/s에 특별한 이유가 있나요? 16:33 <jrandom> 몇 가지가 있어요 — 4KB ~= sizeof(tunnel create message), 그리고 경험상 그보다 낮은 값에서 성공적으로 돌아가는 router는 들어본 적이 없습니다 16:33 <spinky> 그렇다면 공유 비율이 제대로 작동하지 않게 만드는 버그들 때문일까요? 16:34 <jrandom> 공유 비율이 작동하지 않는다고 말하는 근거가 뭔가요? 16:34 <@frosk> 알겠어요 16:34 <+Complication> frosk: 아니요, 그냥 현재 코드에 있는 숫자일 뿐이고, 제가 상상했던 걸 설명하려고 그 숫자를 예로 든 거예요 16:35 <+Complication> (특별한 의미가 있어서가 아니라, 제가 상상한 게 어떤 면에서 그 수치의 상반 개념이었기 때문이죠) 16:35 <spinky> 그게 80%로 설정돼 있는데, 로컬에서 데이터를 생성하면 참여가 0이 돼요. 제가 뭔가 오해한 걸까요? 16:36 <jrandom> 아, 네, 그게 공유 비율의 의미는 아닙니다 16:36 <+Complication> spinky: 그건 공유할 수 있는 양의 상한일 뿐이고, 실제로 공유에 사용할 수 있는 대역폭에 의해 제한됩니다 16:37 <+Complication> 로컬 트래픽이 70%를 차지하면, 공유에는 10%만 남습니다 16:37 <+Complication> 로컬 트래픽이 무거우면 0%만 남게 되고, 80% 상한에는 결코 도달하지 않죠 16:37 <spinky> 알겠어요. '최대'라고 적혀 있네요... 16:38 <+Complication> 그리고 4 KB/s 예약분도 있습니다 16:38 <jrandom> 아, 그건 사용 가능한 것의 공유 비율이라는 뜻이에요 16:38 <spinky> 참여 대역폭(bw)의 하한에 대한 별도 설정을 두고, 그 이하로 떨어지면 router가 더 많은 tunnel을 수락하도록 하는 건 어떤가요? 16:38 <jrandom> 대역폭(bw)의 95%를 쓰고 있으면, 남은 5%의 최대 80%까지만 공유합니다 16:39 <+Complication> 아, 그렇다면 저도 일부 오해했네요 16:40 <fox> <zorglu1> i2p가 다른 로컬 애플리케이션이 사용하는 대역폭(bw) 양은 어떻게 측정하나요 ? 16:40 <spinky> (그냥 의견인데, cover traffic이 좋다고 본다면 로컬 bw 사용이 무거울 때도 그것을 구성 가능하게 하는 게 좋지 않을까요) 16:40 <+Complication> 저는 그게 지속 제한에 대해 적용되는 줄 알았습니다 16:40 <jrandom> zorglu1: i2p 자체의 bw 사용량을 측정하고, i2p의 bw 한도를 알고 있습니다 16:41 <jrandom> 아, 흠, 코드를 다시 보니, int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> 그러니 Complication 말이 맞네요 16:42 <jrandom> spinky: cover traffic은 저지연 mixnet에서만 그나마 유용합니다 16:42 <jrandom> 더 높은 대역폭의 router에게는 어느 정도 동기를 부여하지만, 여유 대역폭이 없는 쪽은 별 뾰족한 수가 없습니다 16:49 <jrandom> 아무튼, tunnel 혼잡 문제는 한동안 있었고, 최근 들어 터무니없는 tunnel 거부율 때문에 더 악화됐습니다 16:49 <jrandom> 다음 릴리스에서는 해결되길 바랍니다 16:49 <jrandom> 좋아요, 2) tunnel 생성과 혼잡에 대해 더 있을까요? 16:50 <@frosk> tunnel 빌드 방식에 약간의 변경이 필요해 보이는군요 16:50 <+Complication> 그게 상황 개선에 도움이 되길 바랍니다 :) 16:51 <+Complication> 아, 그런데요... 16:52 <jrandom> 음, 값싼 해결책들이 몇 가지 있습니다. 예를 들어 최대 동시성 감소, 혼잡 시 빌드 시도 속도 제한, 드롭 빈도 감소(명시적 거부와 대비), 그리고 프로파일링을 조정해 드롭보다는 명시적 거부를 장려하도록 하는 것 등이죠 16:52 <+Complication> ...원시 대역폭 지표와 tunnel 페이로드 지표 사이의 큰 차이를 설명할 만한 걸 혹시 찾으셨나요? 16:52 <+Complication> (예: 총 대역폭 1 GB, 합산된 tunnel 페이로드 300 MB) 16:52 <jrandom> 하지만 사실 그런 것들은 규모에만 영향을 줄 뿐입니다 16:52 <+Complication> (요즘 IRC에 못 와서, 그걸 최근에 살펴보셨는지 잘 모르겠네요) 16:54 <jrandom> 그건 깊이 파보진 않았습니다만, 기억하세요. 아웃바운드 tunnel에 대한 tunnel 빌드 요청은 tunnel 메시지가 아닙니다(성공률이 0.1%에 불과하면 그런 요청이 아주 많아집니다. 게다가 각각 4 KB씩...) 16:54 * Complication 은 그게 지표 문제인지 실제 효과인지 확신이 서지 않음 16:55 <+Complication> 아... 아웃바운드 빌드 요청... 그렇군요 16:55 <jrandom> 다가올 -1 빌드에는 메시지 유형별 패킷을 모니터링하기 위한 통계가 다수 추가됩니다 16:55 <+Complication> 그게 정확히 원인일 수 있겠네요 16:55 <jrandom> (그 아웃바운드 빌드 요청에는 참여 빌드 요청도 포함됩니다 — 응답을 전달하는 것이죠) 16:56 <jrandom> ((그래서 단지 로컬 것만의 문제가 아닙니다)) 17:00 <+Complication>> 감사합니다, 큰 도움이 됐어요 :) 17:00 <+Complication>> 그럼 요술이 아니라 진짜 트래픽이었네요. 제가 확인한 지표에는 따로 집계되지 않아서 그냥 잊고 있었던 거죠 17:00 <+Complication> 실제로 발생할 수밖에 없고, 바이트를 꽤 많이 먹겠군요 17:00 <+Complication> 특히 성공률이 낮으면요 17:01 <jrandom> 맞습니다. 다만 지금보다는 성공률이 높아야 하니, 현재만큼 비용이 크진 않아야겠지요 :) 17:01 <jrandom> 좋아요, 2)에 대해 더 있을까요? 17:02 <jrandom> 없으면 3) Feedspace로 넘어가죠 17:02 <jrandom> frosk: 업데이트 좀 해주시겠어요? 17:03 <jrandom> (아니면 fsck off 하고 eepsite 읽으라고 하셔도 됩니다? ;) 17:04 <@frosk> 음, frosk.i2p나 feedspace.i2p를 아직 안 보신 분들을 위해 말씀드리면, feedspace는 이제 기본적으로 동작합니다(제가 생각하는 "기본적으로"의 정의 기준에서요) 17:04 <jrandom> (w00t) 17:05 <@frosk> 최근에는 i2p 이외의 전송(transport)을 위한 인프라 지원 같은 멋진 추가도 있었습니다(예: Tor와 비익명 TCP/IP) 17:06 <@frosk> 그래서 시간이 지나면, syndie(조만간 아주 멋질 것으로 보이는 리라이트에서)가 feedspace를 배포(syndication) 방법 중 하나로 사용할 수 있게 할 계획입니다 17:06 <@frosk> 현재로서는 feedspace를 실제로 *사용*하는 클라이언트 앱이 없습니다 :) 저는 극히 조악한 서블릿 앱으로 테스트해 왔어요 17:07 <jrandom> (투박함 + 작동함)++ 17:07 <@frosk> 그래서 당연히 클라이언트 해커 모집 중입니다 ;) 17:08 <@frosk> 공개 테스트 전에 feedspace에 아직 필요한 것들이 조금 남아 있지만, 이제 오래 걸리진 않을 거예요 :) 17:08 <jrandom> 좋네요 17:08 <jrandom> 우리가 도울 일 있을까요? 17:08 <@frosk> 또 부족했던 문서 작업도 조금 하고 있어요 17:09 <spinky> 큰 파일에도 feedspace를 사용할 수 있을 거라고 보시나요? 17:10 <@frosk> 1) (아직 문서화되지 않은) XML-RPC API를 사용하는 클라이언트 앱, 2) http://feedspace.i2p/wiki/Tasks, 3) 때가 되면 테스트 참여 17:10 <@frosk> 대용량 파일 지원은 지금은 우선순위가 아니지만, 나중에는 가능할 겁니다 17:10 <@frosk> "1.0"의 초점은 블로그/토론 글이나 각종 이벤트 같은 작은 메시지에 맞춰져 있습니다 17:11 <jrandom> 다만 .torrent 파일을 RSS/feedspace 지원 BT 클라이언트로 넘겨주는 건 문제없겠죠 17:11 <@frosk> 대용량 파일은 될 수도 있고, 안 될 수도 있어요 :) 17:11 <@frosk> 그건 정말 멋질 것 같네요 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> 그런 "어댑터" 앱이 다양하게 나오길 바랍니다 :) 17:12 <+Complication> 글쎄요, 다들 대용량 파일을 옮길 방법을 찾겠죠. 비트... 음, 사이드 채널로요 :) 17:15 <@frosk> feedspace 코드가 온갖 Java 1.5 기능을 사용하는 게 조금 미안하네요. 지금은 자유 Java에서 컴파일/사용하기가 아마 어려울 텐데, 곧 따라잡을 거라고 믿어요 :) 17:15 <jrandom> 이런 17:16 <jrandom> 글쎄요, gcj가 1.5-ism 지원을 위해 ecj를 채택한다는 소문이 있긴 합니다 17:16 <spinky> Complication: 안장가방에 HDD를 가득 싣은 조랑말 같은 거요? 17:16 <@frosk> 네 17:17 <+Complication> spinky: 제 취향이라면 드론이죠 :P 17:17 * jrandom 은 아직 1.4-ism으로 간신히 옮겨가는 중 17:17 <+Complication> 하지만 조랑말도 되겠죠 :P 17:17 <jrandom> 그래도 1.6은 정말 좋죠 ;) 17:17 <@frosk> gcj와의 호환성을 유지하려고요? 17:18 <@frosk> 음, 1.6은 어차피 대부분에서 "ism"이 많지 않다고 생각해요 :) 17:18 <+Complication> (아니면 메모리 카드를 공중투하하는 날아다니는 고슴도치) 17:18 <jrandom> gcj/classpath/기타 때문이기도 하고, 성능 때문이기도 합니다(1.5가 1.4보다 약간 무겁더군요) 17:19 <jrandom> 맞아요, 1.6의 개선점은 주로 VM/바이트코드 쪽이죠 17:19 <@frosk> 흠, 알겠어요 17:20 * jrandom 은 1.5-ism을 쓰지 말라고 설득하려는 건 아님. 분명 이유가 있겠죠. 예컨대 Azureus도 이미 1.5가 필요하니까요 17:21 <@frosk> 뭐, 이제 되돌릴 수는 없죠 :) 너무 험난하진 않길 바랍니다 17:24 <jrandom> 맞아요, 잘 될 거예요 :) 17:25 <jrandom> 좋아요, 그럼 3) feedspace에 대해 더 있을까요? 17:25 * frosk 는 자신의 제네릭과 java.util.concurrent를 꼭 껴안음 ;) 17:25 <jrandom> 헤헤 17:27 <jrandom> 좋아요, 3에 더 없으면 4) ???로 넘어가죠 17:27 <jrandom> 회의에서 더 하실 말씀 있나요? 17:27 <+Complication> 2)에서 물어봤어야 했던 작은 질문이 있어요 17:28 <+Complication> 참여 중인 tunnel이 유휴 상태(idle)가 되는 경우는 보통 어떻게 생기나요? 17:28 <+Complication> 대부분은 tunnel 빌드가 실패했지만, 생성자만 그 실패를 아는 상황의 신호인가요? 17:28 <+Complication> 아니면 다른 이유도 있나요? 17:28 <+Complication> (물론 명백한 이유, 즉 앱이 놀고 있는 경우 말고요) 17:29 <jrandom> 앱이 놀고 있어도 idle tunnel이 있진 않습니다(테스트가 이뤄지니까요) 17:29 <jrandom> idle tunnel은 무슨 이유에서건 실패한 것입니다 17:29 <jrandom> (완전히 생성되지 못했거나, 동작 중에 실패했거나) 17:30 <+Complication> 그렇군요. 어차피 모든 tunnel은 테스트되고, tunnel 테스트는 트래픽을 유발하니까요... 맞네요 17:30 <+Complication> 그럼 질문의 두 번째 부분인데요: tunnel이 idle임을 감지하면, 이를 일찍 폐기하는 게 이점이 있을까요? 17:31 <+Complication> 그렇게 해서 아낄 수 있는 귀중한 자원이 있나요? 17:32 <jrandom> 없습니다 — 데이터를 밀어주지 않는 tunnel은 자원을 소모하지 않아요 17:32 <jrandom> (음, RAM은 조금 씁니다, 어쩌면 32바이트 정도) 17:32 <+Complication> 아니면 router가 자신의 부하나 유사한 파라미터를 더 잘 파악하는 데 도움이 될까요... 17:33 <jrandom> tunnel 이력에 기반한 대역폭 사용량 예측은 확실히 열린 질문입니다 17:33 <+Complication> 아니면 그냥 무의미한 작업이라 자연스럽게 만료될 때까지 기다리는 게 최선일까요? 17:33 <+Complication> (현재처럼요) 17:34 <jrandom> 예전에 예측을 조금 했었지만 뚜렷한 이점이 없어서, 지금은 더 단순한 알고리즘을 씁니다 17:34 <+Complication> 아하, 그러면 이득이 없군요... 17:34 <+Complication> 감사합니다, 그게 제가 묻고 싶었던 전부였어요 :) 17:34 <jrandom> 천만에요, 이해되는 걱정입니다 17:34 <jrandom> 좋아요, 회의에서 더 하실 말씀 있나요? 17:35 <+Complication> 맞아요, 예측을 한다면 idle tunnel의 비율이 추정치를 왜곡할 수도 있겠네요 17:35 <+Complication> (그 비율이 많이 변한다면) 17:36 <jrandom> 맞습니다, 추정치의 일부로 idle 비율을 포함하고 싶겠죠 17:36 <jrandom> (예전에 그랬죠 — RouterThrottleImpl.allowTunnel 메서드를 보세요) 17:37 <+Complication> 오, 몰랐네요 :) 17:37 <jrandom> 그리고 새 주석을 보세요: 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication 은 아직 그 파일을 찾아보는 중이지만, 감사합니다 :) 17:39 <jrandom> w3rd 17:40 <jrandom> 좋아요, 회의에 더 말씀이 없으면... 17:40 * jrandom 마무리함 17:41 * jrandom *baf* 하며 회의를 닫습니다