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

13:04 <jrandom> 0) 안녕 13:04 <jrandom> 1) 0.5 13:04 <jrandom> 2) 다음 단계 13:04 <jrandom> 3) azneti2p 13:04 <jrandom> 4) ??? 13:04 <jrandom> 0) 안녕 13:04 * jrandom 손을 흔든다 13:05 <jrandom> 주간 상태 노트 올라감 @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html 13:05 <jrandom> (그래, 회의 시작 1~2분 전에 올렸으니 속독 실력 한번 시험해보자) 13:05 <+detonate> 그럼 이 경우 boondock saints는 버그가 좀 덜해질 때까지 올리지 않고 기다릴게요 13:06 <jrandom> 왜... 그건... 그건... 그건 저작권 침해야! 13:06 <+detonate> Azureus 베타에 이상한 새 기능들이 있네요 13:06 <+detonate> 카테고리 13:06 <+detonate> 하하 13:06 <+detonate> DHT 트래커 13:06 <+detonate> 굿 13:07 <jrandom> 응, 엄청 멋져 보이지만 3번 전에 1번이랑 2번부터 하자, 응? ;) 13:07 <+detonate> 안녕 13:07 <+detonate> 그렇지 13:07 <jrandom> 1) 0.5로 들어가자 13:07 <jrandom> 그게, 뭐, 이제 나왔고, 그런 거야 13:08 <cervantes> 예이! 13:08 <jrandom> 오늘 저녁 늦게 업데이트가 잔뜩 들어간 새 rev가 나올 거야 (현재 CVS head는 0.5-5이고, 일부 routers에서 -6 테스트 중) 13:09 <jrandom> 꽤 잘 진행됐지만, 중간에 좀 묘한 버그들을 만났어. 뭐, c'est la vie 13:09 <frosk> 0.5-5가 -4보다 훨씬 더 우호적으로 동작한다는 걸 보고합니다 (-4는 종종 참여하는 tunnel 개수가 수천 개까지 올라가곤 했죠) 13:09 <bla> jrandom: 0.5.0.1 버전이 목적지를 찾지 못하는 문제를 고치나요? 13:09 <jrandom> 아, 음, 그건 사실 다른 사람들 상태에 좌우되는 거고, -0 빌드는 실제로 수백 개의 tunnels를 빌드하긴 해 13:09 <bla> s/nor/not 13:10 <jrandom> bla: 응, 그건 netDb의 버그야 13:10 <bla> jrandom: 잘됐네요! 13:10 <jrandom> (정확히는 leaseSet 퍼블리싱에서) 13:11 <jrandom> 그리고 맞아, 0.5.0.1 rev는 가끔 프록시가 사라지는 버그를 없앨 거야 13:12 <jrandom> 여전히 몇몇 사용자에게 영향을 주는 묘한 메모리 릭이 있는데 아직 못 잡았어 13:12 <bla> 그러면, 전체적으로 이 버그들을 빼면 0.5 네트는 아주 잘 돌아가는 것 같네요. 예이! 13:12 <jrandom> 내가 알기론 두세 개의 I2PTunnel 인스턴스에서만 제대로 맞고 있는 것 같아 13:12 <Meomia> 0.5 이후 참여하는 tunnels가 0에서 130까지 늘었다면, 그게 진전의 신호인가요? 13:13 <jrandom> w3wt 13:13 <jrandom> Meomia: 에이, 난 5000개가 넘는 tunnels까지 봤는걸 ;) 13:13 <jrandom> 근데 dm이 exploratory 풀 코드 버그를 찾는 데 실제로 도움을 줘서, 앞으로는 'random' 피어들로 더 자주 tunnels를 빌드하게 될 거야 13:14 <jrandom> (예이) 13:14 <Meomia> 오케이 13:14 <bla> jrandom: 그럼 이제 0.4와 달리, 모든 피어가 한 번쯤은 너의 인바운드 게이트웨이가 될 수 있다는 뜻인가요? 13:14 <jrandom> 응, exploratory tunnels에 대해서는 그래 13:15 <jrandom> 클라이언트 tunnels는 'fast' 티어의 피어만 써 13:15 <bla> bla: 좋아요. 클라이언트 tunnels가 빠른 피어만 쓰는 건 좋네요: 그렇지 않으면 전에 논의했던 익명성 이슈가 생기니까요 13:16 <jrandom> 그리고 아니면 성능이 엉망일 거고 ;) 13:17 <jrandom> 사실, 그게 우리를 2) 다음 단계로 이끌지 13:18 <jrandom> 0.5 시리즈에 남은 큰 과제는 tunnels에 사용할 피어를 정렬하고/혹은 필터링하는 여러 전략들이야 13:18 <godmode0> jrandom i2p에서 nntp 쓸 수 ? 13:18 <jrandom> godmode0: i2p에는 NNTP 서버가 두 개 있어. 포럼을 봐 13:19 <godmode0> jrandom 오케이 테스트 중 13:19 <godmode0> 나도 내 서버 만들 수 있어 ? 13:20 <jrandom> godmode0: 지금 회의 중이긴 한데, 응, 서버 돌릴 수 있어 13:20 <godmode0> jrandom 오케이 미안 13:20 <jrandom> ㄱㅊ 13:20 <jrandom> 공개된 전략들은 기본적으로 익명성 향상을 목표로 하지만, 균형 잡을 수 있는 다른 목표들도 몇 가지 있어 13:21 <jrandom> 아마 bla가 제안한 대로 AS(자율 시스템) 경로를 선택에 통합할 방법을 찾을 수도 있을 거야 13:22 <jrandom> 그건 (사법 관할권 측면의) 익명성을 높일 수도 있고, 반대로 한두 개 AS 안에 머물려고 하면 성능을 높일 수도 있어 13:22 <bla> jrandom: 이건 기본적으로 Tor 제작자들의 논문과 관련 있죠: http://theland.i2p/files/routing-zones.pdf 13:22 <jrandom> 맞아 13:23 <jrandom> 사람들이 쓸 수 있는 전략이 잔뜩 있고, 새 걸 시도해보기도 꽤 쉬울 거야 13:24 <jrandom> 우리가 몇 달을 들여 생각나는 걸 전부 구현하진 않을 거고, 대부분이 필요로 할 기본만 제공할 거야. 새 전략을 추가하고 싶은 사람은 언제든지 플러그인하는 걸 도와줬으면 해 13:25 <jrandom> 아무튼, 기본이 자리 잡으면 0.6을 위해 UDP 트랜스포트에 집중으로 넘어갈 거야 13:26 <jrandom> 2) 다음 단계에 대해선 내 쪽 얘기는 여기까지고, 누가 코멘트/질문/우려 있어? 13:26 <bla> I2P를 살펴보기 시작한 사람들, 다시 누구였죠? 13:26 <bla> 요즘은 그 사람들 얘기를 별로 못 들은 것 같아서요. 13:27 <bla> s/into I2P/into UDP/ 13:27 <bla> 미안 13:27 <jrandom> 아, mule이 아팠고, detonate는 진전이 있는 것 같아 13:28 <jrandom> detonate: 소식 있어? 13:29 <jrandom> 아니면 없나 ;) 13:30 <jrandom> 좋아, 3) azneti2p로 넘어가자 13:30 <+detonate> 미안 13:30 <+detonate> 진전 내고 있어요 13:30 <+detonate> 아직 re-assembly 쪽을 마무리해야 해요 13:31 <+detonate> 데이터를 패킷으로 쪼개서 질서 있게 보내는 건 잘 동작해요 13:31 <+detonate> 3)로 13:31 <jrandom> 멋짐 13:31 <godmode0> 미안 단계 2) i2p 공격에 문제 있어 ? 13:31 <bla> detonate: 멋져요! 포럼에 진행 상황 계속 올려줄 수 있나요? 13:32 <+detonate> bla: 물론이죠 13:32 <tracker> azneti2p에 관해선 여기 봐요: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 다운로드는 되는 것 같은데, 시딩은 안 되네요. 13:32 <jrandom> godmode0: 서로 다른 정렬 전략들은 사용자가 predecessor attack(선행자 공격)의 영향을 어느 정도로 할지 선택할 수 있게 해줄 거야 13:33 <microsoft> i2p.net 운영하는 사람은 페이지에 Enterprise Class Solutions 같은 유행어를 더 넣어야 해. 13:33 <+detonate> Azureus 플러그인 관점에서 봤을 때 새 DHT 트래커도 이상 행동을 하지 않는지 누군가 확인해야 해요 13:33 <tracker> 내 로컬 테스트도 그걸 보여주는 것 같아요, Azureus로는 다운로드되는데 시드는 안 돼요. 13:34 <jrandom> 흠 알겠어 tracker, 고마워 - 어젯밤에 몇 가지 업데이트하고 b34를 올린 건 아는데, 보아하니 해야 할 게 더 남았을지도 13:34 <jrandom> detonate: 좋은 지적이야 13:35 <tracker> 좋은 지적이에요 detonate, 난 DHT를 비활성화했어요. 활성화하면 Azureus가 몇 시간 뒤에 CPU 100% 먹고 죽거든요. 13:35 * jrandom azneti2p 플러그인이 아직 꽤 초기 베타고, Azureus의 익명성 관련 함의가 완전히 감사를 거친 건 아니라는 점을 다시 한 번 강조하고 싶다 13:36 <jrandom> 그걸 테스트해보는 건 좋겠지만, 익명성이 필요한 사람은 조심하는 게 좋을 거야 13:36 <tracker> 반면 i2p-bt는 정말 잘 동작해요. tunnels를 닫지 않는다는 것만 빼면요, 근데 제 생각엔 그렇게 나쁘진 않아요. 13:37 <jrandom> 오, 그게 아직도 너한텐 발생해 tracker? 난 그걸 재현하지 못했는데 13:37 <jrandom> 0.1.7 rev 쓰고 있지? 13:37 <tracker> 네, 맞아요. 13:38 <jrandom> 좋아, 항상 발생한다면 회의 끝나고 원인 추적하는 데 네 도움을 좀 받고 싶어 13:39 <tracker> 아마 리눅스나 유닉스 대신 XP에서 돌리는 것과 관련이 있을지도요. Azureus에서는 tunnel 닫기가 되니까, I2P-BT 쪽 문제인 것 같아요. 13:39 <jrandom> 흠 맞아, i2p-bt는 SAM을 쓰고, Azureus는 i2p SDK를 직접 써 13:40 <tracker> 그나저나. 포럼에 버그 리포트를 보냈어요. I2P 최신 cvs-builds에서 timestamper가 죽어요. 13:40 <jrandom> 아 고마워, 오늘은 거기 PM을 아직 안 봤네 13:41 <jrandom> -5야, -4야? 아니면 그 이전? 13:42 <jrandom> 아, -4. 오케이 13:42 <jrandom> 고마워, 그건 0.5.0.1에서 고칠게 13:42 <jrandom> 좋아, 3) azneti2p에 대해 다른 거 있는 사람? 13:43 <tracker> -5에서도 발생해요 13:43 <jrandom> sntp server를 명시적으로 지정해놨지, 맞지? 13:44 <tracker> 네. 우리나라에 있는 2개요. 13:44 <jrandom> 방금 소스를 봤는데, 예외는 동시에 처리할 # 서버 수(기본 = 3)가 지정한 서버 수보다 큰 경우 발생해 (새 기본값이 3개야) 13:44 <jrandom> 좋아, 서버 수로 % 계산하도록 고치면 되는 사소한 수정이야 13:45 <jrandom> 좋아, azneti2p에 더 없으면, 이제 친숙한 4) ???로 13:46 <jrandom> 회의에서 더 다룰 거 있는 사람? 13:46 <tracker> 좋네요. 방금 포럼에 i2p-bt 종료할 때 router에서 나는 로그 에러를 보냈어요. 13:47 <jrandom> 오케이, 고마워 13:47 <cervantes> 언급할 건 없고, 0.5 롤아웃 잘했어, 버그만 다 잡히면 끝내줄 듯 13:48 <tracker> 맞아요, 최신 CVS 빌드가 여기선 정말 잘 돌아가요. 13:48 <jrandom> 고마워, 너희랑 다른 0.5-pre 테스터들 덕분에 많은 이슈를 정리할 수 있었어 13:49 <jrandom> 성능은 예상보다 좋았지만, 예전만큼의 높은 처리량은 아니야. 그래도 최적화할 게 많이 남았지 13:49 <cervantes> 이상하게 pre 버전이 더 안정적이었어... 내 경우엔, 뭐 다른 머신에서 돌렸으니까 ;-) 13:49 <jrandom> (그리고 이 망할 버그들 때문에 신뢰성을 제자리에 올려놔야지) 13:50 <jrandom> 헤, 뭐, 그래도 -pre 네트워크는 routers가 5-7대였고, 전부 미친 듯이 안정적이면서 정말 정말 빠른 연결이었잖아 13:50 <cervantes> :) 13:51 <cervantes> 그럼 0.6 pre 테스트에 날 등록해줘 :) 13:51 <jrandom> 헤 13:51 <tracker> 그럼 전 다음 pre 네트워크에 참여해야겠네요. 아주 불안정하고 느린 연결을 제공하면서 ;). 13:51 <jrandom> 0.6 마이그레이션은 아마 더 쉬울 거야, 희망하건대, routerInfo에 새 router 주소들(UDP 주소)을 추가하기만 하면 되거든 13:51 <jrandom> 헤 말 됨 13:51 <cervantes> 내 1TB 파일 공유를 온라인에 올릴 수 있어... 13:52 <jrandom> 0.6 테스트에는 정말 다양한 네트워크 환경이 필요하니까 많은 도움이 필요할 거야 13:52 <hobbs> ssh '~C' command 참 쓸만하네 13:52 <laberhorst> 이번에도 또 호환 안 되는 단계가 될까? 13:53 <Myo9> 지금 살아있는 nntp 서버 아는 사람? 13:53 <jrandom> laberhorst: 아니, 0.6은 하위 호환될 거야 13:53 <jrandom> Myo9: 잘 모르겠네, 켜져 있는데 0.5-0 버그에 물렸을 수도 있어 13:54 <jrandom> 0.5.0.1 rev가 많은 이슈를 고칠 거고, 나오면 업그레이드를 강력히 권장할 거야 13:54 <laberhorst> 그럼 테스트 0.6을 빌드해서 테스터에게 주지 13:54 <cervantes> BT 트래픽이 오래된 routers만 쓰도록 만들 수 있어... 그러면 사람들이 업그레이드하게 되겠지 ;-) 13:54 <laberhorst> 그럼 내일 대규모 업그레이드 파티 13:54 <jrandom> 준비되면 포럼이랑 메일링 리스트에 공지 올라갈 거야 13:54 <jrandom> 맞아 laberhorst 13:54 <jrandom> 헤 cervantes ;) 13:55 <laberhorst> *너희를 위해 테스트할 생각에 들뜸* 13:55 <jrandom> 0.5에서 BT 성능은 꽤 좋았어, 트래커에서 큰 파일 전송이 많이 성공하는 걸 봤거든 13:55 <laberhorst> 업로드 속도: 8.85 kB/s 13:55 <jrandom> (그리고 irc는 전에처럼 영향을 받지 않았고, duck의 tunnel 문제를 빼면 말이야) 13:55 <tracker> 뭐가 큰지에 달렸죠 ;) 13:56 <jrandom> tracker: 특정 874MB 파일을 생각하고 있는데, 성공적으로 받은 게 꽤 있지 ;) 13:56 <jrandom> 근데 맞아, 어떤 사람에겐 그건 작은 거지 13:56 <laberhorst> 그냥 올드한 포르노 13:56 <laberhorst> 라고 추측 ;-) 13:57 <laberhorst> 내일부턴 내 router가 >3000 tunnels에 참여하지 않기를 바라자 13:57 <tracker> 오케이, 그건 크네요. 13:57 <laberhorst> 아니면, 만약 그렇다면 네트워크가 크다는 뜻이고 13:57 <jrandom> 헤 laberhorst 13:58 <jrandom> 좋아, 회의에 대해 다른 거 있는 사람? 13:58 <laberhorst> 근데, participate in>3000이 I2P에서 빠른 연결을 가진 좋은 신뢰성 있는 router의 동의어야? 13:58 <+detonate> 오늘 밤 House 보고 오면 boondock saints 올릴게요 :) 13:59 <+detonate> 4.1gb짜리 좋은 놈이 될 듯 :) 13:59 * laberhorst 빠른 버그 스쿼싱에 대해 개발자들에게 감사 인사만 전하고 싶음 13:59 <+detonate> 수요가 많은 것 같아요 13:59 <laberhorst> 오, 여기 DVD 이미지도 좀 있어, 역시 13:59 <hobbs> detonate: 오, 맞다. House. :) 13:59 <tracker> cervantes, phpBB 2.0.12로 벌써 업그레이드했나요 13:59 <laberhorst> 하지만 0.5.0.1이 나올 때까지 기다려 13:59 <+detonate> 0.5.0.1에도 제대로 흔들어 테스트가 되겠지 14:00 <+detonate> 응 14:00 <+detonate> 그럴 생각이야 14:00 <jrandom> 물론, 그런 파일의 합법적 사본을 이미 가진 사람만 다운로드해야 해. 이건 어디까지나 테스트용이니까 14:00 <jrandom> 콜록 14:00 <tracker> rofl 14:01 * jrandom mpaa.i2p 메모 14:01 <+detonate> 헤 14:01 <laberhorst> 오, 난 debian, fedora, suse, 내가 찍은 사진들로 iso 이미지를 만들 수 있어,... 14:01 <laberhorst> 그래서 합법적 자료가 많아 14:01 <laberhorst> 그냥 테스트만 하고 싶다면, /dev/random은 매우 큼 14:01 <Ragnarok> 항상 그런 건 아냐 14:02 <laberhorst> 참고로, 외로운 주말엔: cat /dev/random | grep linux :-) 14:02 <jrandom> 헤 14:02 <frosk> /dev/random은 맨날 비니까, 난 /dev/urandom이 더 좋아 :) 14:02 <frosk> 아니면 새로 개선된 /dev/jrandom 14:02 <jrandom> 아냐, 그건 맨날 코어 덤프해 14:03 <jrandom> 그리고 밤마다 쉬어야 하고 14:03 <Ragnarok> /dev/random용 엔트로피를 생성하는 가장 좋은 방법은 뭐지? 14:03 <laberhorst> "jrandom에게 맥주 몇 잔 사주기" 모금을 진짜로 만들자 14:03 <frosk> 쉬는 거라고 부르든, 엔트로피 수집이라고 부르든 :) 14:03 <hobbs> Ragnarok: 뭘 정확히 뜻하냐에 따라. 하드웨어 RNG(난수 발생기)를 쓰는 게 거의 "최고"의 방법이긴 하지 :) 14:03 <jrandom> Ragnarok: OS에 따라 달라 (그리고 하드웨어가 있느냐에 따라 ;) 14:04 <tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 항상 좋지 ;) 14:04 <jrandom> 언젠가 빌드 중 하나에 Fortuna 구현을 번들링할 거고, 다양한 엔트로피 소스를 찾아봐야 해 14:04 <Ragnarok> 하드웨어 없이 :P 14:04 <susi23> . o O ( i2p 쓰는 사람이 왜 /dev/urandom을 쓰면 안 되는지 알 거라고 생각했는데 ) 14:05 <cervantes> tracker: 2.0.12에서 커버된 보안 취약점은 내 mod_rocinante가 의도치 않게 고쳐서, 아직 업그레이드할 필요를 못 느꼈어 14:05 <hobbs> susi23: 그냥 장난이면 괜찮다고 봐 ;) 14:05 <ant> <Nolar> 여기서 누가 Python BT 포트 하나요? 14:05 <jrandom> Nolar: 그건 duck 14:06 * duck 휘파람을 분다 14:06 <ant> <Nolar> duck: 왜 요청 블록 크기를 128k로 바꿨어요? 14:06 <susi23> . o O ( 다음 제안: while true; do echo $RANDOM>> largefile; done ) 14:06 <ant> <Nolar> 그래서 az가 너에게 시드하지 못하는 거야 14:06 <tracker> cervantes: 오케이 14:06 <ant> <Nolar> 우리는 64k 초과 요청을 차단해 14:06 <laberhorst> 젠장, mp3가 더 필요해 14:06 <frosk> susi23: 한가한 저녁에 linux를 grep하려면, /dev/urandom이면 충분해 :) 14:07 <jrandom> 아, 원래 그랬나? 내 기억으론 i2p-bt가 한동안 128k를 썼던 것 같은데 14:08 <ant> <Nolar> 응, 처음부터 그랬어 :) 14:08 <ant> <Nolar> 128을 쓰는 특별한 이유가 있나? 14:08 <ant> * duck cvs 로그를 뒤진다 14:08 <jrandom> 파이프라인을 채워두려구, i2p는 랙이 좀 있잖아 ;) 14:08 <jrandom> 32KB면 사실상 고정 윈도 크기가 1이야 14:09 <jrandom> 그래서 각 메시지가 ACK 기다리느라 막히고, 128KB면 RTT 동안 4개의 메시지가 날아갈 수 있어 14:09 <@duck> 맞아, BT 스펙상 허용되는 최대 슬라이스 크기 14:09 <ant> <Nolar> 이걸 처리하는 방법은 둘이지: 1) 우리가 제한을 128k로 올리거나, 2) 너희가 그냥 더 많은 요청을 파이프라인에 넣거나 14:09 <cervantes> i2pbt가 예전보다 좀 더 경쾌해졌어... 아마 줄여도 될지도... 14:10 <@duck> schni, schna, schnappi 14:10 <ant> <Nolar> 그래서, 단일 128k 요청 대신, 예를 들어 64k짜리 두 개를 동시에 보내 14:10 <hobbs> duck: 하하... 그건 전 세계로 퍼졌지. 14:10 <@duck> 왜 128k를 차단해? 14:11 <cervantes> 으으으* 유로팝 14:11 <laberhorst> duck: 제발 조용히 하든지 아니면 쏴버릴 거야! 14:11 <tracker> 가끔은 몇 년 전에 독일어를 배운 게 후회돼요... 14:11 <laberhorst> 유로팝 아냐, 진짜 POP도 아냐 14:11 * cervantes 그런 노래가 차트에 들어오기 전에 영국에 국경(?) 방어 명령을 내린다 14:11 <laberhorst> tracker: 신경 쓰지 마, 괜찮아 14:12 <ant> <duck> 지금은 (2^17)-13 14:12 <ant> <Nolar> duck: 그 제한은 오래전부터 있었고, 좋은 이유 중 하나는 128K 블록은 업로드하는 데 시간이 걸려서야.....16KB(우리 기본값)는 더 세밀한 요청 제어가 가능해 14:12 <ant> <duck> 13바이트는 BitTorrent 명령 길이임 14:12 <ant> <duck> (2^16)-13은 문제없어 14:12 <laberhorst> 어떤 음악은 정말 우습지만, 진짜 인더스트리얼 음악은, 으, 그건 아니야 14:13 <ant> <duck> 아니면 기본으로 되돌릴까? 14:13 <jrandom> 64KB로 줄이는 게 가장 간단해 보이네 (그거 지금 CLI 파라미터야?) 14:13 <ant> <duck> --download_slice_size 14:14 <ant> <Nolar> 특히 i2p에선 128K 블록이 좀 큰 것 같은데, 그걸 고집하는 설득력 있는 이유가 있나 14:14 <ant> <Nolar> 더 작은 요청 여러 개를 파이프라인에 넣는 대신에 말이야? 14:14 <ant> <duck> 이유 없어. 14:14 <tracker> laberhorst: 가끔 위성을 통해 독일 채널을 조금 봐요. 특히 viva랑 "Theater Kanal"은 정말 끔찍하더군요... 14:15 <ant> <Nolar> 큰 블록의 문제 중 하나는 내가 널 choke(업로드 차단)하면, 그 128k 청크를 끝까지 보내야 한다는 거야 14:15 <jrandom> 바닐라 BT가 파이프라이닝을 아는지 기억은 안 나는데, 충분히 간단할 거야 (특히 내가 그걸 하는 게 아니니까 ;) 14:15 <ant> <Nolar> 그게 한동안 걸릴 수 있어 14:15 <laberhorst> tracker: viva는 "하드 록" 시간대만 흥미롭고, 그 외 시간대는 "무시 요망", theater는, 잘 모르겠어 14:15 <jrandom> i2p에선, 초 단위의 고유 랙이 있어서 128KB가 그리 큰 건 아니야 14:15 <ant> <Nolar> 그게 chunk/unchoke를 꼬이게 할 수 있어 14:16 <@duck> jrandom: SAM 메시지에 딱 맞추려고 BitTorrent 13바이트 오버헤드를 빼는 게 아직 의미 있어? 14:16 <jrandom> duck: 아니, 스트리밍 라이브러리가 이미 그걸 16KB 메시지로 더 줄이니까, 그냥 64KB로 하자 14:17 <@duck> 오케이, 2**16로 14:17 <jrandom> (그리고 나서 tunnels가 그 16KB 메시지를 996바이트 조각으로 나눠버리지..) 14:17 <ant> <Nolar> 문제는 128k야, 예를 들어 내가 12 k/s로 업로드 중이면, 그 블록을 끝내는 데 10초 이상 걸린다는 거지 14:18 <cervantes> 와 그건 거의 irc 랙만큼 길잖아... 14:18 <jrandom> 즉, 1-10 RTT(왕복 지연)이야 (일반 네트에선 10-500) 14:18 <+detonate> 난 512K 블록을 쓸 준비가 다 됐었는데 14:18 <ant> <Nolar> 16kb 블록을 파이프라인으로 넣는 것도 실험해볼 수 있지 14:18 <jrandom> 헤 14:18 <+detonate> 그럼 64가 선호돼? 14:19 <ant> <Nolar> 내가 아는 한 모든 bt 클라이언트가 16KB 블록을 써 14:19 <ant> <duck> CVS에 반영됨; 14:19 <jrandom> 멋져, 고마워 duck! (그리고 Nolar도!) 14:19 <ant> <duck> 0.1.8 릴리스에 SAM I2CP 튜닝과 함께 들어갈 거야 14:19 <tracker> laberhorst: 전체 이름은 "ZDF Theater"였나 그래요. 높은 수준의 문화 프로그램을 보낸다고 하던데. 제발 그게 독일 문화의 최고는 아니길 바라요 ;) 14:19 <jrandom> 오케이, 헤, 우리 아직 회의 중이라는 걸 이제 생각해냈네 14:19 <jrandom> 회의에 대해 다른 거 있는 사람? 14:20 <ant> <Nolar> 그래서 128k 청크가 필요하면, 동시에 8개의 요청을 보내 14:20 <susi23> . o O ( 그리고 남는 448바이트는 버려? ) 14:20 <jrandom> 맞아 맞아 14:20 <laberhorst> tracker: 오, 그건 작은 사이드 채널... arte나 3sat이 훨씬 더 흥미로워 14:20 <laberhorst> 그리고 arte는 독일/프랑스 공동이야 :-) 14:20 <ant> <Nolar> 업로더가 그런 요청을 채울 수 있으면, 128k 전부가 I2P 파이프 스트림에 밀어 넣어져야 해 14:20 <jrandom> 굿 14:21 <cervantes> . o O ( 왜 susi가 생각하는 걸 내가 다 들을 수 있지 ) 14:21 <ant> <Nolar> 그러니 16KB vs 32KB vs 64KB 블록 크기를 실험해볼 가치가 있을지도 14:21 <jrandom> 응 14:21 <jrandom> 파이프라인만 되어 있으면, i2p는 상관 안 해 14:21 <ant> <Nolar> 좋아 14:22 <jrandom> 파이프라인 없이 16KB일 때 속도는 꽤 나빴거든, 적어도 예전엔 그랬어 14:22 <tracker> laberhorst: 알겠어요, 며칠 내 arte를 볼 수 있는지 시도해볼게요... 14:22 <ant> <duck> 이런 미세 조정은 0.2로 미루자고 제안해 14:22 <ant> <duck> 거기에 bittorrent 3.9.1 개선이 포함될 테니까 14:22 <jrandom> 그래, DTSTTCPW 14:22 <susi23> . o O ( 아 그건 쉽지... 사람들은 너무 예측 가능하거든... ) 14:23 <ant> <duck> 그게 네트워크 코드를 완전히 재구성할 수도 있어 14:23 <cervantes> http://www.gavelstore.com 14:24 <jrandom> 좋아, 지금은 여기까지인 것 같고, 0.5.0.1 rev가 곧 나올 테니 몇 시간 뒤에 리스트와 사이트를 확인해 14:24 <ant> <Nolar> 응, 단일 16kb 요청만 있으면 느릴 수 있겠네 14:24 * jrandom gavel을 다운로드한다 14:24 * jrandom *baf* 하고 회의를 종료한다