Cuộc họp các nhà phát triển I2P - 30 tháng 5, 2006

16:00 <jrandom> 0) chào 16:00 <jrandom> 1) Tình trạng mạng 16:00 <jrandom> 2) Peer filtering (lọc nút ngang hàng) 16:00 <jrandom> 3) Tình trạng Syndie 16:00 <jrandom> 4) ??? 16:00 <jrandom> 0) chào 16:00 * jrandom vẫy tay 16:01 <jrandom> ghi chú trạng thái hàng tuần đã đăng @ http://dev.i2p.net/pipermail/i2p/2006-May/001291.html 16:01 <jrandom> (đăng sớm trước 1 giờ [hoặc muộn vài tuần, nếu muốn bắt bẻ tôi ;]) 16:02 <jrandom> ok, cùng bắt đầu vào 1) Tình trạng mạng 16:02 <jrandom> mọi thứ không đúng như lẽ ra phải thế. tốt hơn so với lúc sụp đổ vì tắc nghẽn, nhưng vẫn nên tốt hơn hiện tại 16:03 <jrandom> tôi không có nhiều để bổ sung về chuyện đó, trừ khi ai có câu hỏi/quan ngại về mục 1)? 16:03 <@frosk> tôi có kết nối irc kéo dài nhiều ngày với .19, nên không có gì phàn nàn ở đây 16:04 <jrandom> hay đấy 16:04 <jrandom> ừ, nó tốt với một số người, chỉ là chưa đủ tốt hoặc chưa đủ ổn định. thống kê trong CSDL trông cũng không đẹp lắm 16:06 <jrandom> ok, ai còn gì khác về 1) Tình trạng mạng, hay ta chuyển sang 2)Peer filtering? 16:07 <jrandom> [chèn tiếng chuyển động ở đây] 16:09 <jrandom> như đã nói trong mail, ý chính là tăng cường một chút cho việc chọn peer. ban đầu sẽ hơi nguy hiểm, cho phép một số tấn công phân hoạch chủ động, nhưng nếu mọi thứ chạy như tôi hy vọng, ta có thể tránh được 16:10 <jrandom> (nhưng để tránh điều đó thì về cơ bản phải “giết” toàn bộ các identity của router, điều này sẽ như một lần đặt lại mạng, nên tôi muốn tránh trừ khi đáng giá) 16:11 <bar> đặt lại chúng một lần hay lặp lại? 16:11 <bar> s/reset/killing 16:11 <jrandom> ít nhất một lần, và cả khi có mọi thay đổi cấu hình mạnh về sau 16:12 <jrandom> (tức là đưa một số tiêu chí vào chứng thư của router identity, và như vậy nghĩa là thay đổi hash định danh, để họ không thể giả vờ đẩy một thiết lập cho một số người và thiết lập khác cho những người khác) 16:13 <bar> hiểu rồi 16:14 <jrandom> ok, tôi nghĩ hiện tại không còn gì thêm về chủ đề đó, trừ khi ai có câu hỏi/bình luận/quan ngại? 16:15 <jrandom> (hy vọng sẽ có một bản dựng trong một hai ngày tới, phát hành sau khi ổn định) 16:17 <jrandom> ok, lướt qua 3) nhanh thôi.. 16:18 <jrandom> Syndie đang tiến triển, và dù cuộc chiến amd64/amd32/x86/swt/gcj không phải lúc nào cũng đẹp, chúng tôi sẽ có bản dựng sẵn vào tháng 6 16:19 <jrandom> (nhưng đừng nói với tôi về mingw/gcj ;) 16:19 <jrandom> tôi không có nhiều để bổ sung ở đó lúc này, trừ khi ai có câu hỏi/quan ngại về việc đại tu Syndie? 16:21 <@cervantes> hỗ trợ mingw/gcj tiến triển thế nào? 16:21 <@cervantes> *né* 16:22 <@cervantes> chúng ta có một số ảnh chụp màn hình trước khi phát hành tháng 6 chứ? :) 16:23 <jrandom> chắc tôi sẽ cố lôi kéo vài tình nguyện viên háo hức vào kiểm thử trước phát hành ;) 16:23 <tethrar> tính tôi một vé ;) 16:23 <jrandom> w3wt 16:24 <jrandom> ok, chuyển sang gạch đầu dòng mà tôi biết mọi người đều chờ: 4) ??? 16:24 <jrandom> wazaaaap? 16:24 <green> Có kế hoạch nào để có một I2P router "thực sự" chạy được với Via C7 không? jbigi chỉ cho hiệu năng tốt hơn Java thuần 30% 16:25 <jrandom> 30% vẫn quá ngốn CPU ư? điều gì khiến nó không "real"? 16:25 <jrandom> nhưng không, tôi không có kỹ năng toán hay asm C7 để làm một libGMP tốt hơn cho C7. 16:25 <green> chắc chắn là quá nặng CPU với mức tải CPU 100% :P 16:26 <jrandom> mức tải CPU 100% gợi ý rằng vấn đề không nằm ở jbigi, mà là jbigi bị dùng quá nhiều 16:26 <jrandom> và về điểm đó, vâng, chúng tôi có nhiều thứ đang trên đường tới. 16:26 <jrandom> (ví dụ: giảm việc tái lập kết nối, cải thiện tỷ lệ thành công khi dựng tunnel, v.v.) 16:27 <jrandom> ((và giảm nhận các yêu cầu tunnel nếu router không đủ khả năng xử lý chúng)) 16:29 <green> ừm, đây là máy chuyên dụng với 100Mb/s nên lẽ ra phải xử lý được 16:30 <jrandom> không, băng thông không phải tài nguyên bị giới hạn duy nhất ở đây, CPU rõ ràng cũng vậy ;) 16:33 <jrandom> ok, ai còn gì nữa cho cuộc họp không? 16:36 <jrandom> *khụ* 16:37 * jrandom chuẩn bị kết thúc 16:37 * jrandom *baf* đóng cuộc họp