Tóm tắt nhanh

Có mặt: cat-a-puss, cervantes, Connelly, deer, duck, jrandom, mihi, modulus

Nhật ký cuộc họp

14:05 <jrandom> 0) chào 14:05 <jrandom> 1) 0.3.2.3, 0.3.3, và lộ trình 14:05 <jrandom> 2) s/reliability/capacity/g 14:05 <jrandom> 3) cập nhật website 14:05 <jrandom> 4) tấn công và phòng thủ 14:05 <jrandom> 5) ??? 14:05 <jrandom> 0) chào 14:05 * jrandom vẫy tay 14:05 <jrandom> ghi chú tình hình hàng tuần đã đăng tại @ http://dev.i2p.net/pipermail/i2p/2004-July/000358.html 14:06 <jrandom> tiến ngay tới 1) 0.3.2.3, 0.3.3, và lộ trình 14:07 <jrandom> (trong lúc mọi người đọc trước, tôi đoán vậy ;) 14:07 <jrandom> bản phát hành 0.3.2.3 đã ra và có vẻ chạy ổn 14:07 <jrandom> mọi người đang gặp khó chịu chính ở đâu? 14:08 <deer> <Nightblade> không gặp rắc rối nào cả 14:08 <deer> <duck> uptime 4 ngày không vấn đề 14:08 <jrandom> hmm, chuẩn 14:08 <deer> <duck> với một số người thì irc có vẻ không ổn định lắm 14:08 <deer> <duck> như kaji bị đá ra mỗi phút 14:08 <deer> <duck> nhưng chuyện đó không mới mẻ 14:09 <jrandom> đúng, chuyện đó cũng xảy ra với anh ấy trên mạng freenode, nên tôi không chắc đổ lỗi cho gì ở đây 14:09 <deer> <duck> yeah 14:09 <deer> <duck> connelly gặp vài download lỗi theo như tôi biết (afaik) 14:10 <deer> <duck> nhưng bạn đâu có thấy tôi kêu ca 14:10 <jrandom> à thật sao? hmm, tôi nghĩ chúng tôi đã tìm ra một số trong đó liên quan đến thư viện của anh ấy, nhưng tôi cũng thỉnh thoảng gặp lỗi khi truyền tệp lớn 14:10 <jrandom> đặc biệt khi đang leech sách từ alexandria 14:10 <jrandom> (ờ, không hẳn là đặc biệt, nhưng đó là site duy nhất tôi leech) 14:11 <deer> <duck> :) 14:11 <jrandom> ok, kế hoạch của tôi là khi bản 0.3.3 ra, tôi sẽ tập trung đưa chúng ta lên 0.4, song song với các bản sửa lỗi mọi người nêu ra 14:12 <jrandom> công việc 0.4 còn lại chủ yếu là các thứ web đơn giản (new router console w/ servlets, jetty integration, servlet to control the router, and a servlet to config the i2ptunnel instances) 14:13 <jrandom> có lẽ vài bạn làm jsp/servlet có thể giúp một tay để làm quen với code, dù tôi từng làm khá nhiều thứ kiểu đó rồi nên việc hiện thực sẽ không quá khó 14:13 <jrandom> theo như tôi biết, installer của hypercubus về cơ bản là sẵn sàng 14:13 <jrandom> (dù hôm nay tôi vừa quăng thêm việc cho anh ấy ;) 14:13 <deer> <duck> featurecreep++ 14:14 <jrandom> giữ mọi người luôn cảnh giác :) 14:14 <jrandom> (nhưng mà, ai cũng ghét phải tải từng jar riêng lẻ để nâng cấp) 14:14 <deer> <duck> đúng, đó là vấn đề lớn nhất của tôi khi nâng cấp 14:14 <deer> <duck> (dù tôi dùng cvs) 14:14 <deer> <duck> nhưng sẽ là như vậy nếu tôi không dùng 14:15 <jrandom> heh 14:15 <mihi> jrandom: chỉ cần tar tất cả chúng -> 1 lần tải ;) 14:15 <jrandom> như vậy đủ đơn giản, và để updgrade.sh/upgrade.bat == jar xf upgrade.jar 14:16 <jrandom> (sau một lệnh kiểu wget) 14:16 <jrandom> tôi nghĩ hypercubus đã nắm code làm mấy việc đó, nên ta có thể để anh ấy quyết định làm điều Đúng Đắn 14:17 <jrandom> dù sao, như mọi người có thể đã để ý, lịch trình của chúng ta không còn như trước 14:17 <jrandom> lộ trình đã được cập nhật và bị kéoooooo dàiiiiii 14:18 <mihi> jjrraannddoomm:: kkiểm ttra công tắc duplex của bạn 14:18 <deer> <Nightblade> hah 14:18 <jrandom> heh 14:18 * mihi mắc lỗi... ai bắt lỗi trước? 14:19 <jrandom> (\n\n) 14:19 <jrandom> nhưng dù sao 14:19 <mihi> ok, thêm cái nữa ;) 14:19 <duck> (không có hai dấu cách) 14:19 <mihi> duck++ 14:20 <jrandom> tôi nghĩ lộ trình giờ khá thực tế ít nhất tới bản 1.0, tuy nhiên tùy vào mức độ người dùng đón nhận và phản hồi, chúng ta có thể sắp xếp lại hoặc bỏ một trong 0.4.2 hoặc 0.4.3 14:20 <jrandom> (và dĩ nhiên, như mọi khi, lộ trình có thể thay đổi nếu có thêm người tham gia :) 14:21 <modulus> có lẽ một ngày nào đó tôi sẽ làm, sau khi học java, nhưng i2p nghe không giống dự án cho người mới. 14:21 <deer> <Sandworm> ừ, sẽ mất lâu hơn :) 14:21 <deer> * duck mong sẽ còn trượt lịch đôi chút dọc đường 14:21 <modulus> :-) 14:22 <deer> * duck khó mà gọi là trượt lịch, nhìn bảng ấn tượng ở http://www.i2p.net/redesign/announcements 14:22 <jrandom> trễ lịch dĩ nhiên có thể xảy ra, nhưng tôi nghĩ các mốc còn lại đều khá khả thi 14:22 <jrandom> ừ, cảm ơn đã cho thấy tôi chẳng có đời sống gì hết, duck ;) 14:22 <deer> <duck> đây là cuộc đời của anh 14:22 <modulus> vậy 1.0 khi nào ra? :-) 14:22 <deer> <duck> hãy tự hào về nó 14:23 <jrandom> modulus: dù một vài phần của i2p rất khó nhằn, vẫn có nhiều mảnh có thể do lập trình viên mới xử lý khá dễ 14:23 <modulus> nhưng có lẽ là phần khá chán, đúng không? 14:24 <jrandom> không, không hề. ví dụ, dựng nhanh một ứng dụng chuyển tệp ẩn danh hay chat, một webserver mini, một MUD, một app cờ vua, v.v. 14:24 <duck> (cập nhật website) 14:24 <modulus> nghe hay đấy. 14:24 <jrandom> (tức là các client app đơn giản có thể ẩn danh) 14:24 <jrandom> và dĩ nhiên là cập nhật web ;) 14:25 <modulus> chuyện cập nhật web là gì vậy? 14:25 <jrandom> website của chúng ta cần làm việc (xem http://dev.i2p.net/pipermail/i2p/2004-July/000358.html hoặc chờ vài phút tới mục 3) 14:25 <cat-a-puss> myi2p nằm ở đâu trong tất cả chuyện đó? 14:25 <modulus> à à 14:26 <jrandom> cat-a-puss: http://www.i2p.net/redesign/myi2p :) 14:26 <modulus> theo tôi myi2p chưa phải ưu tiên lúc này... 14:26 <jrandom> (tôi vừa viết một trang ngắn về nó vài giờ trước) 14:27 <jrandom> nhân tiện, mọi cập nhật website đều được gửi lên mailing list i2pwww (http://dev.i2p.net/pipermail/i2pwww/2004-July/thread.html) 14:28 <modulus> hmm, tôi có thể viết một ứng dụng định danh toàn cục :-) 14:28 <jrandom> nhưng tôi vẫn thấy việc triển khai myi2p (ít nhất sổ địa chỉ cơ bản và blog) sẽ được thực hiện cho bản 1.0 14:28 <jrandom> (theo lộ trình, dự kiến tháng Mười Một) 14:28 <jrandom> đúng, bạn chắc chắn có thể 14:28 <modulus> thứ gì đó đơn giản hơn DNS, có xác thực và ủy quyền TLD 14:28 <jrandom> cũng không tệ chút nào – một app đơn giản để bạn truy vấn một name server trung tâm sẽ hay đấy 14:29 <modulus> ừ 14:29 <jrandom> vậy thì bắt tay vào code đi :) 14:29 <modulus> tôi sẽ bắt đầu vào ngày mai. cứ nhắc nhở tôi nếu tôi lo việc khác ;-) 14:29 <jrandom> hehe hay đấy, sẽ làm vậy 14:29 <jrandom> ok, chuyển sang 2) s/reliability/capacity/g 14:29 <duck> câu hỏi nhỏ về site: 14:29 <duck> ồ đợi đã 14:29 <duck> đó là mục 3 14:29 <duck> xin lỗi 14:29 <jrandom> được, gì vậy? 14:30 <jrandom> à, 'k 14:30 <jrandom> sẽ có một thay đổi khá căn bản với phần profiling và lựa chọn peer trong bản 0.3.3, như mô tả trong email và http://www.i2p.net/redesign/how_peerselection 14:31 <jrandom> tôi đã chạy nó trên một cặp router lúc này và có vẻ hoạt động ổn (Speed: 25.18 (5 fast peers) Capacity: 17.50 (8 high capacity peers) Integration: 37.00 (2 well integrated peers)) 14:31 <jrandom> và không còn giá trị âm nữa :) 14:31 <modulus> :) 14:32 <jrandom> tôi sẽ thử thêm chút nữa, có lẽ một hai ngày nữa, rồi tung nó ra thành 0.3.3 14:32 <cat-a-puss> d 14:32 <cat-a-puss> <modulus> 14:32 <cat-a-puss> oops 14:33 <duck> đang khuyên không nên cập nhật cvs à? 14:33 <cat-a-puss> để làm dns hãy xem một cache của http://www.levien.com/thesis/compact.pdf 14:33 <jrandom> không, cvs hiện khá ổn định 14:33 <jrandom> (nhưng như mọi khi, hãy sẵn sàng quay lui nếu có thứ gì đó tệ xảy ra) 14:35 <jrandom> trông hay đó cat-a-puss, cảm ơn 14:35 <cat-a-puss> (tôi có một bản gốc nếu ai cần) 14:36 <jrandom> cache của Google làm hình hơi méo, nên nếu bạn có pdf thô thì tuyệt 14:36 <jrandom> dù sao, chúng ta đang hơi lạc đề (nhưng có thể quay lại vấn đề này) 14:37 <jrandom> về chuyển đổi reliability/capacity thì thế thôi, chuyển sang 3) cập nhật website 14:37 <jrandom> duck: bạn có điều gì muốn nêu chứ? 14:38 <jrandom> trong lúc duck chuẩn bị ghi chú, có ai có ý tưởng/đề xuất/quan ngại gì liên quan tới các mục đã nêu trong email không? 14:39 <deer> <Nightblade> website trông tốt 14:39 <jrandom> ừ, tôi thích phần điều hướng mới và bố cục site khá sạch 14:40 <deer> <Nightblade> dễ tìm thứ hơn 14:40 <cervantes> _dễ_ tìm thứ hơn nhiều 14:40 <duck> trước hết tôi muốn cảm ơn người đại diện người dùng của chúng ta, protocol, vì đã hữu ích :) 14:40 <jrandom> heh 14:40 <duck> anh ấy có vài gợi ý hay và mới chỉ bắt đầu 14:40 <cervantes> hip hip hurra! 14:40 <jrandom> (đồng ý!) 14:41 <duck> tiếp theo, tôi nghĩ hầu như không có lý do gì để không đưa bản thiết kế lại lên chính thức 14:42 <jrandom> đồng ý – có lẽ ta chỉ cần đánh dấu news/development/documentation là các mục không nằm trong điều hướng trang, tạm bỏ phần jvm và tinh chỉnh config, và thêm một số nội dung cơ bản cho trang I2PTunnel, tôi nghĩ ta có thể triển khai 14:42 <jrandom> tôi chỉ muốn nó lên live với mọi liên kết hoạt động (và mọi trang không hoạt động) 14:43 <jrandom> sẽ dĩ nhiên có các cập nhật tiếp theo sau khi nó lên life ;) 14:43 <jrandom> à, live 14:44 <jrandom> nhân tiện, wilde đã nối tài khoản 34sp của chúng ta rồi, nên khi cần ta có thể chuyển site sang đó 14:44 <cervantes> ngầu đấy 14:44 <jrandom> duck nghĩ sao? cái menu.php đó có xử lý các mục điều hướng không phải trang được không? 14:44 * cervantes kiểm tra inbox xem có điểm giới thiệu 14:45 <jrandom> (hay sửa vào như thế sẽ quá tốn công?) 14:45 <jrandom> hehe cervantes, cái đó đang trên đường tới 14:45 <cervantes> ;-) 14:45 <cervantes> à, chiêu cũ "tấm séc đang trên đường gửi bưu điện" 14:47 <duck> xin lỗi; đang làm việc khác trong lúc này. 14:47 <duck> ok; có thể làm cho nó chỉ là tiêu đề phần điều hướng 14:47 <jrandom> không vấn đề, ta có thể tiếp tục và quay lại sau nếu bạn muốn 14:47 <jrandom> ok hay đó 14:47 <jrandom> (duck++) 14:48 <jrandom> ok, còn gì liên quan website không? 14:48 <duck> với gợi ý của bạn, nghe như đã sẵn sàng để đưa lên. 14:48 <jrandom> nếu không, chuyển sang 4) tấn công và phòng thủ 14:48 <duck> . 14:48 <jrandom> chuẩn 14:49 <jrandom> ok, tôi đoán mọi người đã đọc mailing list và xem bài của connelly cùng các phản hồi 14:50 <cervantes> anh ấy bận rộn :) 14:50 <cervantes> (gần bằng proto) 14:50 <Connelly> theo tôi (imo), mạng có vẻ vững với mọi thứ ngoại trừ phân tích lưu lượng (các site có nhiều lưu lượng), và các tấn công cắt kết nối của chính phủ, và khi kẻ tấn công chiếm phần lớn mạng 14:50 <jrandom> dù tôi nghĩ chúng ta đang ở trạng thái khá tốt, tôi chắc chắn vẫn có điều (hay nhiều điều) chúng ta bỏ sót, vậy xin đừng mặc định i2p làm hay sẽ làm đúng như tuyên bố – hãy thách thức các giả định và nói vì sao nó tệ 14:50 <Connelly> mã hóa về cơ bản làm tiêu các kiểu tấn công không hung hãn 14:51 <jrandom> đó là điều chúng ta kỳ vọng 14:51 <jrandom> thêm nữa, với khả năng i2p 2.0 và 3.0, các biện pháp phòng thủ trước đối thủ tầm cỡ chính phủ sẽ khả thi 14:51 <Connelly> tất nhiên trong thực tế sẽ có lỗ hổng bảo mật cần vá 14:52 * jrandom vẫn cần viết vài tài liệu về cách các độ trễ 3.0 sẽ ngăn tấn công chia cắt 14:52 <jrandom> chắc chắn rồi connelly 14:54 <jrandom> ok, nếu không còn gì theo hướng đó, tôi nghĩ tôi hết rồi 14:54 <jrandom> vậy 5) ??? 14:55 <jrandom> à, nhân tiện, tôi đã vẽ đồ thị băng thông sử dụng so với số tunnel tham gia cho một trong các mô phỏng trong suốt 4 ngày 14:55 <jrandom> đã đăng tại @ http://dev.i2p.net/~jrandom/4daybandwidth.webp 14:56 <jrandom> mô phỏng có các thông điệp 32KB gửi qua lại mỗi 30s, với hai router bị bóp ở 6KBps, và mọi thứ hoạt động đúng như 'nên thế' 14:56 <duck> (đã triển khai thuộc tính nolink cho site) 14:56 <jrandom> (ví dụ: tải phân bố trên các peer nhanh và tin cậy, tránh các peer chậm, v.v.) 14:56 <jrandom> w00t 14:56 <Connelly> một đồ thị log của băng thông/người dùng theo kích thước mạng sẽ hay 14:57 <Connelly> để có thể nói 'ừ, nó thực sự mở rộng tốt' 14:58 <jrandom> thậm chí không cần đồ thị log – khả năng mở rộng của client comm là đúng O(1) [cần 2k*msgSize, với k = # hops trong tunnel] 14:58 <jrandom> nhưng đúng, tôi đồng ý, chúng ta cần vài tài liệu mô tả cách i2p mở rộng 14:58 <Connelly> thế còn kademlia ... có trong mô phỏng của bạn không? 14:58 <jrandom> có, mô phỏng thực chất là toàn bộ code router, tất cả chạy trong một JVM 14:58 <jrandom> tôi còn chạy nó với kết nối TCP đầy đủ thay vì hệ thống liên lạc trong VM nữa 14:59 <jrandom> mã Kademlia được dùng lần đầu khi Alice muốn liên lạc với Bob – chừng nào họ còn nói chuyện, liên lạc của họ là O(1) vì họ gói LeaseSet cùng với payload 14:59 <jrandom> (nên không cần các tra cứu netDb tiếp theo) 15:00 <cervantes> vl07 và onb0 là các router bị bóp nghẹt? 15:00 <jrandom> nhưng đúng, chúng ta cần một mô phỏng để chứng minh chính netDb mở rộng thế nào 15:01 <jrandom> cevantes: 0jvf và onb0 15:01 <cervantes> điều gì giải thích mức tụt của vl07 sau một ngày uptime? 15:02 <cervantes> có vẻ giao cắt với 00u0 15:02 <jrandom> tất cả các router không bị bóp về cơ bản là như nhau – đều trên cùng CPU, có độ trễ (0ms) như nhau, nên việc phân loại một cái là 'fast' so với 'reliable' chỉ là tùy ý 15:04 <Connelly> việc gán nhãn 'fast and reliable', 'slow' v.v. của bạn có hồi phục từ các giá trị lớn không? 15:04 <jrandom> tại sao nó giảm xếp hạng/mức sử dụng sau một ngày? tôi không chắc, có lẽ một lúc CPU hoặc IO bị đội thêm khi đang thử nghiệm khiến tốc độ giảm chút 15:04 <jrandom> đúng, xếp hạng dùng trung vị bây giờ, không phải trung bình, và có độ suy giảm khá nhanh trên dữ liệu 15:05 <jrandom> s/fiarly/fairly/ 15:05 <Connelly> vậy nếu tôi làm bạn nghĩ độ tin cậy của tôi là 1000000000, bạn có thể hồi phục khi tôi bắt đầu bỏ thông điệp chứ 15:06 <jrandom> chắc chắn – nếu bạn 'fail' tôi sẽ lập tức ngừng nhờ bạn làm việc và giảm xếp hạng của bạn 15:06 <jrandom> tính toán "capacity" mới lại khá nhạy với các kiểu thay đổi đó 15:06 <jrandom> (tốc độ cũng khó mà giả mạo, vì mọi xếp hạng tốc độ đều là giá trị đo thực) 15:07 <jrandom> ((giống như reliability trước đây, và capacity bây giờ)) 15:09 <jrandom> ok, còn ai có gì muốn nêu không? 15:10 <deer> * jrandomi2p gợi ý *baf*er 15:11 * jrandom đồng tình 15:11 * jrandom lấy đà 15:11 * jrandom *baf* kết thúc cuộc họp