I2P 개발자 회의 - 2005년 3월 22일

13:01 <@jrandom> 0) 안녕 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) 배칭 13:01 <@jrandom> 3) 업데이트 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) 안녕 13:01 * jrandom 손을 흔듦 13:01 <@jrandom> 방금 올린 주간 상태 노트가 http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 에 올라와 있어요 13:02 <+detonate> 안녕 13:02 <+cervantes> 안뇽 13:02 <@jrandom> 바로 1) 0.5.0.3 로 들어가죠 13:02 <@jrandom> 며칠 전에 릴리스가 나왔고, 보고는 긍정적입니다 13:02 <+cervantes> jrandom: 파란 난쟁이들이 춤추며 네 모니터 위로 기어오르면 알려줘, 회의 일찍 끝낼게 13:03 <@jrandom> 헤헷 cervantes 13:03 <@jrandom> (편집 가능한 회의 로그를 제공한 Bob에게 감사 ;) 13:04 <@jrandom> 그 메시지에 있는 것 외에 0.5.0.3에 관해 딱히 덧붙일 건 없어요 13:04 <@jrandom> 이에 대해 의견/질문/우려 있으신가요? 13:04 <bla> jrandom: fast-peers-selection 코드에 대한 새로운 측정치가 있나요? 13:05 <@jrandom> 아, 0.5.0.3에 내가 빠뜨린 게 또 있었지 ;) 13:06 <@jrandom> 아직 확실한 지표는 없지만, 경험적으로 fast peer selection이 제가 명백히 '빠르다'고 아는 peer들을 잘 찾아냅니다 (예: 같은 박스의 routers 등) 13:07 <bla> jrandom: 가끔 eepsites가 여전히 쓸 만한 tunnel을 찾으려면 여러 번 재시도가 필요합니다 13:07 <@jrandom> 때로는 꽤 합리적인 처리량 보고도 들어옵니다 (10-20KBps 범위) 다만 아직은 자주 나오진 않아요 (파라미터를 낮춰 둔 상태라) 13:08 <+ant> <Connelly> 이런, 회의가 있네 13:09 <@jrandom> 흠, 네, 아직 신뢰성이 필요한 수준에 못 미치고 있어요. 여러 번 재시도하는 건 해결책이 아닙니다 - 1번 재시도해도 사이트가 안 뜨면 재시도하기 전에 5-10분 정도 두세요 13:09 <@jrandom> 네트워크에서 전송 계층 지연 스파이크가 꽤 자주 보이더군요 13:10 <@jrandom> 예: 소켓을 통해 1-2KB 메시지 하나를 flush하는 데만 5-20+초가 걸리는 경우 13:10 <@jrandom> 거기에 5 홉 경로(2 홉 tunnels)를 묶어 놓으면 문제가 생길 수 있죠 13:11 <@jrandom> 그게 바로 배칭 코드를 밀어붙이는 이유 중 하나예요 - 보내야 할 메시지 수를 줄이는 것 13:13 <@jrandom> 좋아요, 0.5.0.3에 관해 다른 질문/의견/우려 있나요? 13:13 <bla> jrandom: 좋아 보입니다. 다음 "섹션"에서 더 물어볼게요 13:14 <@jrandom> w3rd, 좋아요, 그럼 2) 배칭으로 넘어가죠 13:15 <@jrandom> 이메일과 제 블로그(jrandom.dev.i2p</spam>)에 계획의 기본이 설명되어 있습니다 13:15 <@jrandom> 그리고, 음, 사실 꽤 기본적인 것들이에요 13:15 <@jrandom> 지금 있는 preprocessor는 구현하기 가장 단순한 걸로 만들었어요 (클래스명: TrivialPreprocessor) ;) 13:16 <@jrandom> 새 것은 배칭 빈도를 조절하는 파라미터가 있고, 개별 tunnel 풀 내부에서 outbound tunnel 선호(예: 후속 요청에 대해 최대 500ms 정도 같은 outbound tunnel을 선택해 배칭을 최적화하려는 시도)도 있습니다 13:17 <@jrandom> 그 정도가 전부예요 - 질문/의견/우려 있나요? 13:18 <bla> 이건 참여하는 모든 노드가 새 preprocessor를 돌려야 하나요, 아니면 Trivial/새것 혼합도 공존 가능한가요? 13:18 <+Ragnarok> 이거 지연에 0.5초가 추가되겠죠? 13:19 <@jrandom> bla: 아니요, 이 preprocessor는 tunnel gateway에서만 쓰이고, 배칭을 어떻게 할지 말지는 그 gateway가 결정합니다 13:20 <@jrandom> Ragnarok: 보통은 아닙니다 - 메시지 1은 최대 0.5초 지연될 수 있지만, 메시지 2-15는 원래보다 훨씬 빠르게 전송됩니다. 또 단순한 임계값이라서, full tunnel message만큼의 데이터가 준비되면 곧바로 flush합니다 13:20 <+Ragnarok> 멋지네 13:20 <+Ragnarok> 얼마나 오버헤드를 줄이나요? 13:21 <@jrandom> 상당히요 ;) 13:21 <+Ragnarok> 상당히면 좋은데, 좀 모호하군요 :P 13:21 <@jrandom> 네 http://localhost:7657/oldstats.jsp#tunnel.smallFragments 를 보세요 13:21 <@jrandom> 그걸 #tunnel.fullFragments 와 비교해 보세요 13:22 <bla> jrandom: 이게 endpoint->IB-gateway 통신에만 해당하나요? 13:22 <@jrandom> 배칭을 하면, full 대비 small 비율이 올라가고, small의 패딩 바이트 수는 내려갑니다 13:23 <@jrandom> bla: 흠, inbound든 outbound든 모든 tunnel gateway에 해당합니다 13:24 <mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events 13:24 <bla> jrandom: 알겠어요 13:24 <mihi> 조각(fragment) 수가 분수가 될 수 있나요? 13:24 <@jrandom> full: 1.00 over 807,077.00 events small: 746.80 over 692,682.00 events 13:25 <@jrandom> 헤헤 mihi 13:25 <@jrandom> (저 small: 746은 저 692k 메시지에서 996바이트 중 746바이트가 패딩으로 낭비되었다는 뜻!) 13:26 <@jrandom> 음, 완전히 낭비는 아니죠 - 제 역할은 했으니까요 13:26 <+detonate> 어쨌든 불필요한 오버헤드 13:27 <@jrandom> 맞아요, 그중 상당량은 배칭 preprocessor로 줄일 수 있을 겁니다 13:28 <@jrandom> 아쉽게도, 다음 릴리스에는 포함되지 않을 거예요 13:28 <@jrandom> 하지만 0.5.0.6 리비전에 포함될 겁니다 (아니면 0.5.1) 13:28 <@jrandom> 음, 0.5.0.5, 아니면 0.5.1 13:28 * jrandom 숫자에 헷갈림 13:29 <bla> jrandom: 왜죠? 13:29 <+cervantes> 해시랑 약... 젠장 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: 0.5.0.3(및 그 이전)에는 fragmented message handler가 같은 tunnel message 내에서 후속 fragment들을 버리게 만드는 버그가 있어요 13:31 <@jrandom> 배칭 preprocessor를 바로 배포하면, 메시지 손실이 꽤 많이 발생할 겁니다 13:31 <@jrandom> 걱정 마세요, 다른 멋진 것들도 준비해 두었으니 이번 0.5.0.4가 아주 지루하진 않을 거예요 ;) 13:31 <bla> jrandom: 아, 그래서군요 13:32 <bla> jrandom: 그래서 0.5.0.4가 보급된 후에 해야 하는 거였군요.. 이해했습니다. 감사합니다. 13:33 <@jrandom> 네, fragment handler가 처리해 주면 좋겠지만, 일반적으로는 하긴 해요, 다만 바이트 버퍼를 너무 일찍 해제해서 후속 fragment를 0으로 지워버립니다 (읏차) 13:33 <@jrandom> 좋아요, 2)에 대해 더 있을까요, 아니면 3) 업데이트로 넘어갈까요? 13:35 <@jrandom> 좋아요, 상태 노트에서 언급했듯이(여러 군데에서 꽤 논의되기도 했고), 최종 사용자가 웹사이트에 가거나 메일링 리스트를 읽거나 채널 토픽을 읽지 않아도 되는, 간단하고 안전한 업데이트 기능을 추가할 겁니다 :) 13:36 <+detonate> 멋지군요 13:36 <@jrandom> smeghead가 자동화와 보안을 돕는 코드를 만들어 줬고, cervantes와 함께 fire2pe 및 일반 routerconsole과도 연동하고 있어요 13:37 <@jrandom> 이메일에는 제공될 기능의 개요가 나와 있고, 대부분은 동작하지만 아직 완전히 정리되지 않은 부분이 몇 가지 있습니다 13:37 <@jrandom> 배칭과 달리, 이건 다음 리비전에 /반드시/ 포함될 거예요, 다만 사람들이 실질적으로 쓰기 시작하는 건 0.5.0.5부터일 겁니다 (업데이트할 때) 13:39 <+Ragnarok> 그럼... 5.0.4에는 뭐가 멋진가요? 13:42 <@jrandom> 업데이트 코드와 함께 공지 데이터를 받아와 router console 상단에 뉴스 조각을 표시하는 기능이 들어갑니다. 그 외에도 업데이트 코드의 일부로, 직접 또는 eepproxy를 통해 동작하면서 중간에 재시도와 이어받기를 하는 새로운 신뢰성 높은 다운로드 컴포넌트가 있어요. 아마 그걸 기반으로 한 관련 기능도 나올 수 있지만, 장담은 못해요 13:42 <+Ragnarok> 좋네요 13:43 <@jrandom> 좋아요, 3) 업데이트에 대해 다른 질문/의견/우려 있나요? 13:45 <@jrandom> 없으면, 4) ??? 로 넘어가죠 13:45 <@jrandom> 다른 얘기할 것 있나요? 저도 몇 가지는 놓쳤을 거예요 13:45 <+detonate> i2p가 OpenBSD 3.7의 sun jvm에서 동작하는 걸로 확인됨 :) 13:45 <@jrandom> 나이스! 13:47 <bla> UDP transport는 상태가 어떤가요? 13:48 <+detonate> udp는 좀 지저분해질 거라, bt에서 파이프라이닝 코드를 훔쳐와서 바꾸는 게 더 나을 듯 ;) 13:48 <@jrandom> *기침* 13:49 <@jrandom> 큰 문제는 없을 거라 보지만, 해야 할 작업은 분명 있죠 13:49 <@jrandom> 큐잉 정책이 어떻게 동작하는지, 그리고 큐에 들이는 대역폭 제한(bw throttling)이 어떤지 등이 흥미로울 겁니다 13:50 <bla> 그 사전 작업은 누가 했죠? 13:50 <@jrandom> bla: detonate와 mule 13:50 <+detonate> 맞아요.. 지난 한 달 정도는 좀 게으름 피웠지만요 13:50 <bla> detonate: BT 얘긴 농담이죠? 13:51 <+detonate> 반은 진담 13:51 <+detonate> 그렇게 하면 transport의 스레드 수를 최소한 절반으로는 줄일 수 있을 거라서요 13:51 * jrandom detonate에게 진흙 양동이를 던짐 13:51 <jdot> 우후. 내 router가 이제 구린 케이블 회선 대신 전용 서버에서 돌아가요. 13:51 <@jrandom> 잘했어 jdot 13:52 <@jrandom> 모든 peer와의 모든 통신에 대해 transport 계층에서 3-5개의 스레드로 버틸 수 있을 겁니다 13:52 <bla> detonate: 하지만 네트워크가 커지면(수백 노드 이상) 절반으론 안 될 텐데요 13:52 <jdot> 사용 가능한 b/w 1000GB 13:53 <jdot> 안타깝게도 j.i2p와 chat.i2p는 마이그레이션 동안 몇 시간 더 내려갈 거예요 13:53 <duck> detonate: addressbook도 중지? 13:53 <+detonate> 응, 그것도 중지야 13:54 <+detonate> 지금 멈춰 있지 않은 건 monolithic profile storage뿐, 그건 오늘 늦게 작업하려고 했거든 13:54 <@jrandom> w3rd 13:54 <+detonate> 그러면 i2p가 드라이브를 심하게 조각화하지 않을 거야 13:54 <jdot> jrandom: BW 제한은 평균인가요? 13:54 <+frosk> 최신 파일시스템은 조각화되지 않아, 바보야 13:55 <+detonate> NTFS는 돼 13:55 <@jrandom> jdot: 대역폭 제한은 엄격한 token bucket(토큰 버킷)입니다 13:55 <@jrandom> jdot: burst duration을 설정하면, 그 기간 동안 평균을 냅니다 13:56 <@jrandom> (음, 2x burst == 기간) 13:56 <@jrandom> ((대략)) 13:56 <jdot> 흠... 내게는 1000GB가 있고 i2p가 월 800GB까지 쓰게 하고 싶어요.... 13:56 <+ant> <mihi> detonate: ntfs는 매우 작은 파일을 mft에 저장해서 거의 조각화가 없어요 13:57 <jdot> 그리고 burst는 신경 안 써요 13:57 <+detonate> 음, 디프래그 돌리면 6000개 프로필을 옮기느라 10분은 쓰니까.. 조각화는 되는 거지 13:58 <@jrandom> jdot: 음, 800GB는 아마 어차피 그만큼 밀어내고 싶어 하진 않을 테니, 제한 없이 가도 될 듯 ;) 13:58 <@jrandom> 한편, 구현해 주길 바라는 정책을 설명해 주시면 대응할 수 있을지도 몰라요 13:58 <jdot> jrandom: 일단 그렇게 해 보고 잘 되는지 보죠 13:58 <bla> detonate: NTFS는, 제 기억이 맞다면, 저널링 FS예요. 그래서 단일 파일이라도 조금씩 쓰면 조각화됩니다 13:58 <+detonate> 모든 걸 한 번에 씁니다 13:59 <+detonate> 그리고 한 번에 읽고요 13:59 <bla> detonate: 알겠습니다. 13:59 <jdot> jrandom: 음, 문제가 될지부터 봅시다. 13:59 <bla> detonate: 그럼 잘하셨어요! 13:59 <+detonate> 좋은 회선에서 제한을 풀어 두면 실제 사용량이 얼마나 되는지 궁금하네요 14:00 <+detonate> 좋은 연결에서 14:00 <jdot> 나도 궁금! 14:00 <@jrandom> 내 콜로 routers는 제한 없이 돌려요, 다만 CPU가 제약이라 14:00 <+Ragnarok> 한 달 평균을 내도록 bitbucket을 쓸 수는 없나요? 14:00 <jdot> jrandom: CPU 제약이라고요? 어떤 CPU죠? 14:01 <@jrandom> 4d transfer 3.04GB/2.73GB 14:01 <+detonate> 흠, 더 적을 줄 알았는데 14:01 <@jrandom> jdot: 같은 시스템에서 router를 3개 돌리고, 다른 JVM 몇 개에, 가끔 프로파일링도 해서 CPU가 제약이에요 14:01 <+detonate> 아마 bt 하는 사람들일 듯 14:01 <+detonate> 배칭이 들어가면 그게 어떻게 바뀌는지도 궁금하네요 14:02 <@jrandom> detonate: 그 전송량 중 일부는 자기 자신 사이에서 50MB 파일을 밀어 넣은 것도 있어요 ;) 14:02 <+detonate> 헿 14:02 <jdot> 아하. 좋아요. 이 시스템이 어떻게 하는지 보죠. AMD XP 2400, 512MB, 10Mbit 연결 14:02 <@jrandom> Ragnarok: token buckets은 그런 식으로 동작하진 않아요 14:02 <@jrandom> jdot: 워드, 응, 이건 P4 1.6이었던 걸로 14:03 <@jrandom> Ragnarok: token bucket에서는 매 (예: 1) 초마다 rate에 따라 일정량의 토큰을 추가합니다. 버킷이 가득 차면(size = burst period) 토큰은 버려집니다 14:04 <@jrandom> 데이터를 전송하려면 언제나 충분한 토큰을 받아야 하죠 14:04 <@jrandom> (1 token = 1 byte) 14:04 <+Ragnarok> 원리는 알아요... 버킷을 아주 크게 만들면 어떻게 되죠? 14:05 <+detonate> 그러면 데이터 전송을 절대 멈추지 않죠 14:05 <+detonate> 버킷 크기가 무한하면 14:05 <+detonate> 어, 그리고 토큰으로 가득 차 있다면요 14:05 <@jrandom> 아주 크면, 사용량이 낮은 뒤에 무제한 속도로 버스트할 수도 있어요 14:06 <@jrandom> 물론 경우에 따라선 그게 바람직할 수도 있고요 14:07 <@jrandom> 문제는, token bucket을 800GB로만 설정한다고 해서 총 전송량이 제한되진 않는다는 겁니다 14:08 <+detonate> 초당 토큰 수를 설정하는 필드가 필요하고, 그러면 월 대역폭 사용량을 초 단위로 나누면 되죠 14:08 <+detonate> :) 14:10 <@jrandom> 그건 한 달 평균 rate를 설정하는 것과 같아서, 균형이 안 맞을 거예요. 어쨌든 시나리오는 많습니다 - 현재 제공되는 기능으로는 충족되지 않는 니즈가 있다면 연락 주세요 14:10 <+Ragnarok> 하지만 원하는 평균 rate를 설정하고... 여기선 308 kB/s쯤이요, 그리고 bitbucket을 아주 large하게 설정하면... 왜 그건 안 되죠? 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> 음, 60초짜리 burst period에서 800GB/44000을 넘지 않게 설정할 수도 있죠 14:12 <+detonate> 44000은 한 달의 분 수를 대충 근사한 값 14:13 <@jrandom> 버킷 크기/버스트 지속시간은 제약 없이 보낼 수 있는 양을 설명하고, 대부분의 사람은 제약을 /원하니까/, router가 버킷을 비우는 동안 5분 동안 10mbps를 집어삼키지 않도록 하는 겁니다 (혹은 그 외 무엇이든) 14:14 <@jrandom> 버킷에서 나오는 토큰에 추가적인 스로틀을 두는 것도 가능합니다 (그리고 그 스로틀에 또 자체 token bucket이 있어야 할지, 그 버킷에 또 자체 스로틀이 있어야 할지, 등등) 14:16 <+Ragnarok> 난 버킷이 사용되지 않는 대역폭이 있을 때만 채워지는 줄 알았어요 14:16 <@jrandom> 토큰은 일정한 rate로 버킷에 추가됩니다 (예: 초당 64k 토큰) 14:17 <@jrandom> 대역폭이 필요한 건 언제나 버킷에 요청합니다 14:18 <+Ragnarok> 아.. 알겠어요 14:19 <@jrandom> 좋아요, 회의에서 더 꺼내고 싶은 주제 있나요? 14:21 <@jrandom> 없으면 14:21 * jrandom 마무리 14:21 * jrandom 회의를 *baf*로 닫습니다