간단 요약
참석: ant, aum, bla, cervantes, detonate, duck, fedo, frosk, jrandom, legion, maestro^, mancom, named, postman, Ragnarok, septu_ssh
회의 기록
13:06 <@jrandom> 0) 안녕하세요 13:06 <@jrandom> 1) 0.5.0.2 13:06 <@jrandom> 2) mail.i2p 업데이트 13:06 <@jrandom> 3) i2p-bt 업데이트 13:06 <legion> 그러면 irc 서버와 관련된 건가요? 13:06 <@jrandom> 4) ??? 13:06 <@jrandom> 0) 안녕하세요 13:06 <@jrandom> 주간 상태 노트 올라왔습니다 @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html 13:07 <fedo> 안녕 13:07 <+postman> 안녕 13:07 <frosk> 좋은 날 13:07 <@jrandom> legion: 아니요, i2p 버그와 관련된 거고, 작업 중입니다 13:07 <bla> 안녕 13:07 <legion> 오케이 13:07 <@jrandom> 작업 중인 버그 얘기 나온 김에, 1) 0.5.0.2 로 바로 가죠 :) 13:07 <cervantes> 'lo 13:07 <cervantes> -- 연결 끊김 13:08 <@jrandom> ㅎㅎ 13:08 <ant> <mihi> 모두 안녕하세요 13:08 <@jrandom> 0.5.0.2가 나왔습니다. 가끔 irc 연결이 지연될 수 있지만, 금방 복구될 거예요 ;) 13:08 <@jrandom> 오, 안녕 mihi 13:09 <cervantes> 안녕 mihi 13:09 <@jrandom> 상태 노트에는 현재 상황과 가장 시급한 우선순위가 대략적으로 정리되어 있습니다 13:10 <@jrandom> 제가 추적 중인 무서운 현상은 http://localhost:7657/oldstats.jsp#router.invalidMessageTime 에서 볼 수 있어요 13:10 <bla> 제 경우, 0.5.0.2가 0.5.0.1에 비해 신뢰성이 이미 _엄청나게_ 개선되었다고 말할 수 있습니다. 목적지에 연결할 수 없다는 오류가 거의 더는 발생하지 않아요 13:10 <@jrandom> 그 숫자들은 매우매우 작아야 하는데, 안타깝게도 그렇지 않네요 13:10 <@jrandom> 좋네요, bla 13:11 <@jrandom> 맞아요, 0.5.0.2는 확실히 개선됐습니다. 모두 가능한 한 빨리 업그레이드하세요 13:11 <bla> 여기는 지난 10분 동안 375,932.22.... 13:11 <@jrandom> 음, 특정 값 자체가 문제는 아니고, 빈도가 문제예요 13:11 <@jrandom> (주기당 이벤트 수) 13:12 <@jrandom> 그 메시지들은 아마 0.5 router들, 그리고 일부는 0.5.0.1 router들 때문일 가능성이 큽니다. 그래서 모두 최대한 빨리 업그레이드하길 바라는 거죠 13:12 <@jrandom> 물론 다른 원인일 수도 있으니, 그 가능성부터 배제하고 싶어요 13:12 <bla> jrandom: 여긴 시간당 약 200개 정도 나와요 13:13 <@jrandom> bla: 저는 이번 시간대에 현재 93개이고, 피크 때는 훨씬 더 많았어요(수천 개) 13:13 <@jrandom> 어쨌든 이 특정 통계는 netdb에 공개됩니다 13:13 <bla> jrandom: 0.5-0를 네트워크에서 소프트웨어적으로 제외하는 건 어떤가요? 13:14 <@jrandom> 그래서 서로 돌아다니며 다른 사람들이 어떤 값을 갖고 있는지 볼 수 있죠 ;) 13:14 <@duck> 309,854.24 피크 5,473,314.59 13:15 <@duck> 다른 걸 붙여넣었네, 그치 13:15 <@jrandom> bla: 확실히. 0.5.0.2 rev에 0.5.0.1과 0.5에는 없는 forward compatibility(상위 호환성) 코드를 조금 추가했어요 13:16 <@jrandom> duck: 이벤트 개수가 정수가 아니긴 힘들죠 ;) 13:16 <bla> jrandom: 좋네요. 최소한 통제된 방식으로 'invalid message가 0.5-0 때문'이라는 가설을 검증할 수 있으니까요 13:16 <@jrandom> bla: 맞아요, 그래도 그 전에 사람들이 업데이트해주면 더 좋겠죠 ;) 13:17 <@jrandom> (집에서 보고 계신 분들을 위해: http://www.i2p.net/download 가 친구입니다 ;) 13:17 <maestro^> jr: 그 숫자들이 router.invalidMessageTime 편차를 ms 단위로 나타낸 건가요? 13:17 <@jrandom> maestro^: 네 13:18 <@jrandom> (즉, 정말 말도 안 되게 기울어진 값들) 13:18 <legion> 간단한 네트워크 보고서입니다 [버전|노드 수][0.5|6][0.5.0.1|39][0.5.0.2|107] 13:18 <@jrandom> 네, 여러분 업데이트 정말 잘해주셨어요 13:18 <legion> 그러니까 아직 0.5를 돌리는 사람이 몇 있고, 0.5.0.1을 돌리는 사람도 많군요 13:18 <maestro^> 그럼 어디에서 지연이 생기는지 짐작 가는 게 있나요? 13:18 <bla> jrandom: Freenet은 각 릴리스에 통신할 최소 노드 버전을 지정하는 플래그가 있어요. 새로운 forward-compat. 코드도 그런 건가요? 13:19 <@jrandom> maestro^: 0.5와 0.5.0.1 사용자가 지연되는 이유에 대해서는 여러 가지 가설이 있죠. 13:19 <@jrandom> bla: 비슷해요 13:19 <maestro^> 아니면 노드의 시계 드리프트 때문인가요? 13:20 <@jrandom> maestro^: clock skew(시간 오차), 일부 직렬화 버그, 100% CPU 버그 13:20 <@jrandom> 좋아요, 지금 제 주된 초점은 메시지 신뢰성을 다시 끌어올리는 데 있습니다 13:21 <@jrandom> 0.5.0.2에 대해 질문/의견/우려 사항 있으신가요? 13:21 <ant> * mihi는 여기 하드에 0.4.2.5 router가 있는데 12월 22일 이후로 시작하지 않았고... 지우는 게 낫겠다고 생각 중... 13:21 <@jrandom> ㅎㅎ 13:21 <@jrandom> 네, 그건 많은 router들과는 통신 못 할 거예요 ;) 13:21 * postman이 마지막 0.4 설치본의 백업 사본을 갖고 있어요 :) 13:21 <ant> <mihi> 저한테는 업그레이드할지 삭제할지가 질문이겠네요. 13:22 <@jrandom> 삭제 13:22 <@jrandom> (destination 키들은 백업하세요) 13:22 <@jrandom> 이제 0.5 이전 버전에서 업그레이드하는 절차는 없습니다 13:22 <legion> 0.5.0.2 이상에서만 접속을 허용하는 0.5.0.2-1 같은 업데이트를 하나 더 내는 건 어떨까요? 13:22 <@jrandom> legion: 그건 네트워크를 분할시켜요 13:22 <@jrandom> 사람들은 그냥 업그레이드해야 해요. 13:23 <@jrandom> (그리고 그렇지 않은 사람들에 대해서는 우회 처리를 해야죠) 13:24 <legion> 네, 구버전 노드를 돌리는 사람들이 업데이트할 때까지요 ;) 13:24 <@jrandom> 네트워크를 분할하면 그들만이 아니라 우리 모두에게 해가 됩니다 13:25 <legion> router 콘솔에 업데이트 알림 같은 걸 넣어서 자신이 구버전을 돌리고 있다는 걸 알려주는 건 어떨까요? 13:25 <@jrandom> 네, 그거 꽤 멋질 거예요 13:25 <@jrandom> 가능하면 업데이트 기능과도 연동되면 좋겠네요 13:26 <legion> 네, 알아요, 분할은 안 좋죠... 13:26 <@jrandom> smeghead가 그 핵심 구성 요소 몇 가지를 작업 중인데, 알림/다운로드까지 포함되는지는 잘 모르겠네요 13:26 <@jrandom> (그래서 그 작업을 도와보고 싶은 분은 연락 주세요!) 13:27 <@jrandom> 좋아요, 2) mail.i2p 업데이트로 넘어가죠 13:27 <@jrandom> postman: 핑 13:27 <+postman> 네 13:27 <bla> jrandom: 제 기억이 맞다면 smeghead가 서명 관련 작업을 하고 있었어요(업데이트 알림을 받았을 때, 최소한 그게 진짜고 피싱/스파이웨어/잡것이 아니라는 걸 알 수 있도록) 13:28 * postman이 마이크를 넘겨받습니다 13:28 <legion> 흠, i2p를 통해 업데이트를 내려받고 노드가 업데이트만 받으면 우아한 재시작을 하는 자동 업데이트 기능이 내장되어 있으면 어떨까요. 13:28 <@jrandom> 맞아요 bla 13:28 <ant> <Gatak> 아, 참고로. 포트를 열 수 없어도 nat 뒤에서 I2P가 작동하나요? 13:28 <@jrandom> Gatak: 아직은요. 일부는 0.6에서 가능해질 거고, 다른 사람들은 2.0에서요 13:29 <@jrandom> legion: 패치 환영합니다 13:29 <ant> <Gatak> 2.0이라니, 그건 한참 먼 미래네요 =) 13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;) 13:29 <+postman> 어, 지금 시작할까요? 13:29 <aum> 모두 좋은 아침 13:30 <@jrandom> 마이크는 전부 postman 겁니다(미안 ;) 13:30 <@jrandom> 'lo aum, 회의에 맞춰 왔네요 13:30 <@jrandom> (앗! /me 다시 입 다문다) 13:30 <cervantes> Gatek: http://www.i2p.net/roadmap 13:30 <+postman> 먼저, postman.i2p에 등록된 계정이 벌써 300개를 달성했다는 말씀을 드리고 싶어요 13:30 <@jrandom> 와! 13:30 <+postman> '인터넷'과 주고받는 메일 수가 꾸준히 늘고 있고, 우리가 더 나아가야 한다는 걸 다시 한번 보여줍니다 13:31 <cervantes> *꺄아아* 13:31 <+postman> 몇 주 전 jr와 이야기한 후 v2mail을 I2P 1.0과 함께 릴리스하기로 합의했습니다 13:31 <+postman> 현재 상태: 모든 노드에서 실행되도록 설계된 Java 기반 SMTP 프록시는 완료되었습니다 13:31 <@jrandom> 좋네요! 13:32 <+postman> Java 기반 POP3 프록시는 80%까지 진행됐고, maildir(메일 디렉토리 형식) 엔진만 빠져 있습니다 13:32 <+postman> 웹 매니저가 있을 예정이며 아직 많은 손질이 필요합니다(15% 완료) 13:32 <+postman> 노드 간 통신은 40%입니다 - HTTP/XML로 일부 데이터 레코드 교환을 테스트했습니다 13:33 <+postman> 꽤 잘 작동하고, 속도도 빠른 편입니다 13:33 <+postman> 중계 노드가 장애가 나거나 며칠 동안 꺼져 있어도, 다시 온라인이 되면 몇 분 안에 동기화됩니다 13:33 <@jrandom> 멋지네요 13:33 <+postman> 꽤 잘 진행 중이라고 생각합니다 13:34 <+postman> 한 가지 주목할 점이 있어요 13:34 <bla> postman: 멋진 작업이네요! 질문 하나요: 많은 노드가 포트 25에서 데이터를 받거나 보낼 수 없어요(직접은 어쨌든요). 노드 소유자가 이를 지정할 수 있나요(아니면 자동으로 감지되나요)? 13:34 <cervantes> 멋져요 13:34 <+postman> bla: 나중에요 13:34 <+postman> v2mail에서는 로컬에서 실행되는 웹앱이 있을 거예요 13:34 <+postman> 이걸로 로컬 프록시를 관리할 수 있고, 'relayaccount'도 신청할 수 있습니다 13:35 <+postman> 이 relayaccount는 이후 여러분의 주소/도메인을 중계(리레이)에 연동하는 데 사용됩니다 13:35 <+postman> 리레이들이 그 정보를 자동으로 동기화합니다 13:35 <@jrandom> 멋져요 13:35 <+postman> 주소록/공개키 같은 기능도 LOCAL 인터페이스로 동작합니다 13:36 <+postman> 즉, 메일 관련 작업을 모두 처리할 수 있는 단일 중앙 매니저를 두는 것이 아이디어입니다 13:36 <+postman> 관련 데이터는 리레이 중 하나로 전송된 뒤 리레이들 사이에서 동기화됩니다 13:36 <+postman> 그리고 이 웹 기반 매니저는 바로 여러분의 노드에서 실행됩니다 13:37 <+postman> 여러분의 노드가 온라인일 때, 리레이가 여러분의 destination/도메인/주소에 대기 중인 메일을 전달합니다 13:37 <+postman> 로컬 SMTP 프록시로 전달됩니다 13:37 <+postman> ETRN으로 전체 과정을 트리거할 수도 있어요 :) 13:37 <aum> 다시 안녕하세요 13:37 <aum> 괜찮다면 이 회의에서 토론할 주제를 하나 제안하고 싶습니다 13:37 <+postman> 미래 계획은 대략 이 정도예요 여러분 :) 13:37 <+postman> . 13:38 <@jrandom> 끝내주네요, postman 13:38 * postman이 마이크를 돌려줍니다 13:38 <@jrandom> aum: 좋아요, 4)에서 시간 좀 뺄게요 13:38 <+postman> 네, 완전 신나요 :) 13:38 <@jrandom> postman: 그럼 일반 사용자의 경우, SMTP 프록시가 로컬 maildir을 가지고, POP3 프록시가 읽기 등을 담당하는 거죠? 13:39 <+postman> 네, SMTP 프록시에 MDA(메일 배달 에이전트)가 있어요 13:39 <+postman> 그리고 로컬 maildir들로 메일을 배달합니다 13:39 <+postman> 심지어 여러 계정/사용자를 로컬에 생성할 수도 있어요 13:39 <cervantes> postman: 리레이들이 할당량 같은 것을 추적하고 그런 정보를 서로 전파하나요? 13:39 <+postman> 그리고 여러분의 도메인의 계정에 매핑됩니다 13:39 <+postman> cervantes: 네, 그렇게 할 거예요 13:39 <septu_ssh> 죄송한데, 새로운 모델에서 결제/스팸 방지 메커니즘에 대해 postman에게 물어봐도 될까요? 13:40 <+postman> septu_ssh: 웹페이지에 있는 문서들 읽어보셨나요? 13:40 <+postman> cervantes: 완전 실시간은 아니에요 13:40 <+postman> cervantes: 하지만 할당량 정보 교환이 몇 분 간격으로 업데이트되는 건 괜찮다고 봐요 13:40 <septu_ssh> 읽기 대기열에 있어요 :/ 13:40 <septu_ssh> 하지만 문서화돼 있다면 괜찮습니다 13:40 <cervantes> postman: 네 그럴 거라고 생각했어요 13:41 <+postman> septu_ssh: www.postman.i2p/inout.html 13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html 13:41 <+postman> cervantes: 이건 크게 문제 될 건 없어요 - 할당량은 상식적인 한도니까요 13:41 <cervantes> postman: 누군가가 nrelays * quota만큼의 수신자에게 보낼 수 있다고 해도 나쁜 일은 아니죠 13:41 * septu_ssh is bungle 13:41 <+postman> cervantes: 맞아요 13:42 <+postman> 목표는 누군가가 서비스를 심각하게 남용하는 것을 막는 것입니다 13:42 <+postman> 테스트에서는 리레이 3개로도 정말 빨랐어요 13:42 <@jrandom> postman: 이게, 여러분 노드를 경유하지 않고 로컬 SMTP 릴레이가 다른 사람의 SMTP 릴레이와 직접 통신하는 것도 지원하나요? 13:42 <+postman> cervantes: 10초 안에 동기화되었어요 :) 13:43 <@jrandom> (아니면 그건 나중에 할 일인가요) 13:43 <+postman> jrandom: i2p 메일 리레이는 여러 사람들이 운영할 것이고, 메일 라우팅의 우선 목적지입니다 13:43 <cervantes> postman: 발송 대기열에 지수형 지연을 도입할 수도 있겠네요 13:43 <cervantes> 문제가 된다면요 13:43 <+postman> jrandom: 그래서 다른 destination으로 직접 보내는 게 특정 상황에서는 유용할 수 있죠 13:44 <@jrandom> 맞지만, 다른 상황에서는 위험하죠 13:44 <cervantes> 그러니까 메일을 많이 보낼수록 대기열에 머무는 시간이 늘어나게 해서... 리레이가 따라잡을 시간을 주는 거죠 13:44 <+postman> jrandom: 하지만 노드 소유자가 자신의 IMIO destination을 공개하면 통제 없이 스팸을 받을 수도 있어요 :) 13:44 <@jrandom> 맞아요 13:44 <@jrandom> 한편, i2p 메일 리레이가 적대적이라면 마찬가지죠 13:45 <+postman> jrandom: 맞아요, WOT(웹 오브 트러스트) 같은 구성입니다 13:45 <@jrandom> </tinFoil> 13:45 <+postman> jrandom: 리레이 운영자가 여러분 주소에 대해 할당량 0을 배포하는 것을 막을 수는 없죠 13:45 <@jrandom> 'ㅇㅋ 좋아요. 네, 지금은 그걸로 걱정할 필요 없어요 13:45 <+postman> :) 13:46 <+postman> 좋아요 13:46 <+postman> . 13:46 <@jrandom> 좋아요, 업데이트 고마워요. 정말 흥미진진한 내용이네요 13:46 <@jrandom> 좋아요, 3) i2p-bt 업데이트로 넘어가죠 13:46 <@jrandom> duck: 핑 13:46 <@duck> 안녕 13:47 <@duck> 어제 BitTorrent 4.0.0이 릴리스되었습니다 13:47 <ant> <dm> 독일어 같네요 13:47 <@duck> 우리가 0.2 작업을 시작하기 전에 거의 기다리던 것이죠 13:47 <@duck> 작업 목록/할 일 목록을 썼어요: http://pastebin.ca/raw/7037 13:47 <@duck> (죄송, 제 웹이 지금 내려가 있어요) 13:48 <@jrandom> 좋네요 13:48 <legion> 0.2 일정은 어느 정도로 보고 있나요? 13:48 <@duck> 목표는 4주였어요 13:49 <legion> 멋지네요 13:49 <@duck> 보시다시피 RawServer(i2p와 통신하는 부분)가 가장 큰 작업입니다 13:50 <@duck> . 13:50 <@duck> 간단한 설문: 13:50 <legion> 네, 잘 알고 있어요 :) 13:50 <@duck> i2p-bt 포크를 만들 계획이 있는 사람? 13:50 <@jrandom> 좋네요, 사람들이 도울 수 있는 게 있을까요? 13:50 <@jrandom> ㅎㅎ 13:51 <ant> <dm> 나 13:51 * jrandom이 숟가락을 집어 든다 13:51 <ant> <dm> 나 도울 의향 잇음 13:51 <legion> 나 13:51 <ant> <dm> 나 게이야 13:51 <legion> 저는 포크 작업 중이에요 13:52 <@duck> 좋아요, 그럼 누구를 진지하게 안 보면 되는지 알겠네요. 13:52 <@duck> 정말로, 그건 좀 어리석다고 봐요; 자원을 모으면 훨씬 더 멀리 갈 수 있을 겁니다 13:53 <@jrandom> 아니면 더 나은 방법이 있다면, duck을 설득해서 그 방식으로 작업하도록 할 수도 있겠죠? 13:53 <named> qbasic으로 포크를 쓰려고 합니다, 제발 진지하게 대해주세요. 13:53 <@duck> 과정을 더 개방적으로 해보겠습니다. 그러면 다른 사람들이 뭐가 계획되어 있는지 등을 볼 수 있겠죠 13:53 <ant> <dm> 너의 개방성은 우리를 흔들지 못해. 포크! 포크! 포크! 포크! 13:53 <@duck> 다른 제안이 있으면요 13:54 <ant> * dm이 legion을 어깨 위로 들어 올린다. 13:54 <legion> 흠, 맞을지도요. 다만 제가 하는 일로는, 제가 메인 i2p-bt 개발 프로세스를 오염시키는 걸 원하지 않을 것 같네요 ;) 13:54 <ant> <dm> 포크! 포크! 포크! 포크! 13:54 <@jrandom> legion: duck이 지원하고 싶지 않을 만한 일을 뭘 하고 있나요? 13:55 <@duck> legion: 축하해요, 'i2p bittorrent'로 구글링하면 'Windows I2P Bittorrent Version 1.0' 발표가 1위네요 13:55 <@jrandom> 세상에 13:56 <bla> jrandom: 네? 13:56 <+postman> jrandom: 그래요, 곧 이 네트워크를 탈탈 털어버릴 거예요 :) 13:56 <bla> ;) 13:56 <named> 1.0? 젠장, 난 0.1.8 쓰고 있는데! 13:56 <Ragnarok> 어이쿠 13:57 <legion> 세상에, 정말요?! 믿을 수가 없네요... 미쳤다. 13:57 <@duck> 어쨌든, 여기에 대해 새로 말할 건 별로 없다고 봐요 13:57 <legion> 제 1.0 릴리스는 0.1.8을 기반으로 했어요. 0.1.8을 돌리고 있다면 괜찮습니다. 13:58 <@jrandom> (그리고 1.0 릴리스는 아무도 검토하지 않은 .exe입니다. YMMV) 13:58 <legion> 이름과 버전 넘버링을 잘못했어요. 다시 한번 죄송합니다. 13:58 <ant> <dm> 1.0>> 0.1.8 13:58 <ant> <dm> 일주일 내내 13:59 <@duck> 약간 관련 있는 내용: 13:59 <@jrandom> 좋아요, 3) i2p-bt에 더 있을까요, 아니면 4) ???로 넘어갈까요? 13:59 <+postman> legion: 소스 코드는 언제 내려받을 수 있나요? 13:59 <frosk> "I2P-BT 0.1.8은 지금까지 꽤 잘 작동하고 안정적입니다. 개인적으로 I2P-BT 1.0으로 업데이트할 이유를 못 보겠네요" (포럼에서 봄) 13:59 * jrandom 한숨 13:59 <@duck> 지난달 Bram Cohen이 어떤 대학에서 BitTorrent에 대해 강연을 했습니다 14:00 <@duck> 꽤 흥미롭습니다: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent 14:00 <@duck> (대형 P2P 프로그램에 대한 교훈과 BitTorrent 세부 사항 일부 설명이 있습니다) 14:00 <@duck> . 14:01 <@jrandom> 맞아요 14:01 <@duck> postman: legion이 소스 코드를 일부 공개했어요 14:01 <ant> <dm> 그가 BT 발명자인가요? 14:01 <@duck> 하지만 smeghead 말로는 .exe와 동일하지 않다고 하네요 14:01 <@jrandom> dm: 네 14:01 <legion> http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2 여기에서 개발자용 소스를 내려받을 수 있습니다 14:02 <+postman> ㅇㅋ, 확인해볼게요 14:02 <ant> <dm> 그 exe가 그 소스를 그대로 컴파일한 건가요? 14:03 <legion> 사실 1.0 소스는 smeghead의 패치를 적용한 0.1.8을 컴파일하고 보기 좋게 패키징한 것뿐이에요. 14:04 * cervantes가 4)???로 걸어가서 모두가 따라오길 기다린다 14:04 <ant> <dm> 질문은 아직 답이 없군요 14:04 <ant> <dm> Legion, 자네, code red를 명령했나 안 했나??? 14:04 <@jrandom> *콜록* 14:04 <legion> 본론으로 돌아가죠. 제 BT 클라이언트 논의는 #itorrent로 옮겼어요 14:05 <@jrandom> 좋아요, 4) ??? 14:05 <@jrandom> 다른 안건 있으신가요? 14:05 <@jrandom> aum: 얘기할 게 있었죠? 14:06 <ant> <dm> stasher 돌아왔나? 14:06 <legion> 0.5.0.2에서 트래픽이 많은 기간에 이상한 동작이 보이네요... 14:06 <aum> 네 14:06 <aum> tunnel 자동 생성/관리 문제를 제기하고 싶습니다 14:07 <ant> <dm> 계속하세요 14:07 <+detonate> Windows의 systray 관련 부분에서 NullPointerException이 있네요, 방금 발견했어요 14:07 <aum> 지금 웹 콘솔에서 사람이 수동으로 tunnel을 생성/삭제/관리할 수 있게 된 건 1337하죠 14:07 <@jrandom> detonate: 그거 bugzilla에 올려줄 수 있을까요? 14:07 <aum> 하지만 프로그램도 tunnel을 관리할 수 있는 신뢰할 만하고 편리한 방법이 항상 있어야 한다고 강하게 믿습니다 14:08 <@jrandom> aum: 이견 없습니다. 필요하고, 제공할 겁니다. 다만 아직은 아니에요. 14:08 <ant> <dm> SAM으로 그걸 할 수는 없나요? 14:08 <aum> 최근 i2p로 돌아와 보니 pysam 라이브러리가 더는 작동하지 않더군요 14:08 <septu_ssh> aum 다음으로 짧은 질문 하나 있어요 14:08 <aum> 좀 실망이었습니다 14:08 <@jrandom> SAM 프로토콜은 동작하고, pysam은 동작하지 않습니다 14:08 <Ragnarok> 그게 예전에라도 작동했나요? 14:09 <aum> 맞아요 14:09 <aum> pysam은 예전에 아주 잘 작동했어요 14:09 <legion> 그런 기간에는 제 노드가 참여하는 tunnel이 1000개 이상이고, 수 초의 랙과 지연이 발생합니다. 14:09 <@jrandom> legion: 네, tunnel 수가 많은 건 예전 빌드들 때문이에요 14:09 <cervantes> 아 mymodesty 14:09 <cervantes> 음 pymodesty 14:09 <aum> 지금 'i2ptunnel.py'라는 모듈을 작성 중인데, tunnel 관리를 쉽게 해주는 클래스를 정의합니다 14:10 <legion> 그럼 예전 빌드에 연결하지 않으면 네트워킹이 훨씬 매끄러울까요? 14:10 <@jrandom> 'ㅋ, 그게 장기적인 올바른 해법인지는 모르겠지만, 지금 당장 간극을 메우는 데 도움이 된다면 좋네요 14:10 <@jrandom> legion: 그 tunnel들이 문제는 아니에요 14:11 <aum> 뭐, 내부 메커니즘이 바뀌더라도 클래스 인터페이스는 유지될 수 있죠 14:11 <@jrandom> 'ㅋ 14:11 <legion> 아닌가요? 14:12 <legion> tunnel이 적을 때는 랙과 지연이 거의 없는데요... 14:12 <cervantes> legion: 미안해요 aum이 질문 몇 개만 제기하고 있으니 잠깐만 기다려 주세요 14:12 <legion> 그냥 좀 이상하게 느껴져서요. 14:13 <legion> 오케이 14:13 <@jrandom> 과거에 성공적이었던 것을 고려해야 한다는 점이 걱정됩니다 - 웹 설정은 모두가 사용하니까 잘 작동하고 유지됩니다. 아마 지금 작업 중인 앱은 수동 tunnel 생성으로 먼저 동작하게 만드는 게 최선일 거예요. 그게 더 효율적일 겁니다 14:13 <@jrandom> 항상 i2ptunnel.py를 사용하는 무언가가 있어서, 그것을 스트레스 테스트하도록요 14:13 <aum> 우리가 교착 상태에 빠진 것 같네요 14:13 <+detonate> jrandom:물론이죠 14:14 <ant> <dm> 그럼 넘어가죠 14:14 <aum> 믿고 쓸 수 있는 tunnel 관리 API가 있기 전에는 제 앱 개발에 시간을 투자하고 싶지 않아요 14:14 <septu_ssh> \o. - 제안할 사항 하나요 14:14 <cervantes> 현실적으로, 다음 몇 달 안에 tunnel 인터페이스가 개편될 거라고는 상상하기 어려워요... 14:14 <@jrandom> 하지만 하나 추가하는 건 아주 쉽다는 걸 아시잖아요 14:14 <cervantes> 즉, 웹 인터페이스 자체가 그 API를 사용하면 유지보수 부담이 없죠 14:15 <named_> 웹 설정이 aum의 프로그램이 조작할 수 있는 어떤 API를 가질 수는 없을까요? 14:15 <@jrandom> named_: 네 14:16 <@jrandom> URL을 통해 안전하게 제어할 수 있게 뭔가를 추가하는 건 사소합니다만, 그걸 필요로 하는 게 있어야 의미가 있어요 14:16 <@jrandom> 그렇지 않으면 그냥 썩어버리겠죠 14:16 <aum> named_: 그게 괜찮겠네요. 그리고 설정에 하드코딩된 비밀번호를 클라이언트 프로그램이 터널 제어 필드와 함께 POST해야 하는 식이면 될 수 있겠어요 14:16 <cervantes> 개인적으로는 전체 tunnel 시스템을 완전히 개편하고 싶은데, 처음부터 tunnel 관리 인터페이스를 포함하면 별도의 인터페이스를 유지하는 추가 노력을 걱정할 필요가 없죠 14:17 <@jrandom> 맞아요, 프록시에는 손볼 게 많습니다. 저는 가능한 한 그걸 피하고 있었지만요 :) 14:17 <aum> SAM은 어떤 상황에서는 좋고, 다른 상황에서는 나쁩니다 14:17 <cervantes> 하지만 그건 조금 더 나중 일이고요... 14:17 <fedo> ( 14:18 <@jrandom> aum: 하지만 임시방편으로, 현재 가능한 세 가지 방법 중 하나를 그냥 사용할 수는 없나요? 14:18 <cervantes> 즉, 웹 인터페이스 자체가 그 API를 사용하면 유지보수 부담이 없죠 14:18 <@jrandom> 맞아요. 웹 인터페이스는 TunnelControllerGroup을 사용합니다 14:19 <aum> 표준 TCP 소켓에 크게 의존하는 기존 라이브러리를 사용하려고 하면 SAM 사용이 어려워집니다 14:19 <aum> jrandom: I2PTunnel CLI는 server tunnel을 여는 데 작동하지 않아서, 지금 TunnelControllerGroup을 사용하는 코드를 작성 중입니다 14:19 <@jrandom> aum: 기존 라이브러리는 신중히 감사를 해야 합니다. 예를 들어, gzip 유틸리티 자체가 민감한 데이터를 노출합니다 14:19 <aum> 지금 바로 코딩 중이에요 14:21 <@jrandom> CLI가 server tunnel에서는 분명 작동합니다. 하지만 그런 방식이 필요하다면 TunnelControllerGroup을 사용하는 게 바람직해요 14:21 <@jrandom> 좋아요, 다른 안건 있으신가요? 14:22 <septu_ssh> 제 질문은 hosts.txt의 분산 버전에 관한 것입니다. 현재 routerInfo에는 DHT 테이블이 사용되고 있는데, 이를 확장해서 DNS의 분산 버전으로 쓸 수는 없을까요? 그 DNS DHT에는 www.bla.i2p에서 eepsite SHA로의 매핑이 들어가고, 엔트리는 'I2P registrar'의 서명을 받는 식으로요... 의견? 반박? 14:22 <mancom> 로드맵 관련 질문: 0.6은 여전히 4월 예정인가요? 14:22 <@jrandom> septu_ssh: 라우팅이 아닌 데이터를 netDb에 넣는 건 제 시체를 넘고 가야 합니다 ;) 14:23 <septu_ssh> jrandom: 같은 DB가 아니에요 14:23 <septu_ssh> 다른 분산 DB요 14:23 <aum> jrandom: 제 버그 리포트 보셨나요? CLI 'server' 명령은 /작동하지 않습니다/ 14:23 <maestro^> septu_ssh: i2p registrar 같은 건 없어요 14:23 <@jrandom> septu_ssh: 네이밍에는 위험한 측면이 많고, 핵심적인 절충점들이 있습니다. ugha.i2p에서의 네이밍 논의를 보셨나요? 14:24 <@jrandom> septu_ssh: 아, I2P 위의 DHT를 사용해 엔트리를 분산시키는 건 확실히 가능합니다. 다만 그 이름들을 전역 엔트리로 취급하면 보안적이지 않을 겁니다 14:26 <@jrandom> aum: 몇 주 전까지 매일 사용했는데요, 제 답장 보셨나요? 14:26 <@jrandom> maestro^: 그게 계획입니다 14:26 <@jrandom> 어, mancom: 14:26 <cervantes> aum: 그 i2plist 메일에 대한 jr의 답장을 가지고 있는데, 아직 못 받으셨나요, 아니면 문제가 여전히 있나요? 14:26 <septu_ssh> 'registrar'를 제안하는 유일한 이유는, 그렇지 않으면 충돌이 발생할 수 있기 때문이에요 14:26 <@jrandom> septu_ssh: 충돌을 받아들이세요 :) 14:26 <@jrandom> 전역적으로 유일하고, 사람이 읽기 쉬우며, 분산되어 있고, 보안적인 네이밍은 존재하지 않습니다 14:27 <septu_ssh> host.txt를 수동으로 편집해도 그런 일이 생길 수 있지만, 문제는 똑같습니다 14:27 <@jrandom> 첫 번째 조건을 포기하면, 완벽해집니다 14:27 <aum> jrandom: 답장은 봤어요 - 그리고 제 cp에 streaming.jar이 /정말/ 있습니다 14:27 <septu_ssh> postman이 메일에 대해서는 중앙 노드를 운영하니, 네트워크 안에도 신뢰 요소가 있는 거죠. 누군가가 네임스페이스를 관리하는 registrar를 신뢰할 수도 있지 않나요? 14:27 <@jrandom> 좋네요, 그리고 아직도 그 스택트레이스가 나오나요 aum? 14:28 <aum> 네 14:28 <@jrandom> septu_ssh: postman은 postman의 outproxy/inproxy에 대해서만 중앙 요소로 동작합니다 14:28 * Ragnarok, 그 주소록 문서를 정말 써야겠네... 14:28 <aum> 이건 제가 CLI를 수동으로 실행해서 genkeys를 하고, genkeys가 생성한 privkeyfile을 사용해 'server'를 했을 때예요 14:28 <@jrandom> septu_ssh: 누가 네임스페이스를 관리하는 걸 신뢰하지 않을 겁니다. 검열 == 그 registrar에 압력을 가한다는 뜻이죠. 14:28 <maestro^> 모두가 사실 각자의 registrar예요 14:29 <maestro^> 여러분은 친구를 신뢰하고, 친구는 여러분을 신뢰하죠 14:29 <aum> 젠장, 오래된 클래스패스를 들고 왔네요 14:29 * aum 다시 테스트 14:30 <ant> <dm> 좋아, 내가 registrar 할게. 14:31 <ant> <dm> 가능한 한 공정하게 할게... 괜찮지? 14:31 <septu_ssh> 흠, 알겠어요. 그럼 속담대로 원점으로 돌아가야겠네요... 14:31 <@jrandom> septu_ssh: 검토하기 좋은 곳: http://zooko.com/distnames.html :) 14:32 <@jrandom> 모두가 그걸 원하지만, 사람들이 원하는 방식은 보안적이지 않습니다. 우리는 보안적인 해법이 있지만, 전역적 유일성을 포기합니다 14:33 <septu_ssh> 흠, 알겠어요 14:33 <@jrandom> 좋아요, 회의에서 더 다룰 안건 있으신가요? 14:33 <cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134 14:33 <aum> jrandom - 좋아요, 이제 CLI 'server'는 동작하지만, tunnel의 'job number'를 받지 못했어요 14:34 <@jrandom> 흠 그렇죠, 그건 계속 실행됩니다 14:34 <aum> 아, 'list'를 해야 job 번호를 얻는군요 14:36 <@jrandom> 좋아요, 더 없으면... 14:36 * jrandom 마무리 준비 14:36 * jrandom 회의를 *baf* 하고 닫습니다