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

16:12 <jrandom> 0) 안녕하세요 16:12 <jrandom> 1) 네트워크 상태와 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) 안녕하세요 16:13 * jrandom 손을 흔든다 16:13 <@cervantes> 안녕 16:13 <jrandom> 주간 상태 노트를 http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 에 올렸습니다 16:14 <jrandom> 그걸 대충 훑는 동안, 1) 네트워크 상태로 넘어가죠 16:14 <jrandom> 보시다시피 새 릴리스를 배포했고, 지금까지는 꽤 긍정적입니다 16:15 <@cervantes> (야호!) 16:15 <jrandom> 아직 필요한 수준까지는 아니지만, 우리가 겪던 주요 이슈들은 거의 정리되었습니다 16:15 <jrandom> 그렇죠, 2개 이상 홉의 tunnel에서도 그럭저럭 괜찮은 tunnel 구축 성공률을 다시 보니 좋네요 :) 16:16 * jrandom 은 다른 router에서 1-hop tunnel로 50%+ 성공률을 기록 중 16:17 <jrandom> 0.6.1.17의 최근 몇 가지 변경은 앞으로도 이런 종류의 혼잡 붕괴를 피하는 데 도움이 될 거라 봅니다 16:17 <jrandom> 다만 사용자 입장에서는 가끔 lease 만료가 보일 수 있지만, 악순환으로 번지기보다는 백오프할 겁니다 16:17 * cervantes azureus를 켠다 16:18 <+Complication> 오늘 아침에 client tunnel(길이 2 ± 1) 성공률이 약 35%로 기록되었습니다 16:18 <+Complication> 지금은 더 낮습니다. 몇 가지 수정을 시도했는데, 마지막 시도가 별로였거든요 :D 16:18 <@cervantes> jrandom: 그 문제를 잘 추적했어요 - 잠깐 freenet처럼 보이기 시작했었거든요 :) 16:19 <jrandom> *콜록* ;) 16:20 <+fox> <inkeystring> jrandom: 백오프 메커니즘을 간단히 설명해줄 수 있나요? 지금 freenet 0.7에 비슷한 걸 작업 중입니다 16:21 <jrandom> inkeystring: 전송 계층이 과부하일 때 특정 피어로의 전송을 줄이는 전송 계층 백오프 메커니즘은 이미 있었지만, 그걸로는 충분하지 않았습니다 16:21 <@cervantes> *콜록* freenet이라고 했나요, tor를 말하려던 거였어요 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: 새 변경은 그걸 더 높은 레벨로 전파해서 통신 계층이 포화일 때 tunnel 구축을 시도하지 않도록 한 것입니다 16:22 <jrandom> (더 많은 tunnel 구축 시도를 보내는 대신) 16:22 <+fox> <inkeystring> 고마워요 - 전송 계층은 패킷이 손실될 때만 백오프하나요, 아니면 수신자가 흐름을 제어할 방법이 있나요? 16:23 * jrandom 은 혼잡 대 라우팅의 영향에 대해 toad와 몇 번 얘기했던 게 기억나네요(irc와 예전 flog에서), 하지만 유의미하게 긍정적인 해법은 기억나지 않아요 :/ 16:23 <jrandom> 수신자는 NACK을 보낼 수 있고, ECN 훅도 있지만, 필요하진 않았습니다 16:23 <+fox> <inkeystring> 네, 그 논쟁이 freenet-dev에서 다시 떠올랐어요 :-) 아직도 만능 해법은 없죠 16:24 <+fox> <inkeystring> 멋져요, 정보 고마워요 16:24 <+Complication> 요즘 그쪽도 UDP를 쓰지 않나요? 16:24 <jrandom> 현재 심하게 혼잡한 피어들은 피어별 스로틀링 문제가 아니라 피어 통신의 폭 때문에 어려움을 겪고 있습니다 16:24 <+Complication> (전송 프로토콜로서) 16:24 <+fox> <inkeystring> 폭 = 피어 수? 16:24 <jrandom> 네 16:25 <jrandom> tunnel 성공률이 올라가면서, tunnel 하나 구축하려고 수백 개 피어와 통신할 필요가 없어졌습니다 16:25 <jrandom> 그래서 20~30개 피어만으로도 충분합니다 16:25 <jrandom> (직접 연결된 피어 기준으로요) 16:26 <+fox> <inkeystring> NAT 홀 펀칭, keepalive 등에는 좋은 소식이겠네요? 16:26 <jrandom> 반면에, 활성 SSU 연결이 2~300개면 6KBps 링크로는 버티기 어렵죠 16:26 <jrandom> 맞아요 16:26 <+fox> <inkeystring> Complication: 네 16:27 <+fox> <inkeystring> (0.7 알파에서) 16:27 <+Complication> 아하, 그럼 비슷한 문제를 겪고 있겠군요 16:27 <+Complication> 누가 기적의 탄환을 찾아주길 바랍니다 :D 16:27 <jrandom> 다만 방식은 다르죠. 전송 계층은 상대적으로 쉬운 이슈입니다 16:27 <+fox> <inkeystring> SSU 코드를 일부 재사용했을지도요... 적어도 그렇게 얘기하긴 했어요 16:27 <jrandom> (즉, 30년 넘게 잘 연구되어 왔죠) 16:28 <jrandom> 하지만 i2p(그리고 freenet)의 로드 밸런싱은 포인트투포인트 링크보다 더 높은 레벨에서 동작하고, 요구 사항도 다릅니다 16:28 <+fox> <inkeystring> 맞아요, 라우팅과의 상호작용이 까다롭죠 16:29 <jrandom> 맞습니다. 그래도 i2p는 좀 쉬운 편이죠(문제의 데이터를 가진 특정 피어를 찾을 필요 없이, 우리 tunnel에 참여할 수 있는 용량이 있는 누구나면 됩니다) 16:30 <+fox> <inkeystring> 그러니 과부하된 피어를 피하더라도 효율 손실이 없겠네요... 16:30 <+fox> <inkeystring> 반면 freenet에선 과부하된 피어를 우회하면 경로 길이가 늘어날 수 있고요 16:30 <+fox> <inkeystring> 어쨌든 주제에서 벗어난 얘기라 미안해요 16:31 <jrandom> 괜찮아요. 0.6.1.17의 변경이 왜 우리의 혼잡 붕괴에 영향을 주는지 설명하는 건 관련된 주제였으니까요 :) 16:31 <jrandom> 좋아요, 1) 네트워크 상태에 대해 더 얘기할 분 있나요? 16:32 <+Complication> 음, 앞서 말했듯이 .17 순정으로 돌리는 동안 대역폭과 활성 피어 수에서 눈에 띄는 주기성이 관찰됐습니다 16:32 <+Complication> 다른 몇몇도 겪는 것 같지만, 얼마나 흔한지는 모르겠습니다 16:33 <+Complication> 주요 원인이 뭔지, 주로 tunnel 스로틀링 관점에서 생각해 봤지만 아직 해법은 없습니다 16:33 <+Complication> 제 그래프를 좀 더 평평하게 만들기는 했지만, 전반적 성능이 떨어지는 대가를 치러야 했습니다 16:33 <+Complication> 다음과 같은 수정을 시도했어요: 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (자기 자신의 tunnel에 대한 구축 시도를 완전히 멈추지 않게 하려는 목적이었습니다) 16:35 <jrandom> 아 그렇죠 16:35 <+Complication> (아, 그리고 당연히 로그 레벨은 테스트를 위해 바꿔서 좀 엉망입니다) 16:35 <jrandom> 주기성을 조금 비틀어 보려는 코드가 있긴 한데, (보시다시피) 그리 잘 작동하진 않습니다 16:36 * perv 방금 시스템을 날려먹음 :( 16:36 <+Complication> 저도 그런 비슷한 걸 시도해봤고, tunnel 개수의 증가 계수를 줄여보기도 했습니다 16:36 <perv> reiser4에 undelete가 있나요? 16:36 <jrandom> 기본적으로, 실제보다 (무작위로) 더 일찍 tunnel이 만료되는 것처럼 동작하게 하면 도움이 될 겁니다 16:36 <+Complication> 지금 TunnelPool.java의 큰 함수인 "countHowManyToBuild"를 읽는 중입니다 :D 16:36 <+Complication> 아직 끝까지 읽지는 못했어요 16:37 <jrandom> (물론 그건 tunnel 구축 빈도를 높이게 되고, 0.6.1.17 이전에는 그게 적절하지 않았겠죠) 16:37 <+Complication> perv: 뭔가 있긴 해요 16:37 <jrandom> 흠, 그 안에 무작위화를 넣는 건 쉽지 않겠어요 Complication, 그 함수를 꽤 자주 호출하거든요 16:38 * perv 복구하고 gentoo로 갈아탈까 고민 중 16:38 <jrandom> 제가 권하고 싶은 건, 구축에 성공한 tunnel의 만료 시간을 무작위화하는 겁니다 16:38 <+Complication> perv: 확실히 ext3보다 reiser가 나을 거예요 16:38 <+Complication> perv: 하지만 제가 정확히 외우고 있진 않아요 16:38 <+Complication> jrandom: 맞아요, 이렇게 하면 가끔 과도하게 구축될 수도 있죠 16:38 <jrandom> (그래서 기존 countHowManyToBuild가 실제보다 먼저 필요하다고 생각하게요) 16:38 <+Complication> (그리고 tunnel이 끊기고 조급해질 때는, 어쩔 수 없이 과도하게 구축되기도 하죠) 16:40 <+Complication> 흠, 생각하지 못했던 가능성이네요... 16:41 <+Complication> 어쨌든 저도 만져보고는 있지만, 아직 유의미한 관찰 결과는 없습니다 16:42 <jrandom> 좋네요, 저도 그 부분을 손본 게 좀 있는데, 다음 빌드에 묶어서 꽤 쓸 만해진 네트에서 어떻게 동작하는지 보죠 ;) 16:43 <spinky> i2p 네트워크가 애플리케이션 데이터에 추가하는 오버헤드 양을 볼 수 있는 통계가 있나요? 16:43 <jrandom> "overhead"는 참 의미가 많은 단어죠... ;) 16:43 <jrandom> 우린 그걸 익명성의 비용이라고 부릅니다 ;) 16:43 <spinky> 헤헤 16:45 <jrandom> (그러니까 실제로는 아니죠. 혼잡 0에 1+1 hops인 완벽한 네트에서 애플리케이션 계층 페이로드는 엔드포인트 기준으로 대략 70~80% 효율을 보입니다) 16:45 <jrandom> ((마지막으로 측정했을 때 기준)) 16:45 <jrandom> 하지만 그건 정말 실험실 조건이죠 16:45 <jrandom> 실제 네트는 훨씬 더 복잡합니다 16:47 <spinky> 맞아요, 저는 tunnel 설정, 키, 패딩 등에 쓰이는 추가 데이터 양만을 말한 거예요 16:47 <spinky> ...전송된 애플리케이션 데이터와 비교해서요 16:47 <jrandom> 메시지 프레이밍, 혼잡, tunnel 구축 성공률 등에 따라 달라요 16:48 <jrandom> 2-hop tunnel 하나를 구축하는 데 네트워크가 20KB 정도를 감당할 수 있습니다 16:48 <+Complication> 가끔 그걸 테스트해 보고 싶었어요. 주로 BitTorrent와 I2Phex 같은 대용량 전송 애플리케이션의 '낭비도'를 추정하려는 목적이었죠 16:48 <+Complication> 하지만 제 두 노드 간에 깔끔한 측정을 해보지는 못했습니다 16:48 <+Complication> 언젠가는 다시 해보려고요 16:49 <jrandom> Complication: 수다스러운 앱으로는 꽤 어렵고, wget을 재는 게 훨씬 간단하죠 :) 16:49 <+Complication> 정말 그렇죠 16:50 <+Complication> 제가 시도해 본 것들에는 정밀함이라고는 찾아보기 어려웠습니다 16:54 <jrandom> 좋아요, 1)에 더 없으면 2) I2Phex로 넘어가죠 16:55 <jrandom> Complication: 요즘 뭐 하고 있어요? :) 16:55 <+Complication> 음, 어제 커밋은 제 허술한 첫 실행 감지기 때문에 일부가 겪었던 특정 문제를 고친 것이었어요 16:56 <+Complication> 첫 실행 감지기는 이제 덜 허술해졌고, bar가 정상적으로 동작하기 시작한 것 같다고 보고했어요 16:56 <+Complication> 하지만 현재 네트워크 상태에서도 I2Phex는 이미 실행 가능한 것 같으니, 16:56 <+Complication> rehash 버그도 찾아보겠습니다. 16:57 <+Complication> 찾을 수만 있다면요 16:57 <jrandom> 좋네요, 그건 몇 달째 당신을 괴롭히고 있는 걸로 알아요 16:57 <+Complication> 흥미로운 건 메인라인 Phex에도 그게 있을지 모른다는 점이고, 그들의 관찰 내용을 찾아 읽어보려 합니다 16:58 <jrandom> 그래도 시작 문제 수정이 들어갔다니 반갑네요 16:58 <jrandom> 아, 좋네요 16:58 <+Complication> =그렇다는 뜻이에요 16:58 <+Complication> 다만 메인라인 Phex에 그게 있는지는 지금 확인할 수 없어요 - 개인적으로 거기서는 본 적이 없습니다 16:59 <jrandom> (간헐적 버그)-- 16:59 <+Complication> 통제된 방식으로 재현하기 어렵고, 그래서 찾기도 어렵습니다 17:00 <+Complication> 제 쪽 소식은 현재로선 이게 전부예요 17:00 <+Complication> 나중에는, I2Phex가 한 번에 발사하는 병렬 피어 접촉 시도 수를 제한하는 게 의미가 있을지 고민했어요 17:01 <jrandom> 네, 아마 그럴 거예요 17:01 <+Complication> 짧은 시간에 NetDB 조회를 잔뜩 만들어내서 I2P router 입장에선 그다지 좋지 않을 수 있거든요 17:02 <jrandom> 그리고 새 Destination 접촉에는 aes 대신 elG가 필요하죠 17:02 <+Complication> 하지만 그 목표를 위한 실제 코드를 읽거나 쓰지는 아직 않았어요 17:04 <jrandom> ㅇㅋ 괜찮아요. 아마도 전설의 i2phex/phex 병합이 해결책을 같이 가져올지도요 :) 17:04 <+Complication> 제 쪽 I2Phex 소식은 대략 이게 다입니다... 17:04 <jrandom> 좋습니다, 업데이트와 조사해 준 노력에 감사해요! 17:05 <jrandom> 좋아요, 그럼 3) ??? 로 넘어가죠 17:05 <jrandom> 회의에서 더 다룰 것이 있는 분 있나요? 17:05 <lsmith> 안녕하세요! 최신 릴리스의 훌륭한 개선에 대해 개발자분들을 칭찬하고 싶어요. 제 총 대역폭이 0.9/1.4 KBps로 표시되는데도 irc에 계속 연결되어 있네요... 정말... 말도 안 되게 멋져요 :) 17:05 <+Complication> :D 17:06 <jrandom> 그동안 인내해 주셔서 감사합니다 - 낮은 대역폭 사용자 지원은 매우 중요합니다 17:06 <@cervantes> lsmith: 그거 정말 좋네 17:06 <@cervantes> * 연결 재설정 17:06 <jrandom> 헷 17:07 <lsmith> :) 17:09 <jrandom> 아, 주목할 만한 또 하나는 zzz가 돌아왔고, 그와 함께 stats.i2p도 돌아왔다는 겁니다 :) 17:09 <jrandom> [wewt] 17:11 <+Complication> 상당히 유용한 비교 데이터 소스죠 :) 17:11 <jrandom> 완전 동의 17:11 <jrandom> 좋아요, 회의에서 더 이야기할 것 있나요? 17:13 <jrandom> 없다면... 17:13 <jdot> baf 이후 질문이 한두 개 있어요 17:13 <jrandom> 헷 좋아요, 그럼 baffer를 굴려봅시다 :) 17:13 * jrandom 준비한다... 17:13 * jrandom 회의를 *baf*로 종료한다