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

16:09 <jrandom> 0) chào 16:09 <jrandom> 1) Tình trạng mạng và 0.6.1.16 16:09 <jrandom> 2) Tạo tunnel và nghẽn 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) chào 16:10 * jrandom vẫy tay 16:10 <jrandom> ghi chú tình trạng hàng tuần đã đăng tại http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk cũng vậy 16:10 <jrandom> (gần hai giờ *trước* cuộc họp nữa :) 16:11 <jrandom> ok, vì tôi chắc mọi người đã nghiền ngẫm các ghi chú rồi, hãy vào 1) Tình trạng mạng 16:12 <+Complication> Chào :) 16:12 * Complication nhanh chóng lấy ghi chú 16:12 <jrandom> bản phát hành 0.6.1.16 đã sửa một lỗi tồn tại rất lâu trong prng (bộ tạo số giả ngẫu nhiên), vốn đã gây ra một số lượng đáng kể các từ chối tunnel ngẫu nhiên 16:13 <jrandom> (nguyên nhân gốc bị đưa vào tháng 10 năm ngoái, nhưng giờ đã sửa) 16:13 <+Complication> Bên tôi: hoạt động tạm ổn với tunnel 1 + 0..1 hop, không chịu với 2 + 0..1 hoặc 2 +/- 0..1 16:14 <jrandom> ừ, điều đó cũng dễ hiểu, nhất là trên kết nối chậm hơn 16:14 <jrandom> (không may là “chậm hơn” cũng chẳng phải quá chậm đâu) 16:15 <jrandom> vẫn còn nhiều việc phải làm, và 0.6.1.16 chưa đạt mức chúng ta cần, nhưng đó là tiến bộ 16:17 <+Complication> Tôi đã nghĩ về điều bạn gọi là “sụp đổ do nghẽn (congestion collapse)” 16:18 <+Complication> Một cách để hạn chế tác động của nó có thể là thực sự yêu cầu một router chấp nhận một hạn ngạch nhất định các yêu cầu tham gia 16:19 <+Complication> (do người dùng chỉ định trực tiếp hoặc gián tiếp?) 16:19 <jrandom> do người dùng nào chỉ định? 16:19 <+Complication> (ví dụ một phần của tỷ lệ chia sẻ hoặc tham số bổ sung) 16:19 <jrandom> người dùng cục bộ, hay do chúng ta với tư cách người dùng từ xa? 16:19 <+Complication> Mỗi người tự chỉ định cho mình 16:19 <@frosk> chúng ta chuyển sang 2) chứ? :) 16:20 <jrandom> ừ, coi như chúng ta đang ở mục 2) :) 16:20 <+Complication> Để tôi có thể, ví dụ, bảo router của mình "dù bạn đang nghẽn, hãy tiếp tục định tuyến tối thiểu 4 KB/s" 16:21 <jrandom> Complication: điều đó không thực sự khả thi - nếu một router quá nghẽn, những người khác (hy vọng vậy ;) sẽ ngừng yêu cầu họ tham gia vào tunnels. 16:21 <+Complication> (điều này tất nhiên có thể khiến một đích cục bộ nào đó ngoại tuyến lâu hơn) 16:21 <jrandom> và nếu họ không được yêu cầu, họ /không thể/ đẩy dữ liệu của người khác 16:22 <+Complication> À, có lẽ tôi nên diễn đạt rõ ràng hơn 16:24 <+Complication> Tôi hình dung rằng, dưới một hạn ngạch nhất định của lưu lượng tham gia, nó có thể hạn chế (throttle) các thông điệp tạo tunnel của chính nó thay vì các tunnels tham gia 16:24 <+Complication> ví dụ "Tôi sẽ không bao giờ throttle các participating tunnels của mình xuống dưới 4 KB/s. Nếu cần như vậy, tôi sẽ throttle lưu lượng của riêng tôi." 16:26 <jrandom> hmm, có rủi ro về ẩn danh trong đó (dù vẫn cùng hướng với DoS có chọn lọc, mà chúng ta vốn cũng không phòng vệ) 16:27 <jrandom> nhưng việc throttle các build tunnel cục bộ khi đối mặt với nghẽn là điều tôi đang thử nghiệm - thêm hỗ trợ để tuỳ chọn bỏ qua ngưỡng sàn 4KBps chắc khá đơn giản 16:28 <spinky> Hiện tại, bạn không có cover traffic (lưu lượng che) nào khi truyền nhiều dữ liệu. 16:29 <spinky> Có một sàn cho băng thông tham gia nghe có vẻ hay. 16:30 <jrandom> thực ra, chúng ta có một sàn (vừa theo tỷ lệ chia sẻ vừa có 4KBps nội bộ được dành riêng sau khi phân bổ hết băng thông) 16:30 <+Complication> Chà, mất kết nối... Tôi hy vọng không mất nhiều trong những gì tôi nói, còn các trả lời tôi sẽ đọc từ log :) 16:32 <@frosk> có điều gì đặc biệt về 4KBps không? 16:33 <jrandom> vài điều - 4KB ~= kích thước (sizeof) của thông điệp tạo tunnel, và theo kinh nghiệm, tôi chưa từng nghe router nào chạy thành công với ít hơn 16:33 <spinky> Có lẽ là các lỗi khiến tỷ lệ chia sẻ không hoạt động chăng? 16:34 <jrandom> vì sao bạn nói tỷ lệ chia sẻ không hoạt động? 16:34 <@frosk> tôi hiểu 16:34 <+Complication> frosk: không, nó chỉ là một con số trong mã hiện tại, và tôi nhắc đến nó trong khi cố gắng giải thích điều tôi hình dung nữa 16:35 <+Complication> (không phải vì lý do có ý nghĩa, chỉ vì điều tôi hình dung theo một nghĩa nào đó là đối nghịch của nó) 16:35 <spinky> Nó đặt là 80% và mức tham gia về 0 khi tạo dữ liệu cục bộ. Có lẽ tôi hiểu sai. 16:36 <jrandom> à, đúng, đó không phải là những gì tỷ lệ chia sẻ làm 16:36 <+Complication> spinky: đó là giới hạn tối đa của những gì có thể chia sẻ, phụ thuộc vào băng thông thực sự còn lại để chia sẻ 16:37 <+Complication> Nếu lưu lượng cục bộ chiếm 70%, bạn chỉ còn 10% để chia sẻ 16:37 <+Complication> Nếu lưu lượng cục bộ nặng, bạn sẽ còn 0%, và mức trần 80% sẽ không bao giờ chạm tới 16:37 <spinky> Ok. Tôi thấy nó ghi 'tối đa'... 16:38 <+Complication> Và còn có phần dự trữ 4 KB/s 16:38 <jrandom> à, đó là tỷ lệ chia sẻ trên phần bạn còn sẵn 16:38 <spinky> Có lẽ thêm một thiết lập cho sàn băng thông tham gia, dưới mức đó router sẽ chấp nhận thêm tunnels? 16:38 <jrandom> nếu bạn đang dùng 95% băng thông, nó sẽ chia sẻ tối đa 80% của 5% còn lại 16:39 <+Complication> Ồ, vậy tôi cũng hiểu sai một phần 16:40 <fox> <zorglu1> i2p đo lượng băng thông do các ứng dụng cục bộ khác dùng như thế nào ? 16:40 <spinky> (Chỉ nói là, nếu bạn coi cover traffic là điều tốt thì có lẽ việc cho cấu hình nó ngay cả khi băng thông cục bộ nặng cũng là điều tốt) 16:40 <+Complication> Tôi tưởng nó áp dụng đối với giới hạn duy trì 16:40 <jrandom> zorglu1: nó đo việc sử dụng băng thông của i2p, và biết các giới hạn băng thông của i2p 16:41 <jrandom> ồ, hmm, xem lại mã, int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> vậy bạn đúng rồi, Complication 16:42 <jrandom> spinky: cover traffic chỉ hữu ích ở mức nào đó trên một mixnet (mạng trộn) độ trễ thấp 16:42 <jrandom> nó có thêm động lực cho các router băng thông cao, nhưng những router không dư băng thông thì ít có cách 16:49 <jrandom> dù sao, vấn đề nghẽn tunnel đã tồn tại một thời gian, nhưng chỉ gần đây bị trầm trọng bởi tỷ lệ từ chối tunnel quá cao 16:49 <jrandom> hy vọng bản kế tiếp sẽ giải quyết 16:49 <jrandom> ok, còn gì về 2) tạo tunnel và nghẽn không? 16:50 <@frosk> nghe như sẽ cần một số thay đổi với sơ đồ xây dựng tunnel 16:50 <+Complication> Tôi hy vọng nó sẽ giúp cải thiện :) 16:51 <+Complication> À, nhân tiện... 16:52 <jrandom> chúng ta có vài bản vá rẻ, như giảm độ đồng thời tối đa, throttle các lần thử build khi nghẽn, giảm tần suất drop (thay vì từ chối rõ ràng), và điều chỉnh profiling để khuyến khích từ chối rõ ràng thay vì drop 16:52 <+Complication> ...bạn có tình cờ tìm thấy điều gì giải thích sự chênh lệch lớn giữa chỉ số băng thông thô và chỉ số payload của tunnel không? 16:52 <+Complication> (ví dụ băng thông tổng 1 GB, payload tunnel cộng lại 300 MB) 16:52 <jrandom> nhưng đúng, những thứ đó chỉ ảnh hưởng đến độ lớn 16:52 <+Complication> (vì tôi không ở IRC gần đây, tôi không chắc bạn đã xem chuyện đó chưa) 16:54 <jrandom> chưa đào sâu lắm, nhưng nhớ rằng, các yêu cầu build tunnel cho outbound tunnels không phải là thông điệp tunnel (và có rất nhiều nếu chỉ .1% thành công. và mỗi cái 4KB...) 16:54 * Complication không chắc đó là do chỉ số hay là hiệu ứng thực 16:55 <+Complication> Ồ... yêu cầu build outbound... đúng vậy 16:55 <jrandom> bản build -1 sắp tới thêm một loạt thống kê để giám sát gói theo từng loại thông điệp 16:55 <+Complication> Đó có thể chính là nó 16:55 <jrandom> (trong các yêu cầu build outbound đó cũng có cả các yêu cầu tham gia build - chuyển tiếp một phản hồi) 16:56 <jrandom> ((vậy nên không chỉ là thứ cục bộ)) 17:00 <+Complication>> Cảm ơn, điều đó giải thích được rất nhiều :) 17:00 <+Complication>> Vậy thì không phải bùa chú gì, mà là lưu lượng thật, tôi chỉ quên vì nó không được tính riêng ở nơi tôi xem 17:00 <+Complication> Nó thực sự sẽ xảy ra, và thật sự tốn rất nhiều byte 17:00 <+Complication> Đặc biệt khi tỷ lệ thành công thấp 17:01 <jrandom> ừ, dù không nên tốn nhiều như hiện tại, vì lẽ ra chúng ta phải có tỷ lệ thành công cao hơn :) 17:01 <jrandom> ok, còn gì ở mục 2) không? 17:02 <jrandom> nếu không, chuyển sang 3) Feedspace 17:02 <jrandom> frosk: cho bọn mình cập nhật chứ? 17:03 <jrandom> (hoặc bảo bọn mình fsck off và đọc eepsite? ;) 17:04 <@frosk> à, với những ai chưa chú ý đến frosk.i2p hoặc feedspace.i2p, feedspace hiện hoạt động cơ bản (theo định nghĩa “cơ bản” của tôi) 17:04 <jrandom> (w00t) 17:05 <@frosk> gần đây có vài bổ sung hay, như hỗ trợ hạ tầng cho các transport ngoài i2p (nghĩ tới tor và tcp/ip không ẩn danh) 17:06 <@frosk> vậy theo thời gian, chúng tôi dự định cho phép syndie (trong một bản viết lại sắp tới và có lẽ rất hay) dùng feedspace như một trong các phương thức syndication 17:06 <@frosk> hiện chưa có ứng dụng khách nào thật sự dùng feedspace cho mục đích gì :) tôi đang thử nghiệm với một ứng dụng servlet cực kỳ thô sơ 17:07 <jrandom> (crude + functional)++ 17:07 <@frosk> vậy tất nhiên có một chỗ trống cho một hacker phía client ;) 17:08 <@frosk> vẫn còn vài thứ cần thiết mà feedspace phải có trước khi thử công khai, nhưng chắc không lâu nữa :) 17:08 <jrandom> được đấy 17:08 <jrandom> có gì bọn mình có thể giúp không? 17:08 <@frosk> tôi cũng đang làm chút tài liệu, vốn còn thiếu 17:09 <spinky> Bạn thấy feedspace có dùng được cho tệp lớn không? 17:10 <@frosk> 1) ứng dụng khách dùng xmlrpc api (vẫn chưa được viết tài liệu), 2) http://feedspace.i2p/wiki/Tasks, 3) tham gia thử nghiệm khi đến lúc 17:10 <@frosk> hỗ trợ tệp lớn chưa là ưu tiên, nhưng có lẽ sau này 17:10 <@frosk> trọng tâm cho “1.0” là các thông điệp nhỏ hơn như bài blog, bài thảo luận, và các sự kiện các kiểu 17:11 <jrandom> dù việc đưa tệp .torrent vào một client bt hỗ trợ rss/feedspace thì không vấn đề 17:11 <@frosk> tệp lớn có thể hoạt động hoặc không :) 17:11 <@frosk> điều đó sẽ rất ngầu 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> tôi hy vọng sẽ thấy đủ loại ứng dụng “adapter” như vậy :) 17:12 <+Complication> Chà, tôi chắc mọi người sẽ tìm ra cách chuyển tệp lớn bằng những kênh phụ... :) 17:15 <@frosk> tôi thấy hơi áy náy vì mã feedspace dùng đủ loại tính năng java1.5. có lẽ sẽ khó biên dịch/dùng trên free java lúc này, nhưng rồi sẽ bắt kịp thôi tôi chắc vậy :) 17:15 <jrandom> ôi 17:16 <jrandom> à, có tin đồn gcj sẽ dùng ecj cho các 1.5-isms 17:16 <spinky> Complication: Ngựa mang túi yên đầy ổ cứng hdds? 17:16 <@frosk> đúng vậy 17:17 <+Complication> spinky: drone, theo tôi thì thích hơn :P 17:17 * jrandom vẫn chỉ vừa nhích lên 1.4-isms 17:17 <+Complication> Nhưng chắc ngựa cũng ổn :P 17:17 <jrandom> mặc dù 1.6 thì chắc chắn là hay ;) 17:17 <@frosk> để giữ tương thích với gcj? 17:18 <@frosk> ờ 1.6 cũng không có nhiều “isms” cho hầu hết mọi thứ đâu tôi nghĩ vậy :) 17:18 <+Complication> (hoặc nhím biết bay thả dù thẻ nhớ) 17:18 <jrandom> gcj/classpath/etc, nhưng cũng vì hiệu năng (tôi thấy 1.5 nặng hơn 1.4 một chút) 17:19 <jrandom> đúng, cải tiến của 1.6 phần lớn là cụ thể ở vm/bytecode 17:19 <@frosk> hm ok 17:20 * jrandom không cố gắng thuyết phục bạn đừng dùng 1.5isms đâu. tôi chắc bạn có lý do, và ví dụ azureus đã yêu cầu 1.5 rồi 17:21 <@frosk> ừ không quay lại được nữa :) hy vọng sẽ không quá gập ghềnh 17:24 <jrandom> ừ, tôi chắc sẽ ổn thôi :) 17:25 <jrandom> ok hay đấy, còn gì về 3) feedspace không? 17:25 * frosk ôm chặt generics và java.util.concurrent ;) 17:25 <jrandom> heheh 17:27 <jrandom> ok, nếu không còn gì ở mục 3, chuyển sang 4) ??? 17:27 <jrandom> có ai còn gì cho cuộc họp không? 17:27 <+Complication> Một câu hỏi nhỏ lẽ ra tôi nên hỏi ở mục 2) 17:28 <+Complication> Bạn biết không, các participating tunnels nhàn rỗi thường hình thành như thế nào? 17:28 <+Complication> Chúng chủ yếu là dấu hiệu của các build tunnel thất bại, nơi chỉ người tạo thực sự biết nó thất bại? 17:28 <+Complication> Hay còn lý do nào khác? 17:28 <+Complication> (ngoài điều hiển nhiên - tức là một ứng dụng đang rảnh) 17:29 <jrandom> một ứng dụng rảnh sẽ không có tunnels rảnh (chúng sẽ được kiểm tra) 17:29 <jrandom> các tunnels rảnh là bị lỗi vì lý do nào đó 17:29 <jrandom> (hoặc không tạo xong, hoặc hỏng trong khi vận hành) 17:30 <+Complication> Đúng, nên mọi tunnel đều được kiểm tra, và việc kiểm tra tunnel sẽ tạo ra lưu lượng... đúng vậy 17:30 <+Complication> Điều đó dẫn tôi đến phần hai của câu hỏi: liệu có lợi ích gì khi nhận thấy một tunnel đang rảnh và loại bỏ sớm không? 17:31 <+Complication> Có tài nguyên quý nào được tiết kiệm ở đó không? 17:32 <jrandom> không - một tunnel không đẩy dữ liệu thì không tiêu tốn tài nguyên 17:32 <jrandom> (ok, nó dùng một ít RAM, có lẽ 32 byte) 17:32 <+Complication> Hoặc có thể giúp một router giữ bức tranh tốt hơn về tải và các tham số tương tự... 17:33 <jrandom> dự đoán việc dùng băng thông dựa trên lịch sử tunnel chắc chắn vẫn là câu hỏi mở 17:33 <+Complication> Hay chỉ là việc vô ích, tốt nhất chờ nó hết hạn tự nhiên? 17:33 <+Complication> (như hiện nay) 17:34 <jrandom> chúng tôi từng dự đoán, nhưng không mang lại lợi ích rõ ràng, nên giờ dùng thuật toán đơn giản hơn 17:34 <+Complication> Aha, vậy là không có lợi ích... 17:34 <+Complication> Cảm ơn, đó cơ bản là tất cả điều tôi muốn hỏi :) 17:34 <jrandom> không vấn đề, băn khoăn dễ hiểu 17:34 <jrandom> ok, còn ai có gì cho cuộc họp không? 17:35 <+Complication> Đúng, nếu dự đoán, tỷ lệ tunnels rảnh có thể làm lệch ước tính 17:35 <+Complication> (nếu nó biến thiên đáng kể) 17:36 <jrandom> ừ, ta sẽ muốn giữ % rảnh như một phần của ước tính 17:36 <jrandom> (chúng tôi từng làm - xem phương thức RouterThrottleImpl.allowTunnel) 17:37 <+Complication> Ồ, tôi không biết :) 17:37 <jrandom> và lưu ý bình luận mới: 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication vẫn đang duyệt tới tệp, nhưng cảm ơn :) 17:39 <jrandom> w3rd 17:40 <jrandom> ok, nếu không còn gì cho cuộc họp... 17:40 * jrandom kết thúc 17:41 * jrandom *baf* đóng cuộc họp