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

15:25 <jrandom> 0) chào 15:25 <jrandom> 1) Tình trạng mạng và 0.6.1.6 15:25 <jrandom> 2) Syndie 15:25 <jrandom> 3) I2P Rufus 0.0.4 15:25 <jrandom> 4) ??? 15:25 <jrandom> 0) chào 15:25 * jrandom vẫy tay 15:25 <jrandom> ghi chú tình trạng hàng tuần đã đăng @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html 15:26 * bar đưa cho jrandom một cái baf 15:26 <c3rvantes> chưa đâu! 15:26 * jrandom lấy đà 15:26 <jrandom> ờ... 15:26 <jrandom> hãy xử lý vài mục đầu của chương trình nghị sự trước :) 1) Tình trạng mạng và 0.6.1.6 15:27 <jrandom> nhiều thứ đã được cập nhật trong vài bản phát hành gần đây, nhưng mạng vẫn có vẻ khá ổn định. 15:28 <jrandom> đã có vài đợt tăng đột biến về mức độ tham gia của router trên một vài router, tuy vậy cũng khá vô hại 15:28 <+legion> hay đấy, tôi đồng ý tình trạng mạng đang tốt lên. Và ừ, sao không bỏ tcp cho 0.6.1.7 15:28 <jrandom> (ờ, ý là đột biến ở mức độ tham gia của tunnel) 15:29 <@cervantes> anh nói không sai đâu 15:29 <jrandom> chưa chắc đâu legion. có thể có vài người dùng ngoài kia chỉ dùng được tcp, nhưng tôi nhớ là chỉ có một, cùng lắm là hai người như thế 15:29 <+legion> tôi để ý với 0.6.1.5 thì router đôi khi tự khởi động lại. 15:29 <+Complication> Của tôi dao động trong mức hợp lý, 100 đến 250 tunnel tham gia 15:29 <jrandom> Tôi không nghĩ ra lý do lớn nào để giữ nó, nhưng lại có vài lý do để bỏ 15:30 <jrandom> hay đấy Complication 15:30 <jrandom> (những con số đó khá trung bình, theo stats.i2p/, nhưng nhớ là các số liệu như vậy có thể làm tổn hại tính ẩn danh, nên không nên đưa ra, đặc biệt là trong các cuộc họp có log ;) 15:30 <+Complication> Con Celeron cũ của tôi vẫn tự khởi động lại khoảng mỗi 10 tiếng 15:30 <+Complication> Ngoài ra thì kết nối còn tốt hơn trước giờ 15:30 <Pseudonym> lý do để bỏ nó là gì? 15:31 <+Complication> TCP tốn tài nguyên 15:31 <@cervantes> router của tôi kiệt quệ rồi 15:31 <+Complication> xét về số thread trên mỗi kết nối 15:31 <@cervantes> Complication: nhân con số đó lên 10 là ra khoảng hiện tại của router tôi ;-) 15:31 <+legion> Của tôi dao động trong 200-400 tunnel tham gia, nên có vẻ tốt hơn trước. 15:32 <+Complication> cervantes: đau ghê 15:32 <+Complication> Tôi từng thấy một tai nạn kỳ quặc gây ra 2000 tunnel tham gia, nhưng đó là hồi mùa hè 15:32 <jrandom> Pseudonym: hiệu năng (CPU/bộ nhớ, lập lịch tốt hơn do các yêu cầu 'semi-reliable' của chúng ta), khả năng bảo trì, và cho vào blacklist hiệu quả hơn 15:32 <+Complication> Một cú đột biến đơn lẻ, không bao giờ lặp lại 15:32 <+legion> ừ, với vài phiên bản trước có những đợt như vậy 15:32 <jrandom> Complication: với bản sửa gần đây nhất chúng ta đã có các đỉnh > 2000 tunnel 15:33 <jrandom> nhưng hy vọng 0.6.1.7 sẽ xử lý được 15:33 <+legion> Vậy đó là vài lý do tốt để bỏ tcp :) 15:33 <jrandom> nhưng, nhắc lại, các đỉnh về mức tham gia tunnel thì vẫn ổn, vì đa số không được dùng 15:34 <@cervantes> Pseudonym: có vẻ chỉ còn một hai router trên mạng dùng tcp 15:34 <jrandom> cũng có thể nên bỏ tcp ngay trong bản này, vì nó không có thay đổi lớn nào khác. như vậy ta sẽ thấy ảnh hưởng khá rõ ràng 15:34 <jrandom> (và có thể bật lại nếu cần) 15:35 <Pseudonym> nếu chỉ có hai router dùng nó, tôi không nghĩ nó sẽ ảnh hưởng nhiều theo cách nào 15:35 <Pseudonym> (ngoại trừ việc có ít đi hai router trên mạng) 15:35 <@cervantes> 2 khách hàng bực bội 15:35 <jrandom> ờ, transport đó có xuất hiện trong vài tình huống kỳ quặc, đó là một trong các lý do tôi muốn vô hiệu hóa nó :) 15:35 <+Complication> Hy vọng họ không coi đó là chuyện cá nhân 15:36 <+Complication> Một số ISP lọc UDP thật là tệ. 15:36 <+Complication> Tệ và hoàn toàn vô nghĩa. 15:36 <jrandom> (ví dụ khi một router bị hỏng, mọi người đánh dấu SSU transport là lỗi, nhờ thế họ sẽ rơi về tcp transport) 15:36 * Pseudonym yêu ISP của mình. không hạn chế 15:37 <+Complication> Vậy không có TCP, ta sẽ thấy UDP tự xử lý nó ra sao? 15:37 <+Complication> "không có bánh phụ" :P 15:37 <+legion> hả vậy làm sao vượt qua kiểu lọc khó chịu đó mà không có tcp? 15:38 <jrandom> chính xác đó Complication :) 15:38 <jrandom> legion: chúng ta không 15:38 <jrandom> (restricted routes (đường đi bị hạn chế)) 15:38 <+Complication> Ờ, chẳng phải có khá nhiều ứng dụng hữu ích ngoài các chương trình chia sẻ file cũng dùng các gói UDP lớn hơn gói DNS sao? 15:39 <+legion> :( nghe không ổn lắm 15:39 <+Complication> kích thước tương tự kích thước gói nhỏ nhất mà I2P dùng? 15:39 <jrandom> ờ legion, không phải vấn đề đâu 15:39 <jrandom> Complication: các giao thức streaming 15:39 <+Complication> Không thể chặn UDP trực tiếp, nếu không sẽ làm tê liệt DNS. 15:39 <+Complication> Người ta có thể giới hạn kích thước gói. 15:40 <+legion> ok, nghe như có thể là vấn đề 15:40 <+Complication> VoIP? 15:40 <jrandom> nó sẽ thành vấn đề nếu lan rộng - nếu cộng đồng internet nói chung cấm udp 15:40 <+Complication> Hmm, VoIP dùng gói lớn hay nhỏ? 15:40 <jrandom> nhưng nếu chỉ là vài ISP, ta có thể xử lý họ như restricted routes 15:40 <+Complication> Hay ý bạn là kiểu... video streaming? 15:40 <+legion> Tôi nghĩ là dùng cả hai 15:41 <jrandom> cả hai Complication, RTSP chạy trên UDP, và real chạy trên RTSP nếu tôi nhớ đúng 15:41 <+Complication> s/p/s 15:42 <+legion> Vậy chuyển sang mục tiếp theo? 15:42 <+Complication> cat /etc/services | grep -c udp 15:42 <+Complication> 227 15:43 <jrandom> Tôi vẫn chưa chắc có bỏ tcp trong 0.6.1.7 không, nhưng có lẽ là có. 15:43 <jrandom> ừ, còn ai có gì về mục 1) không? nếu không, nhảy sang 2) Syndie 15:43 <+Complication> Tức là có ít nhất 227 ứng dụng (một số có thể đã lỗi thời hoặc là ứng dụng LAN) dùng UDP 15:44 <jrandom> bah, đây là intarweb. bạn chỉ cần truy cập HTTP qua proxy là đủ 15:44 <jrandom> Tôi không có nhiều để thêm cho mục 2) ngoài những gì trong mail (và trên Syndie) 15:44 <+legion> Tôi bị thuyết phục rồi, ừ bỏ nó đi. :) 15:44 <jrandom> ai có gì liên quan đến syndie muốn nêu không? 15:45 <+legion> Tôi cũng không có gì để nói về mục 2). 15:45 * Complication đang đọc "how Syndie works" 15:46 <+Complication> Có một hiệu ứng UI nhỏ cứ làm tôi bất ngờ. :D 15:46 <+Complication> Khi tôi mở rộng một luồng (thread) thông điệp, tôi luôn bất ngờ khi thông điệp đang hoạt động lại nhảy lên thành mục trên cùng trong danh sách. :P 15:47 <+Complication> Nhưng có lẽ bạn có thể bỏ qua. Tôi chỉ hơi khó tính và là người sống theo thói quen. :P 15:47 <@cervantes> mô hình threading đang được thảo luận khá kỹ 15:47 <@cervantes> ;-) 15:47 <+Complication> Tôi sẽ quen thôi. :) 15:48 <+Complication> cervantes: trong Syndie? Tôi phải tìm thread đó. :) 15:48 <@cervantes> Tôi cũng không thích - nhưng nó có thể sẽ thay đổi 15:48 <jrandom> ừ, tôi đoán điều đó hơi kỳ cục 15:48 <+legion> ừ 15:48 <@cervantes> "subject: syndie threading" 15:49 <+Complication> Hơn nữa, nếu thông điệp được mở rộng ở dưới cùng, nó vẫn sẽ phải di chuyển thôi. 15:49 <+Complication> Vì nếu không nó sẽ kẹt ở đó. 15:50 <jrandom> ừ, phần điều hướng (nav) ở dưới cùng hiển thị 10 *threads* mỗi lần, không phải 10 thông điệp. nên nó có thể mở rộng thread dưới cùng 15:50 * cervantes đang thử nghiệm vài triển khai kiểu UI threading khác nhau lúc này 15:51 <jrandom> tuyệt 15:51 <jrandom> ừ, lý tưởng thì ta có thể hoán đổi chúng trong css, hoặc nếu không thì ở phía server 15:52 <@cervantes> chính xác hơn là "threading navigation styles" 15:53 <@cervantes> hmm các thử nghiệm của tôi mặc định dùng danh sách lồng nhau html thuần, dạng không thứ tự (unordered) 15:53 <@cervantes> bạn có thể đắp bao nhiêu css và javascript tùy nhu cầu hoặc muốn 15:53 <jrandom> có ETA nào về lúc chúng ta có thể xem vài mockup không? 15:53 <@cervantes> (tuy nhiên đó chỉ là bằng chứng khả thi (proof of concept), không phải triển khai UI thực sự) 15:54 <@cervantes> Tôi làm phần lớn việc coding trong các buổi họp I2P ;-) 15:54 <jrandom> hê 15:54 <@cervantes> có lẽ mockup đầu tiên sẽ sẵn sàng tối nay 15:54 * jrandom lên lịch họp hàng ngày 15:54 <jrandom> tuyệt 15:54 <@cervantes> trời ạ :) 15:55 <jrandom> ok, còn ai có gì cho 2) syndie không? 15:55 <jrandom> nếu không, chuyển sang 3) I2P Rufus 0.0.4 15:56 <jrandom> Tôi không có nhiều để thêm ngoài những gì trong mail - Rawn/defnax, mọi người còn ở đây chứ? 15:56 <+legion> vậy 0.0.4 tốt đến đâu? Còn vấn đề gì không, nếu có? 15:57 * jrandom chịu 15:58 <+legion> Có lẽ một trong số người dùng của nó có thể trả lời. Nó có vẻ tốt và ổn định chứ? 15:58 <jrandom> ok, có vẻ Rawn và defnax đang vắng mặt atm. nếu ai có câu hỏi/bình luận/quan ngại liên quan đến I2P Rufus, ghé qua diễn đàn và đăng lên nhé 15:58 <+legion> chết tiệt, chắc phải vậy rồi. 15:59 <+legion> sang 4) nhé? 15:59 <jrandom> ừ, có vẻ vậy. ok, 4) ??? 15:59 <+Complication> Tiếc là tôi chưa thử I2P Rufus. 16:00 <jrandom> ai còn điều gì muốn nêu không? 16:00 <jrandom> (nào nào, ta phải kéo dài thêm để cervantes còn làm thêm việc!) 16:00 <+legion> ừ, có những thứ thú vị nào sắp tới? 16:00 <+bar> có chỗ nào tôi có thể đọc thêm về "restricted routes" không? 16:00 <+bar> (tôi *đã* tìm rồi) 16:01 <+legion> Có lẽ ta còn có thể bàn về i2phex? 16:01 <jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD 16:01 * cervantes đặt chuột sẵn sàng trên nút đóng 16:01 <jrandom> ờ, #future.restricted 16:02 <jrandom> cộng thêm các trang how_* & todo 16:02 <jrandom> (trên web) 16:02 <+Complication> Heh, có vẻ I2P đã nhảy qua một build :D 16:02 <+Complication> :D 16:02 <+bar> cảm ơn 16:02 <+Complication> - public final static long BUILD = 1; 16:02 <+Complication> + public final static long BUILD = 3; 16:03 <jrandom> legion: một số hacking trên netDb, chỉnh hiệu năng, restricted routes, cải tiến streaming, cải tiến eepproxy, cải tiến tunnel, v.v. nhiều thứ lắm, nhưng chưa có gì sẵn sàng 16:03 <+legion> hả, lạ nhỉ 16:03 <jrandom> có gì muốn nêu về i2phex không legion? 16:03 <jrandom> Complication: ừ, cố ý. Tôi quên tăng nó cho BUILD = 2 16:03 <+Complication> (không phải nó ảnh hưởng gì, chỉ thắc mắc liệu tôi đã từng thấy dịp hiếm như vậy chưa :) 16:04 <+legion> tuyệt, nghe hay đấy, cảm ơn! 16:04 <jrandom> ồ, điều đó làm tôi nhớ... sẽ thật tuyệt nếu ai đó muốn đào sâu việc làm lại trang web của chúng ta 16:05 * jrandom không muốn nghĩ về nó, nhưng sớm muộn cũng phải làm 16:05 <+legion> ừ, có đấy 16:05 <+legion> giờ cập nhật i2phex lên mã phex cvs mới nhất có đáng không? 16:06 <+Complication> Không chắc, tôi chưa nghe tin từ Redzara gần đây 16:06 <jrandom> lần cuối tôi nhớ, redzara đang đợi cập nhật phex của gregorz 16:06 <jrandom> (để ta có thể có một lần cập nhật/mở rộng khá sạch) 16:08 <+legion> hả, vậy thì cần i2phex làm gì? 16:08 <+Complication> Phòng khi cần? 16:08 <jrandom> hmm? 16:08 <jrandom> i2phex là một extension cho phex 16:08 <+legion> Có vẻ họ muốn chỉ có phex với một i2p extension 16:09 <jrandom> extension, theo nghĩa là sửa đổi một số rất ít thành phần 16:09 <jrandom> ờ, s/bits/components/. để chúng ta có thể dễ dàng cập nhật mã bất cứ khi nào các dev phex sửa thứ gì 16:10 <+legion> nếu vậy thì tôi không phải tốn nhiều công để cập nhật nó lên mã cvs mới nhất, dù tôi biết rồi sẽ tốn công thôi. 16:10 <jrandom> theo tôi nghe trên diễn đàn thì kế hoạch là để I2Phex và Phex là hai ứng dụng riêng, nhưng sẽ chia sẻ phần lớn mã 16:10 <jrandom> ừ legion, thế thì tuyệt, nhưng lần cuối tôi nghe, Gregor vẫn chưa hoàn tất các sửa đổi cho Phex 16:11 <jrandom> (điều mà redzara đang đợi) 16:11 <+legion> à tôi hiểu 16:11 <jrandom> vậy lựa chọn thay thế là hoặc giúp Gregor, hoặc tiếp tục sửa codebase I2Phex hiện có 16:12 <+legion> vậy thì nếu tôi không chờ và chỉ cập nhật i2phex với mã mới, sẽ không cần redzara tiếp tục 16:12 <jrandom> ờ, không hẳn. 16:12 <jrandom> cập nhật I2Phex lên mã Phex hiện tại sẽ rất tốt, đúng 16:13 <jrandom> nhưng ngay khi các nhà phát triển Phex cập nhật mã Phex của họ, chúng ta lại lệch nhịp 16:13 <+legion> ok, tôi có lẽ sẽ làm việc đó tối nay hoặc trong vài ngày tới. 16:13 <jrandom> tuyệt 16:13 <+legion> Thế cũng được. 16:14 <+legion> Thực ra tôi không kỳ vọng i2phex luôn đồng bộ với mã phex, chỉ là có vẻ cvs chứa các bản vá mà i2phex chắc chắn có thể dùng. 16:15 <+legion> Tôi cũng muốn loại bỏ mọi mã và tính năng của phex mà i2phex không cần. 16:15 <jrandom> hay 16:16 <+legion> Về các tính năng mới và sửa những thứ vẫn chưa chạy như hàng đợi upload... Tôi đã xem xét để webcache chạy được, nhưng còn nhiều việc phải làm. 16:17 <jrandom> chuẩn. ừ, phex từng có hỗ trợ gwebcache hoạt động, nhưng sirup đã tắt nó vì ban đầu không cần 16:17 <+legion> Tôi dự định cuối cùng sẽ thêm jeti vào i2phex. 16:17 <jrandom> hay đấy 16:18 * jrandom chưa bao giờ dùng jeti, và tôi hy vọng nó sẽ là thành phần tùy chọn, nhưng hỗ trợ thêm nhiều thứ thì vẫn ngầu 16:18 <+legion> Ừ nó có thể là tùy chọn, người dùng sẽ có thể tải một jeti2phex ;) 16:19 <jrandom> chuẩn 16:19 <+legion> Vẫn còn nhiều việc ta có thể làm với i2phex, dù hiện tại nó hoạt động rất tốt. 16:20 <+legion> Cho đến giờ việc giữ một client kết nối, chạy 24/7 là khả thi và dễ. 16:21 <jrandom> ừ, tôi đã có vài thành công tốt với nó... "sao lưu các bản thu âm có bản quyền của tôi" 16:21 <+legion> hê :) 16:22 <jrandom> ok, còn ai có gì cho buổi họp không? 16:23 * cervantes lăn cái cồng chiêng Trung Quốc vào 16:23 <+legion> Hình như tôi quên cái gì đó... hmm 16:24 <+legion> À đúng rồi, có ý tưởng nào về cách giảm lượng bộ nhớ mà i2p và i2phex tiêu thụ không? 16:25 <+Complication> Ờ, TCP transport chiếm kha khá 16:25 <jrandom> có thể chạy cả hai trong cùng một jvm 16:25 <+Complication> Nếu bỏ được cái đó, sẽ giải phóng được chút 16:26 <@cervantes> rút vài thanh RAM khỏi máy của bạn đi 16:26 <cat-a-puss> ai có kinh nghiệm với javolution biết nó có giúp được không? http://javolution.org/ 16:26 <jrandom> (clients.config trong thư mục cài đặt i2p định nghĩa main class và các tham số để khởi chạy client) 16:26 <+legion> Vậy nếu chạy cả hai trong cùng một jvm và khi bỏ tcp, ta có thể kéo xuống dưới 50mb không? 16:27 <jrandom> không biết nữa legion. còn tùy “50MB” bạn nói là gì. RSS/VSS/v.v 16:27 <jrandom> Tôi thật sự không khuyên chạy cả hai trong một JVM, trừ khi bạn giữ cả hai chạy mọi lúc, vì tắt một cái sẽ giết cái kia 16:27 <@cervantes> legion: giới hạn băng thông và đặt trần số người tham gia cũng có thể giúp 16:27 <jrandom> ừ, như cervantes nói 16:28 <cat-a-puss> theo tôi nếu ta biết chính xác số lượng một kiểu đối tượng nào đó mà ta có khả năng sẽ dùng, nó sẽ giúp tránh việc JVM cấp phát quá đà 16:28 <+Complication> Đúng, nó tạo ra các kiểu cấp phát khác nhau, mà tôi chưa bao giờ hiểu hết 16:28 <jrandom> ừ, ta có làm một phần như vậy cat-a-puss (xem net.i2p.util.ByteCache) 16:29 <+Complication> (nhưng như đã nói, Java còn rất mới với tôi) 16:29 <jrandom> Tôi đã liếc qua javolution trước đây, nhưng có vẻ nó đã tiến bộ nhiều. tôi sẽ xem lại 16:30 <cat-a-puss> jrandom:Tôi biết vài người ở chỗ làm dùng nó và hài lòng, dù họ không quan tâm đến cấp phát bộ nhớ 16:31 <jrandom> ờ, nó thực ra sẽ không tiết kiệm bộ nhớ, nhưng sẽ giúp giảm churn của GC 16:31 <+legion> Cá nhân tôi không quá bận tâm chuyện cấp phát bộ nhớ, tuy nhiên nhiều người có. 16:31 <jrandom> ồ, và nó còn dùng giấy phép BSD nữa 16:31 <cat-a-puss> đúng vậy 16:31 <jrandom> legion: cấp phát bộ nhớ đồng nghĩa với hiệu năng 16:32 <+legion> ờ, à, vậy là mức tiêu thụ bộ nhớ 16:33 <+legion> Nhiều người rất thích uTorrent vì footprint bộ nhớ rất nhỏ. 16:33 <jrandom> à, ừ, đúng. ta có thể tinh chỉnh dần, nhưng vì i2p chạy trong kích thước mặc định của jvm, tôi không quá lo (vì còn nhiều chỗ để tinh chỉnh) 16:34 <jrandom> ok, còn ai có gì cho buổi họp không? 16:35 <+legion> không, tôi ổn rồi... 16:37 * jrandom lấy đà 16:37 * jrandom *baf* kết thúc cuộc họp