Cuộc họp các nhà phát triển I2P - 06 tháng 12 năm 2005

15:26 <jrandom> 0) chào 15:26 <jrandom> 1) 0.6.1.7 và trạng thái mạng 15:26 <jrandom> 2) Các lỗi tunnel thử nghiệm 15:26 <jrandom> 3) SSU và NAT 15:26 <jrandom> 4) Syndie 15:26 <jrandom> 5) ??? 15:26 <jrandom> 0) chào 15:26 * jrandom vẫy tay 15:26 <jrandom> ghi chú trạng thái hàng tuần đã đăng tại http://dev.i2p.net/pipermail/i2p/2005-December/001237.html 15:26 * ailouros đọc ghi chú 15:27 * jrandom đến muộn, nên tôi sẽ cho mọi người chút thời gian để đọc :) 15:29 <jrandom> ok, vào luôn phần 1) 0.6.1.7 và trạng thái mạng 15:29 <@cervantes> *khụ* 15:29 <jrandom> Tôi không có gì nhiều để bổ sung ngoài những gì trong email về điểm này. ai có thêm bình luận/câu hỏi/ý tưởng? 15:30 <Pseudonym> có vẻ tối ưu hiệu năng trước khi thay đổi thuật toán tạo tunnel có thể là làm ngược 15:30 <gott> Tôi nhận được rất nhiều "No HTTP method found in the request. 15:30 <gott> Software caused connection abort: socket write error 15:30 <gott> " 15:30 <@modulus> độ trễ tunnel thấp hơn nhiều, tôi không biết bạn đã thay đổi gì hay ISP của tôi bỗng nhiên tốt hơn. 15:30 <gott> từ I2PTunnel Webmanager 15:31 <jrandom> gott: điều đó gợi ý các yêu cầu HTTP lỗi, hoặc những thứ mà eepproxy không hiểu 15:31 <jrandom> modulus: tốt, chúng tôi đã làm nhiều để cố cải thiện mọi thứ 15:31 <jrandom> Pseudonym: ừ, tới giờ việc tạo tunnel chưa phải điểm nghẽn của chúng ta - điểm nghẽn là các thứ ở tầng cao hơn nhiều 15:32 <jrandom> mặt khác, các cải tiến ở vài bản gần đây đã lộ ra vài vấn đề ở tầng dưới 15:32 <Pseudonym> ồ, vậy tối ưu liên quan tới phần khác của mã? 15:32 <Pseudonym> hay đấy 15:33 <jrandom> đúng, ở tầng SSU, cũng như tầng vận hành tunnel. việc tạo tunnel không nhạy về hiệu năng [trừ khi lại nhạy ;] 15:34 <jrandom> Tuy nhiên tôi đang thử tải trực tiếp trên mạng, thu thập một số thống kê tải không ẩn danh của các peer (nút ngang hàng) khác nhau để cố thu hẹp phạm vi hơn nữa 15:34 <ailouros> Tôi thắc mắc vì sao đôi khi tôi thấy nhiều tunnel hơn cấu hình cho một đích (vd. eeProxy, inbound 7 tunnels 4 outbound) 15:34 <jrandom> nên vài ngày tới nếu bạn thấy router 7xgV đang chuyển rất nhiều dữ liệu, ừ thì, đừng bận tâm ;) 15:35 <jrandom> ailouros: khi việc tạo tunnel mất thời gian, nó sẽ dựng thêm dự phòng, phòng khi cần. 15:35 <jrandom> zzz cũng phác vài vấn đề kỳ lạ ở mảng đó, và đang có một bản vá để cải thiện chút ít 15:35 <ailouros> Tôi hiểu... nhưng sao chúng lại hết hạn cùng lúc? 15:35 <@cervantes> jrandom: hỏi cho biết, bạn bắt đầu các thử nghiệm đó khi nào? 15:35 <jrandom> cervantes: vài ngày trước 15:36 <@cervantes> à hay, vậy _không_ phải vì cái đó ;-) 15:36 <jrandom> không rõ ailouros, tùy vài điều kiện. nhưng có vài... *khụ* điểm kỳ quặc trong mã tạo tunnel, tôi đã tạm chưa đụng vào vì nó sẽ được viết lại cho 0.6.2 15:38 <ailouros> Tôi hiểu. Tôi tưởng đó là vấn đề chính sách... Tôi thích thấy các tunnel chết lệch thời điểm trừ khi có lý do không nên 15:38 <ailouros> như việc tạo tunnel bị lệch pha 15:39 <jrandom> ừ, sẽ có ngẫu nhiên hoá tốt hơn cho 0.6.2, và bản vá của zzz cũng thêm chút ngẫu nhiên cho bản hiện tại 15:40 <+Complication> Tôi thắc mắc vì sao một instance i2phex bình thường... lại quyết định băm lại (rehash) tệp mỗi lần khởi động xen kẽ? 15:40 <jrandom> không biết nữa 15:40 <+Complication> Cấu hình hỏng có vẻ là nguyên nhân hợp lý tới giờ, nhưng tôi chưa xóa cấu hình. 15:40 <jrandom> có lẽ timestamp lệch? 15:42 <+Complication> Không, chúng cũng có vẻ đúng 15:42 * jrandom không biết. chưa từng xem phần mã đó của phex 15:42 <jrandom> à, code 15:42 <+Complication> Tôi sẽ xem thử xóa các tệp cấu hình cũ có giúp gì không 15:42 <jrandom> hay đấy 15:43 <jrandom> ok, còn gì về 1) Trạng thái mạng / 0.6.1.7 không? 15:43 <jrandom> nếu không, chuyển sang 2) Các lỗi tunnel thử nghiệm 15:44 <jrandom> chúng ta đã chạm tới chút rồi, và còn nhiều trong ghi chú và trên zzz.i2p 15:44 <jrandom> zzz: bạn có gì muốn bổ sung/nêu ra không? 15:46 <jrandom> nếu không, chuyển sang 3) SSU và NAT 15:46 <jrandom> bar: bạn muốn bổ sung gì không? 15:46 <+bar> không, tôi không có gì thêm ngoài những gì trong mail 15:47 <jrandom> tốt, tôi vẫn phải hồi một số chi tiết - tôi nghĩ cơ chế truyền lại của chúng ta đã xử lý vài vấn đề bạn nêu 15:48 <jrandom> mấu chốt là phát hiện tình huống nào đang xảy ra, để ta tự động hoá quy trình đúng (hoặc báo cho người dùng là họ bó tay) 15:48 <+bar> mọi thứ sẽ đến đúng lúc, không vội 15:49 <+bar> ừ, tôi đề xuất một thiết lập thủ công cho người dùng để tạm thời lách vấn đề đó, có thể không làm được, nhưng ta bàn sau 15:50 <jrandom> ừ, ghi đè thủ công sẽ giúp, nhưng kinh nghiệm của tôi với các bản i2p trước là ai cũng làm hỏng bét ;) nên tự động vẫn hơn 15:50 <jrandom> (ai ở đây gồm cả tôi ;) 15:52 <+bar> đồng ý 15:52 <ailouros> lol nếu tôi cũng vậy thì chắc tài liệu có vấn đề, vì tôi làm theo từng bước :D 15:53 <+bar> trong lúc đó, tôi sẽ dành thời gian nghiên cứu peer testing 15:53 <jrandom> hay, cảm ơn bar! 15:54 <+bar> (có lẽ tôi cũng có thể tạo chút spam vô dụng về chuyện đó :) 15:54 <jrandom> :) 15:55 <jrandom> ok, nếu không còn gì ở 3), chuyển sang 4) Syndie 15:56 <jrandom> gần đây có nhiều tiến triển ở mảng này, với cải tổ UI khá lớn kể từ khi 0.6.1.7 ra mắt 15:57 <jrandom> cũng có bản cài/dựng độc lập mới, dù tất cả chúng ta đã cài i2p nên không cần bản riêng 15:57 <ailouros> Tôi thấy bố cục của 6.1.7 khó dùng hơn 6.1.6 15:58 <jrandom> hmm, bạn chạy syndie ở chế độ người dùng đơn? và/bạn dùng bản dựng CVS mới nhất hay bản chính thức 0.6.1.7? 15:58 <ailouros> bản chính thức 0.6.1.7, người dùng đơn 15:58 <jrandom> bạn có ủng hộ giao diện kiểu blog, thay vì điều hướng theo luồng (threaded) không? 15:58 <ailouros> Tôi không, dù tôi cũng không rõ cái nào là kiểu blog 15:58 <ailouros> cá nhân tôi thích điều hướng theo luồng hơn 15:59 <ailouros> (và tô màu cho thông điệp mới trong chế độ xem theo luồng) 15:59 <+Complication> CVS tương đối mới, người dùng đơn 15:59 <+Complication> Tôi thấy một điểm nhỏ kỳ lạ (mà tôi nghĩ có thể không chủ ý) 15:59 <jrandom> à, trong CVS đã có nhiều tiến triển ở mảng đó, ailouros 15:59 <ailouros> tuyệt :) 16:00 <jrandom> chúng tôi cũng có hiển thị theo luồng mới, dùng đề xuất của cervantes duyệt đầy đủ chỉ một nhánh thay vì tất cả nhánh 16:00 <@cervantes> những thay đổi đó đã đẩy lên syndiemedia.i2p.net chưa? 16:00 <+bla> Có nên hiển thị vài ví dụ mặc định cho trường location tại http://localhost:7657/syndie/syndicate.jsp không? 16:00 <jrandom> syndiemedia.i2p.net là CVS head, đúng 16:00 <+Complication> Khi bạn đã mở một thread và đang đọc các bài viết của nó... rồi chọn áp dụng một bộ lọc mà không có bài nào khớp (vd. mở thread "Syndie threading", áp dụng bộ lọc "i2p.i2phex")... 16:00 <jrandom> ừ, có lẽ nên, bla. cài đặt mới sẽ có ba mặc định ở đó, nhưng ví dụ thì vẫn tốt 16:01 <@cervantes> (cây của thread đó cũng cần mở hết nhánh) 16:01 <+Complication> ...có vẻ vẫn để các bài hiện tại hiển thị, như thể chúng khớp vậy... 16:01 <+Complication> Mặc dù tôi chắc chắn đã bấm nút "Go". 16:01 <@cervantes> Complication: ừ tôi cũng thấy rối 16:02 <jrandom> hmm Complication, ý tưởng chung là cho bạn duyệt quanh khi vẫn xem một bài, nhưng có lẽ tốt hơn là ẩn các bài đang hiển thị 16:02 <jrandom> cervantes: à, mở rộng tới lá sẽ tốt, và làm cũng đơn giản 16:02 <+Complication> Vừa để ý, thấy nổi bật nên báo 16:02 <@cervantes> (hoặc làm cho rõ ràng hơn là không có kết quả khớp) 16:03 <jrandom> ừ, điều hướng theo luồng có nói là *no matches* :) 16:03 <ailouros> có lẽ anh ấy đang tìm bật lửa 16:03 <jrandom> !thwap 16:03 <@cervantes> (hoặc làm cho càng rõ ràng hơn là không có kết quả khớp) 16:03 <jrandom> <blink>No matches</blink> 16:03 <+Complication> Úi :) 16:04 <tethra> có vẻ cú !thwap của bạn trúng spaetz__ rồi, jr! 16:04 <+Complication> Đúng, đôi khi bộ điều hướng thread cảm giác như ở xa quá :) 16:04 <jrandom> ừ, chúng tôi đang thử vài css để thả nó dọc bên cạnh, như một tuỳ chọn 16:05 <@cervantes> với hỗ trợ skin, bạn có thể đặt thread ở trên, dưới, trái, phải, v.v. 16:05 <@cervantes> à như jr nói 16:05 <+Complication> Liên kết "Threads" đưa đến đó khá nhanh, 16:05 <+Complication> ...nếu nó đang nằm trong khung nhìn. 16:06 <+Complication> Và ai quen điều hướng bằng bàn phím có thể bấm "End" 16:06 <jrandom> tất nhiên, những thứ này rất dễ sửa (như bạn thấy qua thay đổi nhanh trong CVS :), nên nếu ai có đề xuất (hoặc mockup - html / png / v.v.), xin cứ đăng lên bất cứ lúc nào 16:07 <jrandom> Tôi kỳ vọng vài ngày nữa trong CVS sẽ có trang tổng quan blog chính 16:08 <jrandom> ok, còn nhiều thứ khác đang diễn ra với syndie, ghé http://localhost:7657/syndie/ để biết thêm :) 16:08 <jrandom> ai còn gì muốn nêu về việc đó, hay chúng ta sang 5) ??? 16:09 <zzz> chào vừa mới vào. về 2), tôi đang tìm người thử nghiệm bản vá của tôi. 16:10 <zzz> Kết quả của tôi là cải thiện độ trễ job và độ tin cậy, và giảm treo router. Hy vọng người khác sẽ thử. 16:10 <ailouros> nghe đủ thuyết phục. tôi cần làm gì? 16:11 <jrandom> chào zzz, ok hay, tôi cũng sẽ quần nó chút ở đây. nó có nhiều thành phần khác nhau, nên có lẽ đáng tách ra, nhưng trông ổn và đang đúng tiến độ cho 0.6.1.8 16:11 <ailouros> (thời gian chạy trung bình ở đây khoảng 10h :( 16:11 <zzz> Nếu bạn có source code và ant thì áp bản vá là được - hoặc tôi có thể đưa lên một i2pupdate.zip nếu bạn muốn 16:12 <zzz> jrandom Tôi sẽ làm việc để tách nó ra 16:12 <ailouros> Tôi sẽ chọn gói cập nhật, cảm ơn 16:13 <zzz> ailouros tôi sẽ đưa lên zzz.i2p trong vòng một giờ - cảm ơn 16:13 <jrandom> zzz: Tôi không bận tâm đâu trừ khi bạn rảnh... Tôi có thể đọc diff :) 16:13 <ailouros> cảm ơn bạn 16:14 <zzz> jrandom OK. Có vài thứ linh tinh có thể dễ dàng gỡ ra bởi bạn hoặc tôi. 16:16 <ailouros> Tôi đoán giờ chúng ta ở 5) ???? 16:16 <zzz> jrandom chủ đề khác là Router bị OOM (hết bộ nhớ) với i2phex và khả năng có vấn đề ở SAM 16:16 <jrandom> ừ ailouros 16:16 <jrandom> à đúng zzz, sẽ rất tốt nếu lần ra chuyện gì đang xảy ra với SAM 16:17 <ailouros> j346, bạn đã có dịp xem app của tôi chưa? 16:17 <jrandom> Sẽ TUYỆT nếu có ai nhảy vào nhận bảo trì SAM bridge, vì tôi chưa làm gì đáng kể, và human đã không xuất hiện một thời gian. 16:19 <jrandom> chưa ailouros, tiếc là vậy. tôi hơi không chắc nó hoạt động thế nào, nên tôi phải đọc source trước 16:20 <ailouros> cứ hỏi thoải mái 16:20 <ailouros> (và chúc may mắn khi lặn vào source, nó là định nghĩa chuẩn của chữ "bừa bộn") 16:20 <jrandom> hehe 16:21 <zzz> đính chính: trải nghiệm của tôi là OOM khi dùng i2p-bt, không phải i2phex. Xảy ra sau khoảng 24 giờ khi chạy một i2p-bt và vài giờ khi chạy hai i2p-bt 16:22 <+Complication> Của tôi xảy ra sau vài lần stress-test khuya. 16:22 <+Complication> (trong đó, xin lưu ý, tôi thấy trung bình 5 phút đạt 50 KB/s) 16:22 <bar_> bạn nhắc lại giúp ứng dụng của bạn là gì/làm gì được không, ailouros? trí nhớ tôi tốt nhưng ngắn... 16:22 <+Complication> Tốc độ vào, tức là. 16:22 <+Complication> Tốc độ ra bị giới hạn 35 KB/s 16:22 <@cervantes> Complication: tôi chưa từng nghe gọi nó là 'stress test khuya' trước đây... 16:22 <jrandom> ngon đấy, Complication 16:23 <+Complication> cervantes: ừ thì, có thể gọi là 'leech khủng bán nhật' vậy :P 16:23 <ailouros> bar_: đó là bản chứng minh ý tưởng (proof-of-concept) chạy được cho một ứng dụng chia sẻ tệp phân tán, chia sẻ các block chung giữa các tệp khác nhau (như polecat gợi ý) 16:23 <bar_> à, đúng rồi, cảm ơn ailouros 16:24 <tethra> cervantes: heheheh ;) 16:24 <ailouros> không có chi (ai muốn lấy source, nó viết bằng c/c++) 16:25 <+polecat> ailouros: Cẩn thận, khả năng hai block nhị phân giống nhau là khá hiếm, tôi chủ yếu đang nói về lý thuyết thuần tuý mà thực tế có thể không hữu ích. 16:25 <ailouros> polecat, tôi đồng ý. Tôi đoán nó hữu ích khi bạn có các phiên bản khác nhau của cùng một tệp 16:25 <ailouros> như, một bộ phim có một block bị hỏng 16:25 <+polecat> Bạn có thể truyền các block toàn số 0 với tốc độ ánh sáng! ("Block tiếp theo là toàn số 0" "ồ tôi đã có rồi" "block tiếp theo là toàn số 0" "ồ tôi đã có rồi") 16:26 <ailouros> hoặc một kho các tệp zip khác 16:26 <jrandom> hoặc ví dụ thẻ ID3 được sửa, v.v. 16:26 <ailouros> chính xác 16:26 <+polecat> Đúng. Nhưng cách dễ để "sửa" một phim có block hỏng là bảo bittorrent tải chồng lên nó. Hầu hết client sẽ giữ các block có hash giống và ghi đè những block khác. 16:26 <jrandom> nhưng archive các tệp có lẽ không hiệu quả, vì chúng sẽ phải tách theo ranh giới tệp 16:27 <ailouros> j636, đó là lý do tôi muốn triển khai ý tưởng của LBFS là chia theo dấu mốc dữ liệu chứ không theo kích thước block cố định 16:27 <@cervantes> cộng đồng DC dùng phương pháp đó, bằng cách chia sẻ bản phát hành tệp dưới dạng rarset 16:27 <+polecat> Có thể hữu ích là tạo một thuật toán sửa lỗi nhị phân tổng quát, rồi triển khai ở quy mô lớn. Tất cả block có thể được "sửa" thành nhau, và bạn chỉ cần truyền dữ liệu sửa, có thể nhỏ hơn truyền cả block. 16:29 <@cervantes> và tìm kiếm dựa trên tiger hash của các phần rar đó 16:29 <+Complication> Ý tưởng hay... nhưng nghe khó :) 16:29 <+polecat> Nhưng nếu chỉ là tương đương "hash-đổi-hash"... bạn sẽ chẳng bao giờ tìm được hai block giống nhau! 16:29 <ailouros> cervantes, "rarset" là gì vậy? :D (ngoài "tệp RAR" ra) 16:29 <+polecat> Trừ khi cả hai bên đều có tệp, một bên bị hỏng. 16:29 <ailouros> polecat, hả? 16:29 <@cervantes> ailouros: một archive rar được chia nhỏ, có tệp parity nếu cần 16:30 <ailouros> cervantes: Tôi không hiểu lợi ích của cách đó 16:31 <@cervantes> lợi ích chính là thêm tải kiểu giả đa nguồn cho DC 16:32 <ailouros> ừ, đó là một phần của cơ chế chia sẻ block giữa các tệp, đúng không? 16:34 <ailouros> polecat: về việc bittorrent ghi đè tệp hỏng, cái nó không giúp là khi bạn cố lấy nhiều phiên bản cùng lúc 16:35 <@cervantes> client của bạn chỉ khớp/tải các phần hợp lệ, nếu có tệp parity bạn cũng có thể phục hồi phần hỏng 16:35 <ailouros> với hệ thống của tôi thì không có phần hỏng (tệp chỉ được lắp ráp khi các block cấu thành đã tải xong và kiểm lại) 16:36 <@cervantes> những thứ bittorrent làm mặc định, trừ việc bạn không thể tìm cụ thể từng phần 16:36 <+polecat> Nhiều phiên bản khó mà có chung một bit nào... vì thế chúng khá ngớ ngẩn. Có kẻ tái mã hoá phim thành kích thước bằng con tem, và đặt cùng tên. 16:37 <+polecat> Hoặc kẻ khác lấy dữ liệu ngẫu nhiên rồi đặt tên theo tệp bạn muốn tải. 16:37 <ailouros> lol đúng thế 16:37 <@cervantes> chính xác và bản phát hành rarset miễn nhiễm với chuyện đó... 16:37 <ailouros> nhưng nhớ rằng tệp từ mạng khác (emule, kazaa, v.v.) thường bị hỏng 16:38 <+polecat> bản phát hành rarset không miễn nhiễm... 16:38 <+polecat> Bạn vẫn phải xác định rarset nào là đúng. 16:38 <ailouros> cervantes, rarset làm sao miễn nhiễm với kẻ đăng rác ngẫu nhiên? 16:38 <@cervantes> (miễn là bạn có nguồn tin cậy) 16:39 <@cervantes> vì một nhóm phát hành công bố hash/thông tin phân phối 16:39 <ailouros> hahaha cái đó dễ :D 16:39 <@cervantes> và thứ nào chất lượng kém sẽ bị đánh dấu là nuked, mọi người gỡ nó khỏi chia sẻ 16:40 <ailouros> cervantes, mấy thứ đó đồ chơi của tôi đã làm 16:40 <@cervantes> hay đấy 16:40 <ailouros> bạn lấy mô tả tệp từ nguồn đáng tin, bạn tải đa nguồn (multiget) tệp ngay 16:41 <@cervantes> nghe ổn ;-) 16:41 <ailouros> bạn không tìm kiếm tệp, nhưng có thể duyệt thư mục chia sẻ của từng người, vậy bạn có thể dùng web crawler và lưu đệm kết quả 16:42 <ailouros> tuy vậy có thể tôi sẽ thêm chức năng tìm kiếm trong tương lai nếu thấy cần 16:44 <ailouros> Tôi tin đồ chơi của tôi, nếu phát triển thành ứng dụng, có thể cung cấp khả năng lưu đệm và chịu lỗi mà freenet cố gắng cung cấp 16:44 <ailouros> như phân phối và lưu đệm nội dung tĩnh 16:45 <ailouros> bạn đọc blog của tôi, bạn lưu đệm và cung cấp lại cho người khác khi họ cần. bạn không làm gì hơn ngoài để nội dung ở đó 16:45 <ailouros> không thích nội dung? xóa nó là xong 16:45 <jrandom> hmm, vậy bạn thấy nó như một backing store (kho lưu trữ nền) có thể dùng cho syndie chứ? 16:46 <ailouros> NÓ CÓ THỂ dùng làm backing store 16:46 <ailouros> với trạng thái hiện tại, bạn thậm chí có thể dùng nó thay jetty, trong cài đặt mặc định i2p 16:46 <jrandom> vd. đính kèm / liên kết tới [clunk hash="$foo"]my file[/clunk] 16:46 <ailouros> (ừ với vài thay đổi nhỏ :D ) 16:46 <jrandom> hehe 16:47 <jrandom> ok, đúng là tôi chưa hiểu clunk hoạt động ra sao... muốn đăng về nó trên syndie, hoặc dựng một eepsite? :) 16:47 <ailouros> hash của tệp sẽ được tải khi yêu cầu tệp, và các hash này sẽ được tự động "tải thành" tệp đầy đủ 16:48 <jrandom> đúng, nhưng "tải xuống" là câu hỏi từ đâu đến đâu, v.v. một mô tả kiến trúc mạng tổng quan sẽ hữu ích 16:48 <ailouros> Tôi sẽ viết tài liệu tử tế trước, rồi công bố đâu đó 16:48 <jrandom> r0x0r, cảm ơn 16:48 <ailouros> tải từ bất cứ đâu bạn lấy hash 16:48 <ailouros> cộng với mọi người khác đang chia sẻ các block này 16:49 <ailouros> nghĩ như go!zilla và download accelerator :) 16:49 <jrandom> Tôi nghĩ bạn đánh giá thấp mức tôi đang bối rối 16:49 <ailouros> nhưng trong suốt và trong i2p 16:49 <ailouros> lol chắc vậy :D 16:50 <jrandom> một giải thích rất, rất cơ bản kiểu vd. "bạn chạy client clunk, tải từ server clunk, lấy thông tin về các peer clunk", v.v. 16:50 <jrandom> Tôi dùng trình duyệt web để truy vấn client clunk? hay server? hay peer? 16:51 <jrandom> (tôi lạc mức đó đấy) 16:51 <ailouros> làm lại từ 0 :) 16:51 <ailouros> bạn dùng trình duyệt web của bạn 16:51 <ailouros> bạn kết nối tới client của bạn 16:51 <ailouros> bạn duyệt thư mục của người khác bằng trình duyệt 16:51 <ailouros> bạn chọn tệp để tải bằng trình duyệt 16:51 <ailouros> client của bạn làm phần việc nặng 16:52 <ailouros> bạn nhận lại tệp đã tải 16:52 <ailouros> thế này ổn hơn chưa? :) 16:52 <jrandom> ok hay, cảm ơn - vậy "duyệt thư mục của người khác" là do client của bạn truy vấn client của họ và trả về một biểu diễn HTML của nó 16:52 <ailouros> chính xác 16:52 <jrandom> (hoặc lấy từ server/superpeer/v.v.) 16:53 <jrandom> được đấy 16:53 <ailouros> tất cả phần việc nặng (tìm trùng lặp, tải đa nguồn và v.v.) do client (cục bộ) của bạn xử lý một cách trong suốt 16:54 <ailouros> những gì bạn thấy cơ bản là một cây thư mục và vài tệp bạn có thể tải 16:54 <jrandom> hay 16:55 <ailouros> để công bố dữ liệu bạn đưa địa chỉ (p2p) công khai của bạn 16:55 <ailouros> và để chia sẻ tệp bạn copy chúng (hoặc symlink chúng) vào thư mục pub/ (hoặc thư mục con nào đó). Dễ vậy thôi 16:57 * jrandom sẽ đào sâu source thêm, và mong có thêm thông tin :) 16:57 <jrandom> ok, còn ai có gì cho buổi họp không? 16:57 <bar_> ờm.. khác nhau giữa công bố và chia sẻ là gì, nếu tôi có thể hỏi? công bố có đẩy dữ liệu vào một kho nào không? 16:58 <ailouros> bar_: chia sẻ là cho tải các block. công bố là cho thế giới biết bạn chia sẻ gì 16:58 <ailouros> công bố là tập con của chia sẻ 16:58 <bar_> à, hiểu rồi, cảm ơn 16:58 <ailouros> ví dụ, nếu bạn có nửa tệp, bạn chia sẻ nó nhưng không công bố 16:59 <jrandom> vậy làm sao người ta biết họ có thể lấy các block đó từ bạn? 16:59 <ailouros> và bạn hoàn toàn kiểm soát tệp nào bạn công bố (không như emule nơi mọi tệp đã tải đều được công bố) 16:59 <ailouros> vì mỗi client định kỳ gửi thông tin lên mạng về các block nó có để cung cấp 17:00 <jrandom> hay đấy 17:00 <ailouros> gửi lên mạng tức là tới server (hiện tại) hoặc DHT (tương lai) 17:00 <jrandom> vậy nó hơi giống mnet, với một bộ theo dõi block 17:00 <ailouros> ờ giống mnet? 17:01 <jrandom> giống cách mnet (mnetproject.org) hoạt động 17:01 * ailouros đang đọc mnetproject.org 17:02 <ailouros> ừ, bạn chỉ có không gian cá nhân, không có không gian chia sẻ 17:02 <ailouros> và bạn không "PUSH" block đi khắp nơi 17:02 <jrandom> ừ, không giống hệt mnet, nhưng tương tự về cấu trúc 17:03 <jrandom> nó như mnet nơi ai cũng quá "cháy túi" để có người khác host dữ liệu của họ ;) 17:03 <ailouros> đúng 17:03 <ailouros> :D 17:03 <jrandom> ok, còn ai có gì khác muốn nêu? 17:04 <jrandom> nếu không... 17:04 * jrandom thu xếp 17:04 * jrandom *baf*s kết thúc cuộc họp