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

16:21 <jrandom> 0) chào 16:21 <jrandom> 1) Tình trạng mạng và 0.6.1.14 16:21 <jrandom> 2) Lên kế hoạch cho Syndie 16:21 <jrandom> 3) Tối ưu hóa jbigi cục bộ 16:21 <jrandom> 4) ??? 16:21 <jrandom> 0) chào 16:21 * jrandom vẫy tay 16:21 <jrandom> ghi chú trạng thái hàng tuần đã đăng tại http://dev.i2p.net/pipermail/i2p/2006-April/001275.html 16:21 * Complication đọc 16:22 <jrandom> trong khi mọi người đọc bài đó (viết vội), hãy nhảy vào 1) Tình trạng mạng 16:23 <@cervantes> (diễn đàn đã hoạt động lại) 16:23 <jrandom> có vài vấn đề ảnh hưởng đến việc sử dụng trên 0.6.1.13, và hầu hết chúng đã được truy ra và giải quyết 16:24 <Complication> Bên này, với bản build "thứ tư" của CVS, tôi thấy đồ thị của mình thay đổi 16:24 <jrandom> vẫn còn vài chỗ rắc rối đang được thử nghiệm và chỉnh sửa, nhưng bản phát hành sẽ ra trong vài ngày tới 16:24 <Complication> Nhìn chung, mọi thứ ổn định hơn và ít dao động hơn 16:24 <jrandom> ôi chết, tôi quên tăng nó lên -4 phải không? 16:24 <jrandom> (ok, -5 sẽ ra vào tối nay) 16:24 <jrandom> hay lắm, Complication 16:25 <Complication> Nhưng cảm nhận của tôi cũng có thể bị ảnh hưởng bởi jbigi, vì tôi chưa loại trừ yếu tố đó 16:25 <Complication> Giờ, sau một lúc, tỷ lệ truyền lại đã giảm xuống còn 15% 16:28 <jrandom> hmm, tôi cũng thấy RTO (thời gian chờ truyền lại) của ssu trung bình tiến gần ngưỡng 3s 16:28 <jrandom> (tuy nhiên tỷ lệ truyền lại vẫn rất thấp, dưới 5%) 16:29 * Complication xem lại lần nữa 16:29 <Complication> Giả sử trung bình thô là hơn 1500 một chút 16:29 <Complication> (bên tôi) 16:30 <+fox> <BrianR___> jrandom: Có "MTU" thực tế cho gói i2p không? 16:30 <jrandom> à ok, có lẽ khi cái đó tăng dần, tỷ lệ truyền lại sẽ giảm 16:30 <Complication> Tôi thấy của tôi bắt đầu với MTU nhỏ hơn, giờ đã tăng lên khoảng 1350 16:30 <jrandom> BrianR___: vâng, hoặc 1350 hoặc 608 (như hiển thị tại `http://localhost:7657/peers.js)` 16:31 <jrandom> nếu tỷ lệ lỗi quá cao ở MTU lớn, nó sẽ lùi về MTU nhỏ hơn (và nếu quá thấp ở MTU nhỏ, nó sẽ nhảy lên MTU lớn hơn) 16:31 <+fox> <BrianR___> jrandom: Vậy đó là cho payload (tải trọng) bên trong hay cho các gói IP nhìn thấy được? 16:31 <+fox> <BrianR___> Ví dụ, nếu tôi gửi một khối dữ liệu qua một luồng I2P, kích thước khối lý tưởng là bao nhiêu để giảm chi phí phụ trội? 16:31 <jrandom> đó là cho payload UDP 16:32 <jrandom> các stream ở cao hơn hai lớp 16:32 <jrandom> (có phân mảnh ở các tunnel, rồi phân mảnh ở cấp stream/i2cp) 16:32 <+fox> <BrianR___> Đúng... Có kích thước lý tưởng để giảm phân mảnh không? 16:32 <jrandom> kích thước khối lý tưởng của một ứng dụng dùng streaming lib (thư viện xử lý luồng) là "lớn", để streaming lib có thể dùng kích cỡ phù hợp. 16:33 <jrandom> (hay còn gọi là cứ bỏ qua người đằng sau tấm rèm) 16:33 <+fox> <BrianR___> À... Có lẽ tôi nên nghĩ về pipelining hay gì đó... 16:34 <+fox> <BrianR___> Tôi đang lên kế hoạch một ứng dụng có rất nhiều lưu lượng request/response... 16:34 <jrandom> tôi khuyên nên gom lô để giảm tính "chatty" 16:34 <Complication> Có lẽ tập trung lưu lượng sẽ giúp phần nào 16:37 <jrandom> ok, còn gì về 1) Tình trạng mạng không, hay ta lắc lư sang 2) Lên kế hoạch cho Syndie 16:38 * jrandom lắc lư 16:39 <jrandom> đoạn này chủ yếu là giữ chỗ và kêu gọi đề xuất (cfp) - sẽ có một đợt đại tu đáng kể cho syndie, cả về vận hành lẫn ui, nên nếu bạn có tính năng chủ chốt hoặc use case cần giải quyết, hãy liên hệ 16:40 <jrandom> (tất nhiên sẽ có thêm thông tin khi mọi thứ được hoàn thiện hơn) 16:42 <jrandom> đó là tất cả về mục đó lúc này, vậy chuyển sang 3) tối ưu hóa jbigi 16:42 <@frosk> và tôi đã tưởng "plotting" là nói tới vài thứ jrobin trong syndie :) 16:43 <jrandom> hehe 16:43 <jrandom> sẽ thú vị nếu vẽ đồ thị bài viết/ngày, bài viết/tác giả, tác giả mới/ngày, v.v. ;) 16:44 <Complication> À, một ý về Syndie (xin lỗi, giờ tôi mới nhớ) 16:44 <Complication> =một ý 16:44 <@frosk> bạn muốn 0 hay 1? :) 16:44 <Complication> Bạn nghĩ có thực tế không, và dễ/khó thế nào nếu tách tác giả ưa thích và tác giả bị đưa vào blacklist (spam) thành hai danh sách khác nhau? 16:45 <Complication> Trên addresses.jsp 16:45 <jrandom> ồ, được, không khó lắm 16:46 <jrandom> đó cũng là ý hay cho đợt đại tu, nhưng có lẽ ta có thể đưa nó vào bản build 0.6.1.14 16:47 <Complication> Không, nó không làm tôi bận tâm, tôi chỉ vừa nhớ ra điều từng nhận thấy 16:47 <Complication> Dù sao, jbigi chạy nhanh hơn trên Linux/AMD64 khi bạn biên dịch local và dùng GMP 4.2 16:48 <jrandom> hay đấy 16:48 <jrandom> bạn đã so sánh với -O3 -m64 trên GMP 4.1.2 chưa? 16:48 <Complication> Và tôi thật ngốc khi dùng nhầm cờ biên dịch quá đỗi sai :O 16:48 <@cervantes> liên kết liên quan là `http://forum.i2p/viewtopic.php?t=1523&start=30` nhân tiện 16:48 <jrandom> à cảm ơn cervantes 16:48 <Complication> jrandom: tôi chưa so sánh, nhưng sẽ làm 16:49 <Complication> Trong lần khởi động lại theo lịch tiếp theo 16:50 <jrandom> quy trình build jbigi về cơ bản là "build GMP, rồi build jbigi.o, và liên kết hai thứ lại", nên mọi tối ưu hóa muốn áp dụng cho GMP đều có thể thực hiện ở bước đầu tiên 16:50 <@cervantes> Tôi không thấy khác biệt nhiều giữa -O3 và -O2 trong các thử nghiệm trước đây tôi làm; không biết dưới x86_64 thì khác không... *nhún vai* 16:50 <jrandom> ừ, cũng có thể phụ thuộc vào bản compiler 16:50 <jrandom> (đặc biệt với tất cả các vấn đề 3.3/3.4/4.0/4.1 này) 16:51 <@cervantes> nhắc lại điều tôi đã nói trong thread đó... có lẽ sẽ chưa sớm có jbigi tối ưu cho windows64 16:51 <+fox> <BrianR___> Thư viện stream i2p có nén payload không? 16:52 <Complication> BrianR: có 16:52 <@cervantes> trừ khi ai đó có M$ VC 2005 kèm SDK 64-bit và hứng thú lao lực để biên dịch được gmp 16:52 <Complication> Ít nhất theo hiểu biết của tôi 16:53 <@cervantes> (tuy vậy hình như có dự án port gmp sang project vc ở đâu đó) 16:53 <jrandom> cervantes: ừ thì, chúng tôi có một cái /chạy được/ cho amd64/win, nhưng chưa tận dụng tối đa phần cứng ;) 16:53 <jrandom> (khi máy mới của tôi về, tôi có thể tinh chỉnh việc đó, vì nó là amd64) 16:53 <+fox> <BrianR___> đang cân nhắc xem nên dùng giao thức nhị phân để tiết kiệm bít hay để zlib hay gì đó nén giao thức ascii cho gọn nhẹ.. 16:54 <@cervantes> hay đấy - tiếc là Mingw64 hay cygwin64 có vẻ chưa xuất hiện trong tương lai gần... 16:54 <jrandom> BrianR___: tối ưu sớm là cội nguồn của mọi tội lỗi, đại loại thế... 16:55 <Complication> ít nhất các giao thức có thể đọc phần nào bởi con người thường dễ debug hơn, nhưng còn tùy vào việc mình làm 16:56 <Complication> (vì một số thứ như mã hóa không thích "đọc được bởi con người", dù thế nào đi nữa :) ) 16:57 <Complication> Nhưng nếu I2P lo phần mã hóa và cả nén, khả năng cao nhiều thứ chạy phía trên nó có thể dùng giao thức đọc được bởi con người 16:58 <jrandom> ừ 16:58 <jrandom> ok, còn gì về 3) jbigi không? 16:58 <jrandom> nếu không thì chuyển sang 4) ??? 16:59 <jrandom> ai còn gì cho buổi họp không? 17:01 <+tethra> tôi nhớ gần đây có nghe về các công cụ cộng tác ẩn danh 17:01 <+tethra> có thể nói rõ là loại gì, và liệu chúng sẽ kiểu syndie hay không? 17:02 <@cervantes> irc và syndie là công cụ cộng tác ẩn danh :) 17:02 <jrandom> hmm, không chắc bạn đang nói đến gì - hay có lẽ bạn muốn nói tới các kế hoạch đại tu syndie? :) 17:02 <+tethra> đúng. 17:02 * tethra cũng không chắc, nên mới hỏi 17:02 <+tethra> đã có bàn luận về nó trên diễn đàn - lý do cho ẩn danh và các thứ 17:03 <+tethra> tôi sẽ tìm thread để trích dẫn 17:03 <jrandom> à đúng 17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 17:03 <jrandom> thread use case 17:03 <+tethra> - diễn đàn/bảng tin/wiki được host ẩn danh và truy cập công khai 17:03 <+tethra> ừ 17:04 <+tethra> sẽ có dự án kiểu i2wiki dựa trên thứ gì đó như syndie hay để người dùng tự làm? 17:04 <jrandom> trong đó có vài ý tưởng hay và phản hồi tốt 17:05 <jrandom> khả năng chỉnh sửa bài đăng syndie là tính năng được yêu cầu nhiều, và với nó, bạn có thể làm một wiki với trình soạn thảo phong phú 17:05 <jrandom> nhưng dĩ nhiên, chẳng có gì tồn tại trong chân không - nếu ai đó tin rằng điều đó cần thiết, ai đó nên nói "này, một wiki là thiết yếu, và đây là lý do" 17:06 <jrandom> có vô số ứng dụng /có thể/ xây dựng, nhưng vì chúng ta hướng tới ẩn danh mạnh và bảo mật mạnh, cần thận trọng với những gì được xây 17:07 <+tethra> đúng 17:07 <+tethra> nói vậy, những thứ khó giữ ẩn danh và an toàn hơn có lẽ nên do người giỏi việc giữ ẩn danh và an toàn làm, đúng không? 17:08 <jrandom> có lẽ vậy, dù không có "cabal" nào cả - ai cũng có thể học 17:08 <+tethra> (những thứ then chốt, đại khái vậy. không phải tôi nêu tên cái gì, nhưng mà.) 17:08 <+tethra> đúng 17:09 <+tethra> nhưng học mà phải đánh đổi ẩn danh của bản thân và người khác thì không phải cách hay nhất 17:10 <jrandom> ai cũng phải bắt đầu từ đâu đó, dĩ nhiên 17:10 <+tethra> (có lẽ nếu ai đó làm một thứ dạng sandbox cho phép chạy $software rồi có người tấn công nó v.v. thì sẽ tốt cho người mới/chưa có kinh nghiệm?) 17:10 <+tethra> ừ 17:14 <jrandom> ok, còn ai có gì cho buổi họp không? 17:15 <jrandom> nếu không 17:15 * jrandom chuẩn bị kết thúc 17:15 <@cervantes> *ahem* 17:15 * jrandom tạm dừng 17:16 <jrandom> có gì mới vậy, cerv? 17:16 <Complication> Hay quá, tôi tìm ra một baf ;P 17:17 <jrandom> baf-bị-chặn ;) 17:17 <@cervantes> hups xin lỗi, tiếp tục "baf" đi 17:17 * jrandom tiếp tục kết thúc 17:18 * jrandom *baf* đóng cuộc họp