I2P 개발자 회의 - 2004년 5월 18일

14:07 <jrandom> 0) 안녕 14:07 <jrandom> 1) 테스트넷 상태 14:07 <jrandom> 2) SAM 14:07 <jrandom> 3) 로드맵 업데이트 14:07 <jrandom> 4) MyI2P 14:07 <jrandom> 5) ??? 14:07 <jrandom> 0) 안녕 14:07 * jrandom 손을 흔든다 14:08 <Nightblade> 안녕 14:08 * jteitel 손을 흔들어 답한다 14:08 <jar> 안녕 14:08 <duck> 안녕 14:08 <Masterboy> :P 14:08 <jrandom> 주간 상태 노트를 여기에 올렸습니다: http://dev.i2p.net/pipermail/i2p/2004-May/000239.html 14:09 <jrandom> 오늘 살짝 멍하면 미안, 수면 스케줄이 평소보다 더 엉망이라서 14:09 <jrandom> 아무튼, 1) 테스트넷 상태로 넘어가죠 14:10 <duck> 네트워크가 더 커지면 다양화는 자동으로 일어나지 않나요? 14:10 <jrandom> 맞아요, 그리고 피어 선택 임계값의 왜곡을 줄이면 더 그렇고요 14:11 <jrandom> 예를 들어 속도 임계값을 평균이 아니라 중앙값으로 삼으면, 빠른 피어 수가 신뢰성 높은 피어 수의 절반 정도가 될 거예요 14:11 <jrandom> 지금처럼 속도 분포가 심하게 치우친 상황과는 달리요 14:12 <Masterboy> 그래도 네트워크가 회복됐으니 그렇게 나쁘진 않네요 14:12 <jrandom> 맞아요, 다만 예상보다 오래 걸렸고, 개선할 수 있는 부분들이 드러났죠 14:13 <jteitel> 네트워크가 회복됐나요? i2p irc에 아직 안정적으로 접속하지 못하겠어요 14:13 <jrandom> 피어 프로파일이 충분히 빨리 감소하지도 않았고, 새 후보를 효과적으로 승격시키지도 못했죠 14:14 <jrandom> 그로 인해 이차적인 사건들도 연쇄적으로 발생했어요 - 부하를 감당할 수 없는 router들이 과부하 상태가 되었고(프로파일링이 충분치 않아서), 일부 과부하된 router는 메모리가 부족해져 종료되기도 했습니다 14:15 <human> 아이이이! 14:15 <jrandom> 점진적으로 나아지고 있어요 jteitel - 우리가 겪은 문제 중 일부는 netDb 장애와 관련이 있습니다 14:15 <jrandom> 안녕 human 14:15 <jteitel> 오, 알겠어요 14:16 <_cervantes_> 문제가 있는 router가 tunnel을 다른 피어로 오프로드할 수는 없나요? 14:16 <ugha_node> 와, 누적 전송률: 보냄 8.87KBps 받음 8.35KBps. 14:16 <Nightblade> jteitel: 방금 몇 번 시도 끝에 연결했어요...아직 제 /join 이 처리되길 기다리는 중 14:16 * BrianR 둘러본다. 14:16 <jrandom> 아니요 - 다만 router는 tunnel을 그냥 버릴 수는 있어요(애초에 수락하지 말았어야 했다면) 14:16 <ugha_node> (그리고 30분 전에 제 router를 재시작했어요) 14:16 <BrianR> 젠장. 늦었네. 14:17 <BrianR> jrandom: (안건 맨 끝으로 myi2p를 배치해줘서 고마워요) 14:17 <jrandom> ugha> 네, 그 세 개의 빠른 녀석들 몫까지 여러분이 메꿔야 했죠 14:17 <jrandom> 헤헤 :) 14:18 <duck> 멋진 공격이었죠 14:18 <ugha_node> jrandom: 분명하죠. 14:18 <_cervantes_> 그렇다면 더 가차없이 더 낮은 임계값에서 tunnel을 거절하는 편이 낫지 않을까요 14:19 <jrandom> 맞아요 cervantes - 지금은 router가 다음 홉에 도달할 수 없을 때를 제외하고는 tunnel을 절대 거절하지 않아요 14:19 <jrandom> 그 안에 일종의 쓰로틀링을 넣어야 할 거예요, 예를 들어 jobQueue / avg lag 같은 것들을 기준으로요 14:20 <jrandom> 또한 한 번에 너무 많은 tunnel을 만들려고 하지 않도록 해야 해요, 많은 tunnel이 실패했을 때 그런 일이 벌어졌거든요 14:20 <_cervantes_> 아니면 사용자가 자신이 사용할 수 있다고 아는 하드웨어/대역폭을 기준으로 임계값을 직접 설정하게 해도 되고요 14:20 <jrandom> (빠르고 신뢰성 있는 피어들이 오프라인으로 전환되었기 때문에) 14:20 <_cervantes_> 적어도 지금 단계에서는요 14:20 <jrandom> 오 좋은 지적이에요 - 참여하는 tunnel의 최대 개수를 명시적으로 설정할 수 있게 하죠. 14:21 <jrandom> 그건 다음 rev에 반영하겠습니다. 좋은 제안이에요. 14:21 <ugha_node> 이거 퍼지 로직 같네요. 14:21 <jrandom> 과부하를 처리해야 하고, 메시지를 메모리에 그냥 큐잉하는 방식은 확실히 통하지 않아요 14:21 <duck> (안녕 fvw) 14:21 <_cervantes_> tunnel 성능에 대한 어떤 형태의 취합된 통계가 있으면 좋겠어요... 벤치마크 프로세서(들)에 얼마나 부하를 줄 수 있는지 같은 14:22 <_cervantes_> 참, 제 서버는 내렸어요.... tunnel이 엄청 몰려오는데 아직 jbigi를 컴파일하지 못했거든요 ;-) 14:22 <jrandom> http://localhost:7655/routerStats.html#Tunnels 를 보세요 14:23 <jrandom> 아! 네, jbigi는 모두가 쓰도록 권장하고 싶어요 14:23 <BrianR> tunnel별 대역폭 예산을 두는 것에 대한 생각은 어떤가요? 14:24 <jrandom> 현재 3.0에 예정되어 있어요(전체 router에 대한 총 대역폭 제한은 0.4.1에) 14:24 <jrandom> 하지만 tunnel별 대역폭 제한을 더 일찍 도입해도 나쁠 건 없겠죠 14:25 <fvw> 현재 사용자/테스터 대부분이 쓰는 OS 커널에서 훨씬 더 쉽고 정밀하게 할 수 있는데, 너무 이른 시점에 여기에 노력을 들이는 게 현명할까요? 14:25 <_cervantes_> 제가 보고 싶은 건 tunnel별 깊이 설정이에요 (어쩌면 이미 가능한가요) 14:25 <_cervantes_> 예를 들어 제 서버는 신뢰할 수 있다는 걸 아니까요.... 거기까지 가는 데 _x_ 홉을 거치고 싶지 않아요 14:25 <jrandom> fvw> 좋은 지적이에요, 특히 지금은 대역폭을 그렇게 많이 잡아먹지 않으니까요 14:26 <jrandom> 흠 cervantes - 네, 각 클라이언트가 자신의 tunnel 길이를 지정할 수는 있지만, 그게 정확히 당신이 원하는 건지는 모르겠네요 14:26 <_cervantes_> 아니요 14:26 <jrandom> cervantes - 원하시는 건 특정 피어에 대해 연결을 더 짧게 할 수 있는 QoS 같아요 14:26 <_cervantes_> 예를 들면... 14:26 <_cervantes_> 네 14:27 <jrandom> (그건 i2p 4.0에 예정되어 있었는데, 1년 넘게 남았으니 == 무한대죠) 14:27 <_cervantes_> 이 경우 또한 i2p 호스트별로 깊이를 선택 14:27 <BrianR> fvw: 맞아요. 하지만 현명하게 tunnel을 구성하려면, 잠재적 tunnel 구성원들이 어느 정도의 대역폭을 사용할 수 있는지 i2p가 대략 알아야 해요... 14:27 <_cervantes_> 아, 알겠어요 14:27 <_cervantes_> :) 14:27 <jrandom> 그래도 좋은 아이디어고, 기술적으로 가능해요, 패치 환영 :) 14:28 <_cervantes_> 패치는 이미 우편으로 보냈어요.... e-gold 5000 bars짜리 수표랑 함께요 14:28 <_cervantes_> ;-) 14:28 <jrandom> BrianR: 절충안으로 갈 수도 있겠네요 - 참여 중인 tunnel의 개수와 그 tunnel들이 쓰는 대역폭을 추적해서, tunnel 생성 요청을 수락/거절할지 결정하는 데 그 정보를 일부로 활용하는 거죠? 14:28 <jrandom> 헤헷 14:30 <jrandom> 좋아요, 테스트넷 상태와 관련해 더 있을까요? 14:30 <Masterboy> 제 패러독스는요? 14:30 <Masterboy> :) 14:30 <jrandom> 업데이트 포함 0.3.1.3을 목요일이나 금요일쯤 내는 게 제 계획이에요 14:31 <jrandom> Masterboy: 당신 로그를 살펴볼 시간이 없었지만, 해결할게요 14:31 <_cervantes_> 2005년 금요일? 14:31 <_cervantes_> 좋네요 14:31 <Masterboy> k 14:31 <jrandom> 좋아요, 2) SAM으로 넘어가죠 14:31 <Masterboy> 이제 누가 오래된 router를 돌리는지 알겠군요.. 14:32 * jrandom 우리의 대담한 SAM.pm 개발자에게 마이크를 넘긴다 14:33 <jrandom> (그게 당신이에요, BrianR :) 14:33 <BrianR> 잠깐만요.. :) 14:33 * duck 환호한다 14:33 <jrandom> 그 사이에 dm이나 firerabbit 있나요? 14:33 -!- Irssi: #i2p: 총 26명 닉 [op 0, halfop 0, voice 0, 일반 26] 14:33 * jrandom /names 를 확인한다, 없음. 어쩔 수. 14:33 <jrandom> (그럼 .net/C# SAM lib 업데이트는 없겠네요) 14:34 <duck> .py 쪽은 아직 최신인가요? 14:34 <duck> 아니면 SAM 개선으로 더는 쓰지 않게 됐나요 14:34 <jrandom> 잘 모르겠어요 14:34 <BrianR> 좋아요. 돌아왔습니다. 14:34 <Nightblade> 제 C 라이브러리는 작동하는 것 같아요... 다만 그걸 쓰는 애플리케이션은 아직 안 썼습니다 14:34 <jrandom> 좋아요 nightblade! 14:35 <Nightblade> 여기서 Windows에서 GTK+/C 프로그래밍 해보신 분 있나요? 14:35 <human> duck: 버전 관리를 지원하려면 클라이언트 lib에 작은 변경이 필요해요 14:35 <_cervantes_> "hello world"? 14:35 <human> duck: 나머지는 문제 없이 작동할 거예요 14:35 * jrandom SAM 테스트로는 tftp 같은 datagram이 제격이라고 제안 :) 14:35 <Nightblade> 음, 뭐든지요... GTK가 Windows에서 잘 작동하나요.....? 14:35 <jrandom> (아니면 datagram이나 raw 대신 SAM streaming도 좋고요) 14:36 <jrandom> 좋아요 BrianR - .pm이랑 samcat은 어떻게 되고 있나요? 14:36 <BrianR> Net::SAM은 CVS에 있지만 대체로 동작하지 않는 형태예요. 14:36 <BrianR> 주말 전까지 버그를 다 잡고 datagram과 raw가 동작하도록 하길 바랍니다. 14:37 <BrianR> streams에 깔끔한 OO 마감을 하려면 조금 더 작업이 필요해요. 14:37 <Nightblade> 아 맞다, datagram이나 raw는 건드리지 않았어요... 그냥 stream만 14:37 <Nightblade> 어차피 그게 제가 쓸 전부예요 14:37 <fvw> human: wxWindows를 생각해 보셨나요? 그런 용도에 꽤 유용해요(Windows용 GTK 타깃은 없다고 봐요) 14:37 <jrandom> 훌륭해요 BrianR 14:38 <BrianR> 아내가 저녁 먹으러 오라고 성화네요. myi2p 논의 시간에 돌아올 수도 있고 못 올 수도 있어요. 위협 모델과 몇 가지 단순 파일서버 자료를 208번 노드에 올려놨어요 14:38 <human> fvw: GTK Windows 클라이언트는 있어요(GIMP도 Windows에서 돌아가잖아요) 14:38 <jrandom> 좋아요 nightblade, 필요한 것부터 구현하는 게 최선이죠 14:38 <human> fvw: s/client/port/ 14:38 <jrandom> 헤헤, 알겠어요 BrianR, 고마워요 14:38 <fvw> human: 제가 말한 건 wxWindows의 GTK Windows 타깃이에요(그걸 쓰라고 제안했죠) 14:38 * fvw BrianR에게 손을 흔든다. 맛있게 드세요. 14:38 <human> fvw: 아... 음, 저는 vxWidgets(vxWindows의 새 이름 :-)는 잘 몰라요 14:39 <human> fvw: 그런데 GTK+ 얘기한 건 제가 아니라 Nightblade였어요 :-) 14:40 <fvw> 앗, 제가 헷갈렸네요, 무시하세요. 14:40 <Nightblade> 저는 C++보다는 C에 더 익숙해요 14:40 <Nightblade> 제가 알기로는 GTK가 유일한 크로스플랫폼 C GUI 라이브러리예요 14:40 <Nightblade> 그렇다고 GTK를 특별히 좋아한다는 건 아니고요 14:40 <fvw> 상관없어요, wxWindows는 C에서도 쉽게 접근할 수 있어요. 14:40 <Nightblade> 흠 14:40 <Nightblade> 그럼 저도 한번 살펴볼게요 14:40 <Nightblade> C++를 알긴 하지만, 그걸로 큰 프로그램을 써본 적은 없어요 14:41 * fvw도 C++ 코더는 아니지만, 얼마 전 운송 회사에서 꽤 큰 트랜잭션 뷰어를 C++로 문제 없이 구성했어요. 14:42 <Nightblade> wxWindows가 Windows 포트는 더 성숙했을 거예요 14:42 <Nightblade> GTK보다요 14:42 <fvw> 아마 그럴 거예요. 14:43 <Nightblade> (좋아요 회의 계속하죠) 헤헷 14:43 <jrandom> :) 14:43 <jrandom> 좋아요, 3) 로드맵 업데이트로 넘어가죠 14:44 * jrandom 지난 한 달 동안 http://www.i2p.net/roadmap 업데이트를 소홀히 했습니다 14:44 <jrandom> 하지만 지금은 최신으로 되돌렸어요 14:44 <jrandom> 안타깝지만 다음 주에는 0.4를 분명히 못 냅니다 14:44 <duck> (1.1, 2.0, 3.0도 최신인가요?) 14:45 <jrandom> 예 14:45 * Masterboy 읽어봤고 좋네요 - 서두를 필요 없어요, 급한 불은 아니죠.. 14:46 <duck> 누군가 위키피디아/infoanarchy도 업데이트해야겠네요 :) 14:46 <jrandom> 아, 0.4에서 "SAM bridge and client libraries implemented and tested" 는 아마 빼야겠어요 14:46 <jrandom> 헤헷 맞아요, 그래서 예전에 iA가 위키 페이지를 그대로 베껴 갔을 때 !thwapped 했죠 14:46 <jrandom> (내용을 복사하지 말고 /roadmap을 가리키기만 해야죠) 14:47 <Masterboy> SAM은 끝났나요? 14:47 <jrandom> 기능적으로는 맞아요, 다만 추가 클라이언트 라이브러리 작업은 진행 중입니다 14:47 <jrandom> s/are/is/ 14:48 <jrandom> 좋아요, 로드맵에 대한 질문/우려가 더 없으면 4) MyI2P로 넘어가죠 14:50 <jrandom> 제가 직접 myi2p 작업은 중단했지만, 이 작업에 현상금을 걸었습니다 - http://www.i2p.net/node/view/216 14:50 <jrandom> 그 말은 요구사항을 제대로 정의해야 한다는 뜻이고, 무엇이 요구사항이어야 하는지에 대해 약간의 논쟁이 있었어요 14:51 <Masterboy> 친구에게 참여해보라 했더니 일이 너무 많고 돈이 너무 적다네요;P 뭐 자본주의자라서요;) 14:51 <Masterboy> 뭐, 제가 코딩하겠다고 하긴 했죠.. 14:52 <jrandom> 코딩은 언제나 환영이에요 :) 14:53 <jrandom> 하지만 현재 남아 있는 아키텍처적 핵심 질문은, 자신의 i2p router / myi2p 노드를 항상 돌릴 수 없는 사람들을 어떻게 다룰지예요 14:53 <Nightblade> 신뢰할 수 있는 I2P ISP가 있으면 되죠 14:53 <jrandom> 두 가지 제안이 있어요. 호스팅 서비스 제공자를 쓰거나, 시스템을 분리해 분산 백킹 스토어를 쓰는 것이죠 14:54 <_cervantes_> 후자가 장기적으로 이상적인 해법이고요 14:54 <_cervantes_> *latter 14:54 <duck> (그리고 또 다른 현상금) 14:55 <_cervantes_> 아니면 웹 캐시 프록시 서비스... 14:55 <jrandom> 맞아요 - 호스팅 서비스 제공자(또는 로컬로 돌리는 노드)로 가더라도, DHT/기타가 준비되면 점점 더 많은 콘텐츠를 DHT로 밀어 넣을 수 있죠 14:55 <jrandom> _cervantes_: 그게 본질적으로 분산 백킹 스토어 - 신뢰할 수 없는 데이터 캐시예요 14:57 <deer> * Masterboy bogobot이 어디 있나 궁금해한다 14:57 <jrandom> 어려운 부분은 필요한 접근 제어 기능을 갖추는 거예요 - 신뢰할 수 없는 데이터 캐시 / 분산 백킹 스토어에서는 ACL이 본질적으로 암호화가 되거든요 14:57 <jrandom> 그런데 이 논의에 대한 "사이드 채널"로 익명의 사람이 제기한 세 가지 포인트가 있어요 @ http://www.i2p.net/node/view/215#comment-105 14:57 <_cervantes_> 그리고 서명된 콘텐츠 14:58 <jrandom> 맞아요, 두 방식 모두 서명된 콘텐츠가 필요해요 15:00 <_cervantes_> 여기서 hypercubus의 모델이 의미가 있어요...하지만 결코 "빠른" 해법은 아니죠 15:00 <jrandom> 어젯밤 irc에서의 논의로는, 'LiveJournal 위협 모델'에 초점을 맞췄어요 - LJ 사용자가 신경 쓰는 공격과 그렇지 않은 것들 15:01 <wilde> 먼저 할 일은, 기본 MyI2P를 우선 구현하는 거죠 15:02 <jrandom> 맞아요, 그리고 기본 myi2p를 구현하려면 배포 아키텍처를 알아야 해요 15:03 <jrandom> 자신의 노드를 돌릴 수 없는 사용자의 LJ 위협 모델을 기준으로 하면, 신뢰할 수 없는 데이터 캐시 경로로 갈 필요는 없다고 봐요 15:03 <jrandom> 그리고 누군가가 LJ의 위협 모델만 필요하다면 왜 myi2p를 쓸까요? 익명성이 있으니까요 15:04 <jrandom> 이상적인 시스템을 향해 계속 나아갈 수도 있지만, 수확 체감의 법칙이 있죠 15:04 -!- Irssi: #i2p: 총 24명 닉 [op 0, halfop 0, voice 0, 일반 24] 15:05 <jrandom> 그래서 저는 현 방향대로 현상금을 유지하는 쪽으로 기울었어요 - 기본 시스템을 내놓은 뒤에 대안을 추가할 수 있으니까요 15:05 -!- duck_ 은 이제 duck으로 변경되었습니다 15:06 <jrandom> 아무튼, 4) MyI2P에 대해 제가 말할 건 여기까지예요, 더 언급할 게 있으면 말씀하세요 15:06 <jrandom> 없으면 5) ???로 넘어가죠 15:07 <_cervantes_> 흠 의사봉이 필요하겠네요 :) 15:07 <jrandom> 회의 기록에 morph.i2p의 새 eepsite를 적는 걸 잊었네요, 그리고 nickster.i2p에는 이제 public fproxy가 열려 있어요! 15:08 <jrandom> (그리고 sungo.i2p는 웹캠을 올려서 돌리고 있어요 :) 15:08 <_cervantes_> 헤헷... 15:08 <_cervantes_> i2pr0n 15:08 <jrandom> 다른 분들 더 말씀하실 거 있나요? 15:10 <jrandom> 없다면, 이제 70분이 되겠네요 15:10 <deer> <Masterboy> 아니요 15:10 * jrandom 마무리한다 15:10 * jrandom 회의를 *baf*하며 닫는다