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

16:12 <jrandom> 0) chào 16:12 <jrandom> 1) Tình trạng mạng và 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) chào 16:13 * jrandom vẫy tay 16:13 <@cervantes> chào 16:13 <jrandom> ghi chú trạng thái hàng tuần đã đăng tại @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 16:14 <jrandom> trong lúc mọi người lướt qua, hãy nhảy vào 1) Tình trạng mạng 16:14 <jrandom> như đa số mọi người đã thấy, chúng ta vừa có bản phát hành mới, và đến giờ kết quả khá tích cực 16:15 <@cervantes> (hoan hô!) 16:15 <jrandom> vẫn chưa đạt như kỳ vọng, nhưng cơ bản đã giải quyết các vấn đề chính mà chúng ta gặp 16:15 <jrandom> ừ, thật vui khi lại có tỷ lệ xây dựng tunnel khá ổn, với các tunnel 2+ hop :) 16:16 * jrandom có tỷ lệ thành công 50%+ trên một router khác với các tunnel 1 hop 16:17 <jrandom> Tôi nghĩ vài thay đổi cuối trong 0.6.1.17 cũng sẽ giúp tránh kiểu sập do tắc nghẽn này trong tương lai 16:17 <jrandom> tuy nhiên, kết quả người dùng thấy là thỉnh thoảng sẽ có lease hết hạn, nhưng thay vì tự chồng chất, nó sẽ backoff (giảm nhịp thử lại khi quá tải) 16:17 * cervantes bật azureus 16:18 <+Complication> Sáng nay, tôi ghi nhận tỷ lệ thành công tunnel phía client (độ dài 2 +/- 1) khoảng 35% 16:18 <+Complication> Hiện giờ thấp hơn, vì tôi thử vài chỉnh sửa, và cái mới nhất không ngon lắm :D 16:18 <@cervantes> jrandom: làm tốt việc lần ra nguyên nhân - một lúc chúng ta bắt đầu trông như freenet vậy :) 16:19 <jrandom> *khụ* ;) 16:20 <+fox> <inkeystring> jrandom: bạn có phiền mô tả ngắn gọn cơ chế backoff không? tôi đang làm thứ tương tự cho freenet 0.7 lúc này 16:21 <jrandom> inkeystring: chúng tôi đã có cơ chế backoff ở tầng truyền tải để giảm gửi tới một peer khi tầng truyền tải bị quá tải, nhưng thế vẫn chưa đủ 16:21 <@cervantes> *khụ* tôi nói freenet á, ý tôi là tor 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: thay đổi mới là đẩy cơ chế đó lên tầng cao hơn để ngừng cố xây tunnel khi tầng giao tiếp (comm layer) bị bão hòa 16:22 <jrandom> (thay vì gửi thêm các lần thử xây tunnel) 16:22 <+fox> <inkeystring> cảm ơn - tầng truyền tải chỉ back off khi mất gói, hay có cách nào để phía nhận kiểm soát lưu lượng? 16:23 * jrandom nhớ đã thảo luận tác động của tắc nghẽn vs định tuyến với toad vài lần (trên irc và flog cũ của tôi), dù tôi không nhớ có giải pháp nào thật sự tích cực cho mạng :/ 16:23 <jrandom> bên nhận có thể NACK (báo nhận phủ định), và chúng tôi có sẵn hook cho ECN (Explicit Congestion Notification - thông báo tắc nghẽn rõ ràng), nhưng chúng chưa cần thiết 16:23 <+fox> <inkeystring> vâng tranh luận đó lại nổi lên trên freenet-dev :-) vẫn chưa có giải pháp thần kỳ 16:24 <+fox> <inkeystring> hay đấy, cảm ơn thông tin 16:24 <+Complication> Dạo này họ cũng dùng UDP, đúng không? 16:24 <jrandom> hiện tại, các peer bị tắc nghẽn nặng gặp vấn đề không phải với throttling theo từng peer, mà với độ rộng của giao tiếp giữa các peer 16:24 <+Complication> (như giao thức truyền tải) 16:24 <+fox> <inkeystring> breadth = số lượng peer? 16:24 <jrandom> đúng 16:25 <jrandom> với tỷ lệ thành công của tunnel tăng, peer không còn cần phải nói chuyện với hàng trăm peer chỉ để xây được một tunnel 16:25 <jrandom> nên họ có thể chỉ cần 20-30 peer 16:25 <jrandom> (các peer kết nối trực tiếp, tức là vậy) 16:26 <+fox> <inkeystring> tôi đoán đó là tin tốt cho NAT hole punching (xuyên NAT), keepalive (gói giữ kết nối), v.v.? 16:26 <jrandom> mặt khác, với 2-300 kết nối SSU đang hoạt động, một đường truyền 6KBps sẽ gặp khó 16:26 <jrandom> ừ 16:26 <+fox> <inkeystring> Complication: đúng 16:27 <+fox> <inkeystring> (trong bản alpha 0.7) 16:27 <+Complication> Aha, vậy họ có lẽ đang gặp những thứ tương tự 16:27 <+Complication> Hy vọng ai đó tìm ra giải pháp thần kỳ :D 16:27 <jrandom> tuy theo cách khác. tầng truyền tải là vấn đề tương đối dễ 16:27 <+fox> <inkeystring> tôi nghĩ họ có thể đã tái dùng một số mã SSU... hoặc ít nhất họ có nói về nó 16:27 <jrandom> (tức là đã được nghiên cứu kỹ 30+ năm) 16:28 <jrandom> nhưng cân bằng tải của i2p (và freenet) hoạt động ở tầng cao hơn so với các liên kết điểm-điểm, và có yêu cầu khác 16:28 <+fox> <inkeystring> vâng, phần tương tác với định tuyến mới khó 16:29 <jrandom> ừ, dù i2p dễ hơn (chúng tôi không cần tìm đúng peer có dữ liệu, chỉ cần bất kỳ ai có khả năng tham gia vào các tunnel của chúng tôi) 16:30 <+fox> <inkeystring> vậy sẽ không mất hiệu năng nếu bạn tránh một peer quá tải... 16:30 <+fox> <inkeystring> trong khi ở freenet, định tuyến vòng qua một peer quá tải có thể tăng độ dài đường đi 16:30 <+fox> <inkeystring> dù sao xin lỗi vì lạc đề 16:31 <jrandom> không sao, giải thích vì sao các thay đổi trong 0.6.1.17 ảnh hưởng đến việc sập do tắc nghẽn của chúng ta là phù hợp mà :) 16:31 <jrandom> ok, còn ai có gì cho 1) Tình trạng mạng không? 16:32 <+Complication> Vâng, như đã nói trước đó, khi chạy bản .17 thuần, tôi quan sát thấy tính chu kỳ rõ rệt trong băng thông và số peer hoạt động 16:32 <+Complication> Và vài người khác có vẻ cũng gặp, dù tôi không rõ nó phổ biến thế nào 16:33 <+Complication> Tôi đang băn khoăn về nguyên nhân chính của nó, chủ yếu từ góc nhìn throttling của tunnel, nhưng chưa có giải pháp 16:33 <+Complication> Tôi đã làm đồ thị của mình phẳng hơn, nhưng phải đánh đổi bằng một số suy giảm tổng thể 16:33 <+Complication> Đã thử các chỉnh sửa như: 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (cái này để tránh việc nó hoàn toàn không thử xây các tunnel của chính nó) 16:35 <jrandom> à phải 16:35 <+Complication> (à, và tất nhiên loglevel thì kỳ quặc, vì tôi đã đổi chúng để test) 16:35 <jrandom> chúng tôi có một ít mã ở đó cố làm lệch tính chu kỳ đi chút, nhưng nó hoạt động không chuẩn lắm (rõ ràng) 16:36 * perv vừa làm sập hệ thống của mình :( 16:36 <+Complication> Nhưng tôi đã thử vài thứ như vậy, và thử giảm hệ số tăng cho số lượng tunnel 16:36 <perv> có undelete cho reiser4 không? 16:36 <jrandom> cơ bản là nếu chúng ta coi như các tunnel hết hạn (ngẫu nhiên) sớm hơn thực tế, sẽ có ích 16:36 <+Complication> Hiện đang đọc hàm lớn "countHowManyToBuild" trong TunnelPool.java :D 16:36 <+Complication> Nhưng tôi chưa đọc hết 16:37 <jrandom> (dù rõ ràng nó sẽ tăng tần suất xây tunnel, điều mà trước 0.6.1.17 là không hợp lý) 16:37 <+Complication> perv: có gì đó 16:37 <jrandom> hmm, đưa ngẫu nhiên hóa vào đó sẽ khó đấy Complication, vì chúng ta gọi hàm đó khá thường xuyên 16:38 * perv cân nhắc cứu dữ liệu và chuyển sang gentoo 16:38 <jrandom> tôi khuyên nên thử ngẫu nhiên hóa thời điểm hết hạn của các tunnel xây thành công 16:38 <+Complication> perv: chắc chắn bạn sẽ đỡ hơn với reiser so với ext3 16:38 <+Complication> perv: nhưng tôi không nhớ nằm lòng 16:38 <+Complication> jrandom: đúng, đôi khi nó có thể xây quá mức (overbuild) theo cách này 16:38 <jrandom> (để hàm countHowManyToBuild hiện có nghĩ rằng nó cần trước khi thực sự cần) 16:38 <+Complication> (và đôi lúc nó tất yếu xây quá mức, khi tunnel hỏng và nó trở nên vội vã) 16:40 <+Complication> Hmm, một khả năng tôi chưa nghĩ tới... 16:41 <+Complication> Dù sao, cũng đang nghịch nó, nhưng chưa có quan sát hữu ích 16:42 <jrandom> hay đấy, tôi cũng có vài tinh chỉnh đang thử, có lẽ chúng ta gom lại cho bản build tới để xem nó chạy thế nào trên mạng đang tạm ổn ;) 16:43 <spinky> Có số liệu nào cho thấy lượng overhead mà mạng i2p thêm vào dữ liệu ứng dụng không? 16:43 <jrandom> "overhead" là một thuật ngữ dễ gây tranh cãi... ;) 16:43 <jrandom> chúng tôi gọi đó là cái giá của ẩn danh ;) 16:43 <spinky> hehe 16:45 <jrandom> (tức là không hẳn. payload tầng ứng dụng trên một mạng hoàn hảo với 0 tắc nghẽn & 1+1hops đạt hiệu suất khoảng 70-80% ở các đầu cuối) 16:45 <jrandom> ((lần cuối tôi đo)) 16:45 <jrandom> nhưng đó thực sự là điều kiện phòng lab 16:45 <jrandom> mạng thực tế phức tạp hơn nhiều 16:47 <spinky> Đúng, ý tôi chỉ là lượng dữ liệu phụ dùng để thiết lập các tunnel, khóa, padding, v.v 16:47 <spinky> ...so với dữ liệu ứng dụng được truyền 16:47 <jrandom> phụ thuộc vào đóng khung thông điệp, tắc nghẽn, tỷ lệ xây tunnel thành công, v.v 16:48 <jrandom> một tunnel 2 hop có thể được xây với mạng phải gánh khoảng 20KB 16:48 <+Complication> Tôi từng muốn thử đo cái đó, chủ yếu nhằm ước lượng "độ lãng phí" của các ứng dụng truyền tải lớn như BitTorrent và I2Phex 16:48 <+Complication> Nhưng tôi chưa từng rảnh để làm một phép đo sạch giữa hai nút của mình 16:48 <+Complication> Một ngày nào đó, tôi sẽ quay lại chuyện đó, though 16:49 <jrandom> Complication: khá khó với các ứng dụng "lắm lời", dễ hơn nhiều nếu đo bằng wget :) 16:49 <+Complication> Quá đúng 16:50 <+Complication> Trong những gì tôi đã thử, không có chút chính xác nào 16:54 <jrandom> ok, nếu không còn gì cho mục 1), ta trượt qua 2) I2Phex 16:55 <jrandom> Complication: dạo này làm gì đấy? :) 16:55 <+Complication> Hôm qua tôi commit một bản sửa cho vài vấn đề mà một số người gặp với bộ phát hiện chạy-lần-đầu ngớ ngẩn của tôi 16:56 <+Complication> Bộ phát hiện chạy-lần-đầu giờ đỡ ngớ hơn, và bar báo rằng nó bắt đầu hành xử bình thường 16:56 <+Complication> Tuy nhiên, vì I2Phex có vẻ đã chạy được trong điều kiện mạng hiện tại, 16:56 <+Complication> tôi sẽ thử tìm cả bug rehash. 16:57 <+Complication> Nếu tôi có thể 16:57 <jrandom> hay đấy, tôi biết con đó ám bạn mấy tháng rồi 16:57 <+Complication> Điều thú vị là Phex nhánh chính có thể cũng dính, và việc xác định + đọc các ghi nhận của họ cũng là thứ tôi sẽ thử làm 16:58 <jrandom> nhưng vui khi nghe bản sửa khởi động đã vào 16:58 <jrandom> à chuẩn 16:58 <+Complication> =là vậy 16:58 <+Complication> Tôi hiện không thể xác nhận Phex nhánh chính có bị hay không, though - cá nhân tôi chưa thấy ở đó 16:59 <jrandom> (lỗi chập chờn)-- 16:59 <+Complication> Khó gây ra theo cách có kiểm soát, nên khó tìm 17:00 <+Complication> Về phía tôi, tạm thời chỉ vậy 17:00 <+Complication> Sau đó, tôi tự hỏi liệu có đáng để giới hạn số lần thử liên hệ peer song song mà I2Phex bắn ra cùng lúc không 17:01 <jrandom> ừ, có lẽ vậy 17:01 <+Complication> Vì chúng sẽ tạo ra cả đống tra cứu NetDB trong thời gian ngắn, và điều đó có thể không hay từ góc nhìn của một router I2P 17:02 <jrandom> và liên hệ đến destination mới cần elG thay vì aes 17:02 <+Complication> Nhưng tôi chưa đọc hay viết mã thực sự nào cho mục tiêu đó 17:04 <jrandom> k np. có lẽ vụ hợp nhất i2phex/phex thần thoại sẽ kèm theo một giải pháp :) 17:04 <+Complication> Và về phần tôi, đó là toàn bộ tin tức từ mặt trận I2Phex... 17:04 <jrandom> tốt, cảm ơn cập nhật và công sức đào sâu! 17:05 <jrandom> ok, chuyển qua 3) ??? 17:05 <jrandom> ai còn gì cần nêu trong buổi họp không? 17:05 <lsmith> xin chào! tôi chỉ muốn khen các dev về những cải tiến tuyệt vời ở bản phát hành mới nhất, tổng bw của tôi chỉ 0.9/1.4 KBps mà tôi vẫn giữ kết nối irc... thật...siêu ngầu :) 17:05 <+Complication> :D 17:06 <jrandom> cảm ơn sự kiên nhẫn của bạn suốt thời gian qua - hỗ trợ người dùng băng thông thấp là then chốt 17:06 <@cervantes> lsmith: điều đó thật tốt để 17:06 <@cervantes> * Connection Reset 17:06 <jrandom> heh 17:07 <lsmith> :) 17:09 <jrandom> ồ, một điều đáng chú ý khác là zzz đã trở lại, và kèm theo anh ấy là stats.i2p :) 17:09 <jrandom> [wewt] 17:11 <+Complication> Một nguồn dữ liệu so sánh khá hữu ích :) 17:11 <jrandom> chắc chắn rồi 17:11 <jrandom> ok, còn ai có gì nữa cho buổi họp không? 17:13 <jrandom> nếu không... 17:13 <jdot> tôi có một hai câu hỏi sau-baf 17:13 <jrandom> heh ok, vậy thì cho baffer lăn bánh nào :) 17:13 * jrandom khởi động... 17:13 * jrandom *baf* kết thúc buổi họp