I2P Dev Meeting - February 28, 2006

15:11 <jrandom> 0) chào 15:11 <jrandom> 1) Tình trạng mạng và 0.6.1.12 15:11 <jrandom> 2) Lộ trình tới 0.6.2 15:12 <jrandom> 3) Dự án nhỏ 15:12 <jrandom> 4) ??? 15:12 <jrandom> 0) chào 15:12 * Complication nhanh chóng đọc ghi chú 15:12 * jrandom vẫy tay 15:12 <jrandom> ghi chú trạng thái hằng tuần đã đăng tại http://dev.i2p.net/pipermail/i2p/2006-February/001266.html 15:12 <jrandom> (và lần này tôi đã đăng ghi chú sớm hơn cuộc họp hơn 15 phút! ;) 15:13 <jrandom> ok trong lúc mọi người đọc những phần hấp dẫn đó, hãy bắt đầu với 1) Tình trạng mạng và 0.6.1.12 15:14 <jrandom> như đã nêu, các mục tiêu chính của các bản phát hành 0.6.1.10-0.6.1.12 có vẻ đã đạt được, xử lý thay đổi mã hóa tạo tunnel và cải thiện đáng kể độ tin cậy khi tạo 15:16 <jrandom> những trục trặc chúng ta thấy ở 0.6.1.10 đã biến mất, và độ ổn định irc có vẻ lại khá tốt 15:16 <jrandom> ai còn điều gì cho 1) Tình trạng mạng và 0.6.1.12, hay chúng ta chuyển sang 2) Lộ trình tới 0.6.2? 15:17 <+Complication> Tình trạng mạng bên này: không còn tụt dưới 20 KB/s nữa :) 15:18 <jrandom> tuyệt, đúng vậy 0.6.1.12 đã sửa một bug khá lớn trong 0.6.1.11 khiến nó không tận dụng băng thông sẵn có. giờ nó nên sử dụng tài nguyên sẵn có tốt hơn 15:20 <jrandom> ok, chuyển sang 2) 15:20 <jrandom> như đã nói, còn vài thứ cần sắp xếp trước khi đưa thay đổi chức năng cuối cùng vào 0.6.2, nhưng chúng ta đang tiến triển 15:20 <nymisis> tình trạng mạng ổn :) 15:22 <jrandom> chuẩn. sẽ có thêm thông tin chi tiết về các chiến lược sắp xếp peer (nút đồng đẳng) mới trước khi phát hành, nhưng ý chính của chúng hẳn đã rõ qua phần nhắc ngắn trong ghi chú 15:23 <jrandom> ai có câu hỏi/bình luận/quan ngại gì về 2) lộ trình tới 0.6.2? 15:23 <postman> jrandom: có testnet lần này không? 15:24 <postman> (cần router hay người tham gia để thử nghiệm không) 15:24 <postman> ? 15:24 <+Complication> Cốt lõi của vấn đề có vẻ khá đơn giản - hạn chế cơ hội để đối phương thu thập đa dạng dữ liệu thống kê 15:25 <+Complication> Nghe như một tính năng khá đáng mong muốn 15:25 <jrandom> postman: thứ mới sẽ hoạt động minh bạch trên mạng thật, dùng thông tin chỉ cục bộ, nên không cần mạng riêng để thử 15:25 <jrandom> ừ, chính xác đấy Complication 15:26 <postman> ok 15:26 <postman> jrandom: bạn có dám công bố ETA (thời gian dự kiến) cho 0.6.2 không? :) 15:27 <blubb> 1 tháng 4 15:27 <jrandom> ừ, vì hôm nay là cuối tháng 2, tôi đoán tháng 3 hoặc tháng 4 15:27 <postman> hehe 15:27 <jrandom> blubb: chúng ta đã lên lịch một cửa hậu MI6 cho lúc đó rồi ;) 15:29 <@cervantes> giống cửa cho mèo của MI6 hơn 15:29 <@cervantes> (cắt giảm ngân sách) 15:29 <postman> trong chuồng voi 15:30 <nymisis> Đó là SIS, không phải MI6, nếu bạn muốn chính xác. :) 15:30 <jrandom> thôi, cứ gọi họ là Bọn Họ ;) 15:31 <jrandom> ok, còn gì cho 2) không? 15:31 <jrandom> nếu không, ta chuyển qua 3) dự án nhỏ 15:31 <@cervantes> xin lỗi "the firm" 15:34 <jrandom> ok, tôi chỉ muốn nêu vài thứ hay ho 1) dễ làm và 2) thật sự hữu ích 15:34 <+Complication> Về phía các dự án nhỏ, tôi không chắc phản hồi Syndie của mình đã tới chưa, nhưng tôi đang tự hỏi liệu tôi có thể chộp một cái không. 15:34 <+Complication> Chưa chắc cái nào. Hiện đang luyện Java thêm (làm một micro-project :D) để chắc rằng khi thử, tôi sẽ xử lý được một cái 15:35 <DeltaQ> hmm nếu tôi tăng băng thông trên bảng điều khiển (console) thì thay đổi có hiệu lực ngay hay cần khởi động lại? 15:35 <+Complication> Khi xong "micro-project" (giả sử dĩ nhiên danh sách chưa bị dọn sạch), tôi sẽ thử chọn một cái 15:35 <jrandom> w3wt, tuyệt Complication 15:36 <jrandom> DeltaQ: ngay lập tức 15:36 <@cervantes> 1) syndie scheduler có liên kết với 4) Download Manager / eepget scheduler không 15:36 <+Complication> DeltaQ: có hiệu lực gần như tức thì (trong các khoảng mà băng thông được lấy trung bình) 15:37 <@cervantes> theo tôi, một trình quản lý tải lên và tải xuống tổng quát hơn sẽ đáp ứng cả hai nhu cầu 15:37 <jrandom> cervantes: hmm, không hẳn. 1) khá tập trung, và còn bao gồm push, trong khi 4) khá tổng quát 15:37 <+Complication> cervantes: nghe có vẻ được 15:37 <jrandom> nhưng đúng, lõi phía sau cả hai là EepGet 15:37 <jrandom> (eepget làm các truyền http của syndie, theo cách lập trình) 15:38 <DeltaQ> trung bình có vẻ không vượt quá 13kb/s 15:38 <DeltaQ> tôi đặt 64kb/s với 192 burst xuống 15:38 <DeltaQ> 32/64 lên 15:38 <@cervantes> vậy một eepget push và pull tổng quát với một api lập lịch và quản lý... 15:39 <@cervantes> dù vậy, có lẽ đến mức đó thì không còn là dự án nhỏ nữa 15:39 <+Complication> DeltaQ: trung bình còn phụ thuộc vào mức tải mà client tunnels của bạn (và participating tunnels của các peer khác) tạo ra 15:39 <+Complication> xin lỗi, s/average/actual bandwidth 15:39 <jrandom> cervantes: ừ, tuy vậy phần syndie có khá nhiều logic liên quan. 15:40 <DeltaQ> heh cuối cùng nó cũng tăng 15:40 <DeltaQ> 1s: 30.82/29.33KBps 15:40 <DeltaQ> chắc tôi cần tăng băng thông upload (ul) 15:40 <jrandom> DeltaQ: trung bình cũng bị ảnh hưởng bởi cách người khác nhìn bạn, điều này phụ thuộc vào hành vi của bạn, không phải tốc độ quảng bá, nên sẽ mất chút thời gian 15:40 <+Complication> DeltaQ: với lưu lượng chuyển tiếp (participating tunnels), cái vào cũng phải ra 15:41 <+Complication> DeltaQ: vì vậy tốc độ ul/dl quá khác nhau sẽ bóp nghẹt lưu lượng participating xuống mức thấp hơn trong hai mức 15:42 <+Complication> DeltaQ: ngoài ra, lưu lượng participating phụ thuộc vào cách các nút khác "nhận định" khả năng định tuyến của nút bạn 15:42 <DeltaQ> oki 15:43 <+Complication> Nếu họ nghĩ nó định tuyến tốt, họ sẽ yêu cầu thường xuyên hơn 15:43 <jrandom> ok, nếu không còn gì ở 3) dự án nhỏ, chuyển sang 4) ??? 15:43 <jrandom> ai còn điều gì muốn nêu cho cuộc họp không? 15:43 <DeltaQ> à tôi ở sau một router nhưng tôi đã ánh xạ cổng 8887 tới PC này 15:43 <+Complication> Nếu nó mới, hoặc vừa tăng năng lực, họ sẽ hơi dè dặt 15:44 <DeltaQ> ồ xin lỗi tôi không định xen vào cuộc họp ^^ 15:44 <+Complication> Có người hôm trước hỏi về các tấn công có thể dựa trên độ lệch đồng hồ (clock skew). Tôi nghĩ tôi đã thấy câu trả lời của bạn về phần tunneling (thông điệp tạo chỉ chứa khoảng thời gian hiệu lực của tunnel, không phải thời gian theo góc nhìn của bên tạo)... 15:44 <@cervantes> (cảm ơn vì đã nhắc trong ghi chú trạng thái) ;-)_ 15:46 <+Complication> Vậy tôi nghĩ, thực ra, hỏi rằng... những điểm nào, nếu có, trong truyền tin I2P có thể chứa thời gian theo góc nhìn của người gửi? 15:47 <+Complication> Tôi chưa kịp cập nhật về chuyện này, nên hơi mù mờ về nó 15:47 <jrandom> Complication: không có gì nói rõ "Tôi nghĩ bây giờ là $time", nhưng với đủ lưu lượng và phân tích thời gian, người ta có thể thu hẹp đáng kể 15:48 <jrandom> chúng tôi có làm tròn thời gian theo bậc lớn, dù không lớn bằng độ lệch đồng hồ tối đa, nên vẫn còn khoảng trống 15:49 <+Complication> Bạn có nghĩ rốt cuộc sẽ có lợi ích nào từ một NTP client "tinh gọn" hơn không? 15:49 <+Complication> Một cái có thể dễ giữ độ lệch nhỏ hơn? 15:50 <jrandom> ừ, từ khi sntp client được đưa vào i2p, nó ngày càng tốt hơn để giờ chúng ta không còn thấy mức dao động như trước 15:51 <jrandom> có lẽ ta có thể giảm giới hạn lệch tối thiểu từ 10 giây xuống khoảng 2 hoặc 3 giây, hoặc ít hơn 15:51 <jrandom> hoặc, ta có thể cho phép nó xem cả độ lệch đồng hồ SSU để tránh lệch không cần thiết 15:52 <+Complication> Hoặc ngược lại, liệu có thể hạn chế thêm cơ hội đoán giá trị đồng hồ có thể có của peer khác không? 15:53 * Complication không biết hướng nào thiết thực hơn, chỉ gợi ý vài khả năng ngẫu nhiên :D 15:53 <jrandom> không, chúng ta biết độ lệch đồng hồ của các peer kết nối trực tiếp 15:55 <Magii> có cách nào biết cập nhật đã thực hiện thành công không? 15:55 <+Complication> Aha, vậy session protocol thực sự phụ thuộc vào thông tin đó.. 15:55 <tethra> xem số phiên bản của bạn 15:55 <+Complication> Magii: nó sẽ ghi vào logs một CRIT như "update verified, restarting to install" 15:55 <tethra> :/ 15:55 <+Complication> Sau đó, nó sẽ đếm ngược số phút để khởi động lại êm ái 15:56 <+Complication> Và cuối cùng khởi động lại 15:57 <+Complication> Ồ, ghi chú bên lề: NTP client nội bộ có biết khái niệm như "clock drift rate" (tốc độ trôi đồng hồ) không? 15:58 <jrandom> ừ, số phiên bản ở góc trên bên trái của http://localhost:7657/index.jsp là dấu hiệu rõ ràng :) 15:58 <jrandom> Complication: không, nó không đảm bảo các nhịp đồng hồ tuần tự 15:59 <jrandom> s/sequential/ordered/ 15:59 <+Complication> Cũng không học được kiểu kiến thức như "đồng hồ hệ thống của chúng ta nhanh hơn cần thiết 0,00345 lần"? 16:00 <jrandom> à, không, dù thêm cái đó vào net.i2p.util.Clock cũng không quá khó (muốn làm một dự án nhỏ không? :) 16:00 <+Complication> Tôi đang nghĩ theo hướng đó 16:01 <+Complication> Chắc giờ tôi sẽ nghĩ thêm chút về nó :) 16:01 <+Complication> Nhưng các dự án nhỏ khác trước đã :) 16:02 <jrandom> ok, ai còn gì nữa cho cuộc họp không? 16:03 <nymisis> Bánh muffin? 16:04 <jrandom> không, bánh pancake 16:04 <jrandom> (mmMMmm pancake) 16:04 <jrandom> nói về chuyện đó 16:04 * jrandom thu xếp kết thúc 16:04 <nymisis> Ồ, chết thật, đúng ý. 16:04 * jrandom *baf* đóng cuộc họp