I2P 개발자 회의 - 2005년 12월 06일

15:26 <jrandom> 0) 안녕하세요 15:26 <jrandom> 1) 0.6.1.7과 네트워크 상태 15:26 <jrandom> 2) 실험용 tunnel 실패 15:26 <jrandom> 3) SSU와 NAT 15:26 <jrandom> 4) Syndie 15:26 <jrandom> 5) ??? 15:26 <jrandom> 0) 안녕하세요 15:26 * jrandom 손을 흔든다 15:26 <jrandom> 주간 상태 노트를 http://dev.i2p.net/pipermail/i2p/2005-December/001237.html 에 올렸습니다 15:26 * ailouros 노트를 읽었다 15:27 * jrandom 제가 늦었으니, 여러분이 읽을 시간을 잠깐 드릴게요 :) 15:29 <jrandom> 좋아요, 그럼 1) 0.6.1.7과 네트워크 상태부터 들어가죠 15:29 <@cervantes> *콜록* 15:29 <jrandom> 이 주제에 대해 메일에 쓴 것 외에 더 보탤 말은 많지 않습니다. 추가 의견/질문/아이디어 있으신가요? 15:30 <Pseudonym> tunnel 생성 알고리즘을 바꾸기 전에 성능 최적화를 하는 건 순서가 거꾸로인 것 같네요 15:30 <gott> I am getting a lot of "No HTTP method found in the request. 15:30 <gott> Software caused connection abort: socket write error 15:30 <gott> " 15:30 <@modulus> tunnel 지연이 훨씬 낮아졌습니다, 변경을 하신 건지 제 ISP가 갑자기 좋아진 건지는 모르겠네요. 15:30 <gott> I2PTunnel Webmanager에서 15:31 <jrandom> gott: 그런 건 잘못된 HTTP 요청이거나 eepproxy가 이해하지 못한 것들을 시사합니다 15:31 <jrandom> modulus: 좋네요, 개선하려고 많은 작업을 해왔습니다 15:31 <jrandom> Pseudonym: 음, 지금까지 tunnel 생성이 병목은 아니었습니다 - 병목은 훨씬 상위 레벨에 있었어요 15:32 <jrandom> 반면에, 최근 몇 차례 리비전의 개선 덕분에 아래쪽 층의 몇 가지 문제가 드러났습니다 15:32 <Pseudonym> 아, 최적화는 코드의 다른 부분과 관련된 거였나요? 15:32 <Pseudonym> 좋네요 15:33 <jrandom> 네, SSU 레벨과 tunnel 동작 레벨에서요. tunnel 생성은 성능에 민감한 작업이 아닙니다 [물론 그럴 때도 있지만 ;] 15:34 <jrandom> 현재 라이브 네트워크 부하 테스트를 하면서, 여러 피어의 비-익명 부하 통계를 모아 더 좁혀보려 하고 있습니다 15:34 <ailouros> 때때로 어떤 destination에 설정한 것보다 더 많은 tunnel이 보이는 이유가 궁금합니다 (eg. eeProxy, inbound 7 tunnels 4 outbound) 15:34 <jrandom> 그래서 앞으로 며칠 동안 router 7xgV가 데이터를 많이 전송하는 걸 보시더라도, 신경 쓰지 마세요 ;) 15:35 <jrandom> ailouros: tunnel 생성에 시간이 걸리면, 만약을 대비해 여분을 더 만듭니다. 15:35 <jrandom> zzz가 그 부분의 몇 가지 이상한 이슈를 정리해뒀고, 개선을 위한 패치도 작업 중입니다 15:35 <ailouros> 그렇군요.. 그런데 왜 전부 동시에 만료되나요? 15:35 <@cervantes> jrandom: 궁금해서 그런데, 그 테스트는 언제 시작했나요? 15:35 <jrandom> cervantes: 몇 일 전에요 15:36 <@cervantes> 아 좋네요, 그게 _아닌_ 거군요 ;-) 15:36 <jrandom> 잘 모르겠어요 ailouros, 몇 가지 조건에 달려 있습니다. 다만 tunnel 생성 코드에... *콜록* 기묘한 부분이 좀 있어서, 0.6.2에서 다시 작성 중이라 당분간 손대지 않고 있었습니다 15:38 <ailouros> 알겠습니다. 정책 문제인 줄 알았어요... 특별한 이유가 없다면 tunnel들이 서로 다른 시점에 종료되면 좋겠습니다 15:38 <ailouros> 즉, tunnel 생성 시점을 분산시키는 식으로요 15:39 <jrandom> 네, 0.6.2에서는 더 나은 랜덤화가 들어갈 거고, zzz의 패치도 현재 리비전에 약간의 랜덤화를 추가합니다 15:40 <+Complication> 정상적으로 보이는 i2phex 인스턴스가... 왜 실행할 때마다 한 번씩 파일을 다시 해시하려 드는 걸까요? 15:40 <jrandom> 전혀 모르겠네요 15:40 <+Complication> 지금까지는 손상된 설정이 가장 그럴듯해 보이지만, 아직 설정을 지워보진 않았습니다. 15:40 <jrandom> 혹시 타임스탬프가 치우쳤을까요? 15:42 <+Complication> 아니요, 그것도 정상으로 보입니다 15:42 * jrandom 모르겠네요. phex의 그 부분 코드는 본 적이 없어서요 15:42 <jrandom> 어, code 15:42 <+Complication> 예전 설정 파일을 지우면 나아지는지 보겠습니다 15:42 <jrandom> 좋아요 15:43 <jrandom> 좋아요, 1) 네트워크 상태 / 0.6.1.7에 대해 더 있을까요? 15:43 <jrandom> 없다면 2) 실험용 tunnel 실패로 넘어가죠 15:44 <jrandom> 이건 이미 조금 이야기했지만, 노트와 zzz.i2p에 더 자세히 있습니다 15:44 <jrandom> zzz: 추가하거나 제기할 내용이 있나요? 15:46 <jrandom> 없으면, 3) SSU와 NAT로 넘어가죠 15:46 <jrandom> bar: 추가할 게 있나요? 15:46 <+bar> 아니요, 메일에 있는 것 외엔 덧붙일 게 없습니다 15:47 <jrandom> 좋아요, 세부 사항 몇 가지에는 아직 답을 달아야 하고요 - 제 생각엔 우리가 하는 재전송이 말씀하신 이슈 중 일부는 이미 처리할 겁니다 15:48 <jrandom> 핵심은 어떤 상황이 벌어지고 있는지 감지해서 적절한 절차를 자동화하는 겁니다 (아니면 사용자가 곤란하다는 걸 알려주거나요) 15:48 <+bar> 천천히 해도 됩니다, 급할 거 없어요 15:49 <+bar> 네, 당분간은 그 문제를 우회할 수 있도록 수동 사용자 설정을 제안했어요. 불가능할 수도 있지만, 나중에 논의해봅시다 15:50 <jrandom> 맞아요, 수동 오버라이드는 도움이 되겠지만, 예전 i2p 리비전들에 대한 제 경험으로는 모두가 (*정말 모두가*) 망치더군요 ;) 그래서 자동화가 더 바람직합니다 15:50 <jrandom> (여기서 '모두'에는 저도 포함됩니다 ;) 15:52 <+bar> 동의합니다 15:52 <ailouros> ㅋㅋ 저도 그랬다면 문서에 뭔가 문제가 있었던 거겠죠, 한 글자도 안 빼고 따라 했거든요 :D 15:53 <+bar> 그동안 peer 테스트를 좀 더 공부해보겠습니다 15:53 <jrandom> 좋아요, 고마워요 bar! 15:54 <+bar> (아마 그와 관련해 쓸모없는 스팸도 좀 만들어낼 수 있겠네요 :) 15:54 <jrandom> :) 15:55 <jrandom> 좋아요, 3)에 더 없으면 4) Syndie로 넘어가죠 15:56 <jrandom> 최근 이쪽에서 진전이 많았고, 0.6.1.7 이후로 UI도 꽤 대대적으로 개편했습니다 15:57 <jrandom> 별도의 독립 설치/빌드도 새로 나왔지만, 우리 모두 i2p가 설치되어 있으니 따로 필요하진 않습니다 15:57 <ailouros> 6.1.7의 레이아웃이 6.1.6보다 사용하기 어렵다고 느낍니다 15:58 <jrandom> 음, Syndie를 단일 사용자 모드로 실행 중인가요? 그리고 최신 CVS 빌드를 쓰나요, 아니면 공식 0.6.1.7 빌드를 쓰나요? 15:58 <ailouros> 공식 0.6.1.7, 단일 사용자 15:58 <jrandom> threaded 내비 대신 블로그형 인터페이스를 지지하는 쪽인가요? 15:58 <ailouros> 아니요, 다만 어떤 게 블로그형인지 잘 모르겠네요 15:58 <ailouros> 개인적으로는 threaded 내비가 더 좋습니다 15:59 <ailouros> (그리고 thread 보기에서 새 메시지에 색상 코드도 있었으면 합니다) 15:59 <+Complication> 상대적으로 최신 CVS, 단일 사용자 15:59 <+Complication> 사소한 이상 현상을 발견했습니다 (의도된 게 아닐 수도 있다고 봅니다) 15:59 <jrandom> 아, 그 부분은 CVS에서 진척이 많았습니다 ailouros 15:59 <ailouros> 좋네요 :) 16:00 <jrandom> 모든 브랜치를 펼치는 대신 cervantes가 제안한 방식대로 한 브랜치만 전체 순회하는 새로운 threaded 표시도 있습니다 16:00 <@cervantes> 그 변경 사항이 syndiemedia.i2p.net에 반영되었나요? 16:00 <+bla> http://localhost:7657/syndie/syndicate.jsp 의 location에 기본 예시 몇 개를 보여주는 게 좋을까요? 16:00 <jrandom> syndiemedia.i2p.net은 CVS 헤드입니다, 네 16:00 <+Complication> thread를 열어서 게시물을 읽고 있을 때... 그 후 게시물이 하나도 매칭되지 않는 필터를 적용하면 (e.g. thread "Syndie threading"을 열고, 필터 "i2p.i2phex" 적용)... 16:00 <jrandom> 맞아요, bla. 새 설치에는 기본값 세 개가 들어가겠지만, 예시를 두는 것도 좋겠네요 16:01 <@cervantes> (실제 thread 트리도 완전히 열려야 하긴 합니다) 16:01 <+Complication> ...현재 게시물이 여전히 표시된 채로 남아 있어요, 마치 매칭된 것처럼요... 16:01 <+Complication> 제가 분명히 "Go" 버튼을 클릭했는데도요. 16:01 <@cervantes> Complication: 네, 저도 그게 헷갈렸습니다 16:02 <jrandom> 흠 Complication, 기본 아이디어는 게시물을 보면서도 이리저리 탐색할 수 있게 하는 거였지만, 표시 중인 게시물을 내려버리는 게 더 나을지도 모르겠네요 16:02 <jrandom> cervantes: 아, 네 리프까지 펼치는 건 괜찮겠고, 구현도 어렵지 않을 겁니다 16:02 <+Complication> 방금 눈에 띄어서 말씀드렸습니다 16:02 <@cervantes> (아니면 매칭되는 게 없다는 걸 더 분명히 표시하든지요) 16:03 <jrandom> 음, thread 내비에는 이미 *no matches*라고 뜨긴 합니다 :) 16:03 <ailouros> 아마 라이터를 찾는 걸지도 16:03 <jrandom> !thwap 16:03 <@cervantes> (또는 매칭 없음이 더 눈에 띄게) 16:03 <jrandom> <blink>No matches</blink> 16:03 <+Complication> 이런 :) 16:04 <tethra> 네 !thwap이 대신 spaetz__에게 맞은 듯해요, jr! 16:04 <+Complication> 맞아요, 때로는 thread 내비게이터가 정말 멀게 느껴지죠 :) 16:04 <jrandom> 네, 옵션으로 옆에 띄울 수 있도록 css를 몇 가지 실험 중입니다 16:05 <@cervantes> 스킨 지원이 있으면 thread를 위/아래/왼쪽/오른쪽 등 원하는 곳에 둘 수 있겠죠 16:05 <@cervantes> 아, jr가 말한 대로요 16:05 <+Complication> "Threads" 링크를 누르면 꽤 빨리 그리로 갑니다 16:05 <+Complication> ...현재 뷰포트 안에 있다면요. 16:06 <+Complication> 그리고 키보드 내비게이션에 익숙한 분들은 당연히 "End"를 누르면 됩니다 16:06 <jrandom> 물론 이런 것들은 수정이 정말 간단합니다 (CVS에서 빠르게 바뀌는 걸 보면 아시죠 :), 그래서 제안(또는 목업 - html / png / etc)이 있으면 언제든 올려주세요 16:07 <jrandom> 며칠 내에 CVS에 메인 블로그 개요 페이지를 추가할 예정입니다 16:08 <jrandom> 좋아요, Syndie에 관한 다른 작업도 많으니 더 알고 싶으면 http://localhost:7657/syndie/ 에 들러주세요 :) 16:08 <jrandom> 그와 관련해서 더 이야기할 게 있나요, 아니면 5) ???로 넘어갈까요? 16:09 <zzz> 안녕하세요 이제 막 왔습니다. 2)와 관련해서, 제 패치를 테스트해 줄 분을 찾고 있어요. 16:10 <zzz> 제 결과로 job 지연과 안정성이 개선되고, router 멈춤도 줄었습니다. 그래서 다른 분들도 시도해보셨으면 합니다. 16:10 <ailouros> 충분히 좋아 보이네요. 제가 무엇을 하면 되나요? 16:11 <jrandom> 안녕 zzz, 좋아요, 여기서도 좀 두들겨 볼게요. 구성 요소가 다양한 만큼 여러 조각으로 나누는 게 좋을 수도 있겠지만, 괜찮아 보이고 0.6.1.8에 맞춰가고 있습니다 16:11 <ailouros> (여기 평균 가동 시간은 약 10시간이라서요 :( 16:11 <zzz> 소스 코드와 ant가 있으면 패치를 적용하면 됩니다 - 아니면 원하시면 i2pupdate.zip을 올릴 수도 있어요 16:12 <zzz> jrandom 나누는 작업을 해볼게요 16:12 <ailouros> 업데이트로 가겠습니다, 감사합니다 16:13 <zzz> ailouros 한 시간 안에 zzz.i2p에 올리겠습니다 - 감사합니다 16:13 <jrandom> zzz: 여유가 없으면 신경 쓰지 않아도 돼요... 제가 diff를 읽을 수 있습니다 :) 16:13 <ailouros> 감사합니다 16:14 <zzz> jrandom 알겠어요. 자잘한 것들은 당신이나 제가 쉽게 걷어낼 수 있습니다. 16:16 <ailouros> 이제 5) ???인가요? 16:16 <zzz> jrandom 다른 주제로 i2phex에서 Router OOM이 있었고 SAM 관련 가능성도 있습니다 16:16 <jrandom> 네 ailouros 16:16 <jrandom> 아 맞아요 zzz, SAM에 무슨 문제가 있는지 추적할 수 있으면 좋겠습니다 16:17 <ailouros> j346, 제 앱을 확인해볼 기회가 있었나요? 16:17 <jrandom> 최고는 누군가가 SAM bridge 유지보수를 맡아주는 거겠죠, 저는 그동안 본격적으로 손대지 못했고, human도 한동안 보이지 않거든요. 16:19 <jrandom> 아직요 ailouros, 유감스럽게도. 동작 방식이 조금 불확실해서 먼저 소스를 읽어봐야 합니다 16:20 <ailouros> 편하게 물어보세요 16:20 <ailouros> (그리고 소스 여행에 행운을... '난장판'의 좋은 정의니까요) 16:20 <jrandom> 헤헤 16:21 <zzz> 정정합니다 제 경험상 OOM은 i2phex가 아니라 i2p-bt를 사용할 때 발생했습니다. i2p-bt 하나를 돌리면 약 24시간 후, 두 개를 돌리면 몇 시간 내에 발생합니다 16:22 <+Complication> 제 경우는 밤늦게 스트레스 테스트 후에 발생했어요. 16:22 <+Complication> (그때 5분 평균 50 KB/s까지 본 건 기록해둡시다) 16:22 <bar_> ailouros, 당신의 앱이 무엇이고 무엇을 하는지 다시 알려줄 수 있나요? 기억력이 좋긴 한데 짧아서요... 16:22 <+Complication> 수신 속도요. 16:22 <+Complication> 송신은 35 KB/s로 제한했었습니다 16:22 <@cervantes> Complication: 그걸 밤샘 스트레스 테스트라고 부르는 건 처음 들어보네요... 16:22 <jrandom> 좋네요 Complication 16:23 <+Complication> cervantes: 음, 그럼 반쯤은 매일 하는 초흡혈(megaleeching)이라고 부를 수도 있겠죠 :P 16:23 <ailouros> bar_: 서로 다른 파일 간에 공통 블록을 공유하는 분산 파일 공유 앱의 작동하는 개념증명(PoC)입니다 (polecat의 제안) 16:23 <bar_> 아, 맞아요, 고마워요 ailouros 16:24 <tethra> cervantes: 헤헤헤 ;) 16:24 <ailouros> 천만에요 (소스를 원하시면 C/C++입니다) 16:25 <+polecat> 조심하세요, 두 바이너리 블록이 동일할 확률은 매우 희박합니다. 저는 주로 실제로는 쓸모 없을 순수한 이론을 이야기한 겁니다. 16:25 <ailouros> 동의합니다. 제 생각엔 동일 파일의 서로 다른 버전을 받을 때 유용할 것 같아요 16:25 <ailouros> 예를 들어, 손상된 블록이 있는 동영상 같은 경우요 16:25 <+polecat> 0으로만 된 블록은 번개처럼 전송할 수 있겠네요! ("The next block is zeroes" "oh I have that already" "the next block is zeroes" "oh I have that already") 16:26 <ailouros> 혹은 다른 ZIP 파일들의 아카이브 16:26 <jrandom> 또는 예컨대 수정된 ID3 태그 등 16:26 <ailouros> 맞아요 16:26 <+polecat> 맞습니다. 다만 손상된 블록이 있는 동영상을 "고치는" 쉬운 방법은 그 위에 비트토렌트로 다시 받게 하는 겁니다. 대부분의 클라이언트는 해시가 같은 블록은 유지하고, 다른 블록만 덮어씁니다. 16:26 <jrandom> 하지만 파일 아카이브는 아마 잘 안 될 겁니다. 파일 경계에서 끊어야 하니까요 16:27 <ailouros> j636, 그래서 저는 고정 블록 크기 대신 데이터 마크를 기준으로 분할하는 LBFS 아이디어를 구현하고 싶습니다 16:27 <@cervantes> DC 커뮤니티는 그 방법을 썼죠, rarset으로 파일 배포본을 공유하는 식으로요 16:27 <+polecat> 유용할 수 있는 건 일반적인 바이너리 오류 정정 알고리즘을 만들고, 대규모로 적용하는 겁니다. 모든 블록을 서로 "보정"할 수 있게 하고, 블록 자체 대신 보정 데이터만 전송하면 되니까요. 그 보정 데이터가 블록 전송보다 작을 수도 있죠. 16:29 <@cervantes> 그리고 검색은 그 RAR 파트의 Tiger 해시를 기반으로 합니다 16:29 <+Complication> 좋은 생각이네요... 다만 어렵게 들립니다 :) 16:29 <+polecat> 하지만 해시 대 해시로 동일함을 따진다면... 동일한 블록을 찾을 일은 없겠죠! 16:29 <ailouros> cervantes, "rarset"이 뭐예요? :D ("RAR file" 말고요) 16:29 <+polecat> 양쪽 모두 이미 파일을 가지고 있고, 그중 하나가 손상된 경우가 아니라면 말이죠. 16:29 <ailouros> polecat, 어? 16:29 <@cervantes> ailouros: 분할된 RAR 아카이브예요. 필요하면 패리티 파일도 함께요 16:30 <ailouros> cervantes: 그렇게 하는 장점이 잘 이해가 안 됩니다 16:31 <@cervantes> 주요 장점은 DC에 유사 멀티 소스 다운로드를 더해준 것이죠 16:32 <ailouros> 음, 그건 파일 간 블록 공유 메커니즘의 일부 아닌가요? 16:34 <ailouros> polecat: 비트토렌트로 손상된 파일을 덮어쓰는 것과 관련해서, 동시에 여러 버전을 받으려는 경우에는 도움이 안 됩니다 16:35 <@cervantes> 클라이언트는 유효한 파트만 매칭/다운로드하고, 패리티 파일이 있으면 손상된 파트도 복구할 수 있습니다 16:35 <ailouros> 제 시스템에서는 손상된 파트가 없습니다 (구성 블록을 모두 다운로드하고 재검증한 뒤에야 파일을 조립하니까요) 16:36 <@cervantes> 비트토렌트가 기본으로 하는 일이죠, 다만 개별 파트를 특정해서 검색할 수는 없다는 점이 다릅니다 16:36 <+polecat> 다중 버전은 한 비트도 공통되지 않을 가능성이 높습니다... 그래서 바보 같죠. 어떤 사람은 영화를 우표 크기로 다시 인코딩해 놓고 같은 이름을 붙여요. 16:37 <+polecat> 또는 또 다른 이는 랜덤 데이터를 가져다 당신이 받으려는 파일 이름을 붙여버리고요. 16:37 <ailouros> ㅋㅋ 맞아요 16:37 <@cervantes> 맞습니다, 그리고 rarset 릴리스는 그런 것에 면역이죠... 16:37 <ailouros> 하지만 다른 네트워크(emule, kazaa 등)에서 온 파일은 종종 손상되어 있다는 점을 기억하세요 16:38 <+polecat> rarset 릴리스도 면역은 아닙니다... 16:38 <+polecat> 어떤 rarset이 올바른 건지 여전히 판별해야 하죠. 16:38 <ailouros> cervantes, rarset이 누군가가 랜덤 쓰레기를 올리는 문제에 어떻게 면역이 되죠? 16:38 <@cervantes> (신뢰할 수 있는 소스가 있다는 전제하에요) 16:39 <@cervantes> 릴리스 그룹이 해시/배포 정보를 공개하기 때문입니다 16:39 <ailouros> 하하하 그건 쉽네요 :D 16:39 <@cervantes> 그리고 품질이 안 좋으면 'nuked'로 표시되고, 사람들이 공유에서 빼버립니다 16:40 <ailouros> 그 정도는 제 장난감(프로토타입)이 이미 합니다 16:40 <@cervantes> 좋게 들리네요 ;-) 16:40 <ailouros> 신뢰할 수 있는 소스에서 파일 디스크립터를 받고, 곧바로 멀티 다운로드를 합니다 16:41 <@cervantes> 좋아요 ;-) 16:41 <ailouros> 파일을 검색하진 못하지만, 각 사용자의 공유 디렉토리를 탐색할 수 있으니 웹 크롤러로 긁어와 결과를 캐시할 수 있습니다 16:42 <ailouros> 다만 필요하다고 판단되면 나중에 검색 기능을 추가할 수도 있습니다 16:44 <ailouros> 제 장난감이 제대로 앱으로 발전하면, Freenet이 제공하려는 캐싱과 탄력성을 제공할 수 있다고 봅니다 16:44 <ailouros> 즉, 정적 콘텐츠 배포와 캐싱이요 16:45 <ailouros> 제 블로그를 읽으면 캐싱되고, 다른 사람이 원할 때 제공하는 식입니다. 거기 두는 것 이상으로는 아무 것도 하지 않습니다 16:45 <ailouros> 마음에 안 드시나요? 지우면 끝입니다 16:45 <jrandom> 흠, 그러면 Syndie에서 사용할 수 있는 백엔드 저장소로 보나요? 16:46 <ailouros> 백엔드 저장소로 사용할 수는 있습니다 16:46 <ailouros> 현 상태로도 i2p 기본 설치에서 Jetty 대신 사용할 수도 있을 겁니다 16:46 <jrandom> e.g. attachments / links to [clunk hash="$foo"]my file[/clunk] 16:46 <ailouros> (뭐, 몇 가지 사소한 변경만 하면요 :D ) 16:46 <jrandom> 헤헤 16:47 <jrandom> 좋아요, 네, clunk가 어떻게 동작하는지 정말 모르겠네요... Syndie에 글을 올리거나 eepsite를 하나 올려줄래요? :) 16:47 <ailouros> 파일을 요청하면 파일 해시가 다운로드되고, 이 해시들을 바탕으로 전체 파일이 자동으로 다운로드됩니다 16:48 <jrandom> 맞아요, 하지만 어디에서 어디로 "다운"로딩되는지 등은 질문이 남습니다. 전체 네트워크 아키텍처 설명이 도움이 되겠어요 16:48 <ailouros> 먼저 제대로 된 문서를 쓰고, 어딘가에 공개하겠습니다 16:48 <jrandom> r0x0r, 감사합니다 16:48 <ailouros> 해시를 가져온 곳이면 어디에서든 내려받습니다 16:48 <ailouros> 거기에 이 블록들을 공유하는 다른 모든 이들에게서도요 16:49 <ailouros> Go!Zilla와 Download Accelerator를 떠올려 보세요 :) 16:49 <jrandom> 제가 얼마나 혼란스러운지 오해하신 듯합니다 16:49 <ailouros> 하지만 투명하게, 그리고 i2p 안에서요 16:49 <ailouros> ㅋㅋ 그런 듯요 :D 16:50 <jrandom> 예를 들면 "clunk 클라이언트를 실행하고, clunk 서버에서 다운로드하고, clunk 피어 정보를 받는다" 같은 아주아주 기본적인 설명이요 16:50 <jrandom> 웹 브라우저로 clunk 클라이언트에 질의하나요? 아니면 서버? 아니면 피어? 16:51 <jrandom> (제가 이 정도로 길을 잃었습니다) 16:51 <ailouros> 0부터 다시 합시다 :) 16:51 <ailouros> 웹 브라우저를 씁니다 16:51 <ailouros> 당신의 클라이언트에 연결합니다 16:51 <ailouros> 브라우저로 다른 사람들의 디렉토리를 탐색합니다 16:51 <ailouros> 브라우저로 어떤 파일을 받을지 선택합니다 16:51 <ailouros> 지저분한 일은 클라이언트가 처리합니다 16:52 <ailouros> 다운로드된 파일을 받습니다 16:52 <ailouros> 이제 좀 낫나요? :) 16:52 <jrandom> 좋아요, 감사합니다 - 그러니까 "다른 사람의 디렉토리 탐색"은 당신의 클라이언트가 상대의 클라이언트에 질의하고, 그 결과를 HTML로 표현해 응답하는 거군요 16:52 <ailouros> 맞아요 16:52 <jrandom> (혹은 어떤 서버/슈퍼피어 등에서 끌어오거나요) 16:53 <jrandom> 좋군요 16:53 <ailouros> 중복 찾기, 멀티 다운로드 등 모든 지저분한 작업은 (로컬) 클라이언트가 투명하게 처리합니다 16:54 <ailouros> 당신이 보게 되는 건 기본적으로 디렉토리 트리와 다운로드할 수 있는 몇몇 파일입니다 16:54 <jrandom> 좋네요 16:55 <ailouros> 데이터를 publish하려면 자신의 공개 (P2P) 주소를 알려줍니다 16:55 <ailouros> 그리고 파일을 share하려면 그것들을 pub/ 디렉토리(또는 하위 디렉토리)에 복사(또는 심링크)하면 됩니다. 아주 간단해요 16:57 * jrandom 소스를 더 파보고, 추가 정보를 기대하겠습니다 :) 16:57 <jrandom> 좋아요, 회의에서 더 이야기할 분 있으신가요? 16:57 <bar_> 음.. 실례지만 publishing과 sharing의 차이가 뭔가요? publishing은 데이터를 어떤 저장소에 푸시하는 건가요? 16:58 <ailouros> bar_: sharing은 다운로드할 블록을 제공하는 겁니다. publishing은 무엇을 공유하는지 세상에 알리는 것이고요 16:58 <ailouros> publishing은 sharing의 부분집합입니다 16:58 <bar_> 아하, 이해했습니다, 고마워요 16:58 <ailouros> 예를 들어, 파일의 절반만 가지고 있다면 share는 하되 publish는 하지 않습니다 16:59 <jrandom> 그럼 사람들이 당신에게서 그 블록들을 받을 수 있다는 걸 어떻게 알죠? 16:59 <ailouros> 그리고 어떤 파일을 publish할지 완전히 제어할 수 있습니다 (다운로드한 모든 파일이 publish되는 emule과 달리요) 16:59 <ailouros> 각 클라이언트가 자신이 제공할 수 있는 블록 정보를 주기적으로 네트워크에 보내기 때문입니다 17:00 <jrandom> 좋군요 17:00 <ailouros> 네트워크로 보낸다는 건 서버(현재)로 보낸다는 뜻이거나, DHT(향후)로 보낸다는 뜻입니다 17:00 <jrandom> 그럼 block tracker가 있는 mnet 같은 거네요 17:00 <ailouros> 어... mnet 같은? 17:01 <jrandom> mnet(mnetproject.org)이 동작하는 방식과 비슷합니다 17:01 * ailouros mnetproject.org를 읽는 중 17:02 <ailouros> 음, 개인 공간만 있고, 공유 공간은 없습니다 17:02 <ailouros> 그리고 블록을 여기저기로 PUSH하지 않습니다 17:02 <jrandom> 네, mnet과 완전히 같진 않지만 구조적으로 비슷합니다 17:03 <jrandom> 모두가 가난해서 누군가가 데이터를 호스팅해줄 수 없는 mnet 같은 거죠 ;) 17:03 <ailouros> 네 17:03 <ailouros> :D 17:03 <jrandom> 좋아요, 더 제기할 내용이 또 있을까요? 17:04 <jrandom> 없다면... 17:04 * jrandom 마무리 준비를 합니다 17:04 * jrandom 회의를 *baf* 하며 종료합니다