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

13:04 <jrandom> 0) chào 13:04 <jrandom> 1) 0.5 13:04 <jrandom> 2) Các bước tiếp theo 13:04 <jrandom> 3) azneti2p 13:04 <jrandom> 4) ??? 13:04 <jrandom> 0) chào 13:04 * jrandom vẫy tay 13:05 <jrandom> ghi chú trạng thái hàng tuần đã đăng @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html 13:05 <jrandom> (ừ, chỉ trước cuộc họp một hai phút thôi, nên hãy thử khả năng đọc nhanh của bạn) 13:05 <+detonate> tôi nghĩ tôi sẽ đợi đến khi nó bớt lỗi rồi mới đưa Boondock Saints lên, trong trường hợp đó 13:06 <jrandom> sao... đó là... đó là... đó là vi phạm bản quyền! 13:06 <+detonate> những bổ sung kỳ lạ mới cho bản beta Azureus 13:06 <+detonate> phân loại 13:06 <+detonate> haha 13:06 <+detonate> một tracker DHT 13:06 <+detonate> tuyệt 13:07 <jrandom> ừ, trông rất ngầu, nhưng hãy xử lý mục 1 và 2 trước mục 3, nhé? ;) 13:07 <+detonate> chào 13:07 <+detonate> đúng vậy 13:07 <jrandom> nhảy vào 1) 0.5 13:07 <jrandom> nó, kiểu như, đã phát hành rồi, đại loại vậy 13:08 <cervantes> yay! 13:08 <jrandom> tối nay sẽ có một bản rev mới với một đống cập nhật (CVS head hiện tại là 0.5-5, với -6 đang được thử nghiệm trên một số router) 13:09 <jrandom> mọi thứ diễn ra khá ổn, nhưng chúng ta đã đụng một vài bug kỳ quặc trên đường. nhưng kệ thôi, đời mà 13:09 <frosk> tôi có thể báo là 0.5-5 thân thiện hơn _rất nhiều_ so với -4 (vốn thường cho tôi số lượng participating tunnel lên đến hàng nghìn) 13:09 <bla> jrandom: Bản 0.5.0.1 có sửa vấn đề không thể tìm thấy destinations không? 13:09 <jrandom> à, ừ, cái đó thực ra phụ thuộc vào người khác thôi, bản -0 thực sự có dựng hàng trăm tunnels 13:09 <bla> s/nor/not 13:10 <jrandom> bla: vâng, đó là bug trong netDb 13:10 <bla> jrandom: Tuyệt! 13:10 <jrandom> (cụ thể là trong việc publish leaseSet) 13:11 <jrandom> và vâng, bản 0.5.0.1 sẽ loại bỏ bug thỉnh thoảng proxy biến mất 13:12 <jrandom> vẫn còn một rò rỉ bộ nhớ kỳ quặc mà tôi chưa lần ra, ảnh hưởng đến một số người dùng 13:12 <bla> Vậy nhìn chung, có vẻ ngoài những bug đó, mạng 0.5 chạy rất tốt. Yay! 13:12 <jrandom> theo tôi biết, nó chỉ thực sự ảnh hưởng đến hai ba instance I2PTunnel thôi 13:12 <Meomia> có phải là dấu hiệu tiến bộ khi bạn từ 0 lên 130 participating tunnels kể từ 0.5 không? 13:13 <jrandom> w3wt 13:13 <jrandom> Meomia: bah, tôi đã từng có hơn 5000 tunnels ;) 13:13 <jrandom> nhưng dm thực ra đã giúp tìm một bug trong code exploratory pool, nên chúng ta sẽ dựng tunnels thường xuyên hơn trên các peer 'random' 13:14 <jrandom> (yay) 13:14 <Meomia> ok 13:14 <bla> jrandom: Điều đó cũng có nghĩa là bây giờ, trái với 0.4, mọi peer đều có thể tại một thời điểm trở thành inbound gateway của bạn? 13:14 <jrandom> đúng, đối với exploratory tunnels 13:15 <jrandom> client tunnels sẽ chỉ dùng các peer trong tier 'fast' 13:15 <bla> bla: Ok. Việc client tunnels chỉ dùng các peer nhanh là tốt: nếu không, ta gặp vấn đề ẩn danh như đã bàn trước 13:16 <jrandom> và hiệu năng sẽ tệ nếu không làm vậy ;) 13:17 <jrandom> thực ra, điều đó đưa ta đến 2) Các bước tiếp theo 13:18 <jrandom> việc lớn còn lại cho dòng 0.5 là một loạt chiến lược để sắp xếp và/hoặc lọc các peer dùng trong tunnels 13:18 <godmode0> jrandom có thể dùng NNTP với I2P không? 13:18 <jrandom> godmode0: có hai NNTP server trên I2P, đúng vậy. xem diễn đàn 13:19 <godmode0> jrandom ok tôi đang thử 13:19 <godmode0> tôi có thể dựng server của mình nữa không? 13:20 <jrandom> godmode0: chúng ta đang họp ngay lúc này, nhưng vâng, bạn có thể chạy một server 13:20 <godmode0> jrandom ok xin lỗi 13:20 <jrandom> không sao 13:20 <jrandom> các chiến lược đã đăng cơ bản nhằm cải thiện tính ẩn danh, nhưng có vài mục tiêu khác mà ta có thể cân bằng trong đó 13:21 <jrandom> có lẽ ta có thể tìm cách tích hợp một số AS (Autonomous System - hệ tự trị) paths vào việc lựa chọn, như bla đề xuất 13:22 <jrandom> việc đó vừa có thể cải thiện ẩn danh (theo khu vực pháp lý), hoặc nếu ta cố gắng ở trong một AS (hoặc hai), nó có thể cải thiện hiệu năng 13:22 <bla> jrandom: Điều này về cơ bản liên quan đến một bài viết của những người tạo Tor: http://theland.i2p/files/routing-zones.pdf 13:22 <jrandom> ừ 13:23 <jrandom> có cả một loạt chiến lược khác nhau mà mọi người có thể dùng, và thử các cái mới thì khá dễ 13:24 <jrandom> chúng tôi sẽ không dành nhiều tháng để triển khai mọi thứ nghĩ ra, mà chỉ cung cấp những thứ cơ bản mà đa số cần. ai muốn bổ sung cái mới thì rất được khuyến khích giúp cắm chúng vào 13:25 <jrandom> dù sao, khi những phần cơ bản đã ổn, chúng ta sẽ chuyển sang tập trung vào transport UDP cho 0.6 13:26 <jrandom> đó là tất cả tôi có cho 2) Các bước tiếp theo, ai có bình luận/câu hỏi/quan ngại gì không? 13:26 <bla> Những người bắt đầu xem xét I2P là ai ấy nhỉ? 13:26 <bla> Có vẻ dạo này không nghe nhiều từ họ. 13:27 <bla> s/into I2P/into UDP/ 13:27 <bla> xin lỗi 13:27 <jrandom> à, mule bị ốm, nhưng tôi nghĩ detonate đang tiến triển 13:28 <jrandom> detonate: có tin gì không? 13:29 <jrandom> hoặc có lẽ không ;) 13:30 <jrandom> ok, chuyển sang 3) azneti2p 13:30 <+detonate> xin lỗi 13:30 <+detonate> tôi đang tiến triển 13:30 <+detonate> tôi vẫn cần hoàn tất phần ghép lại (re-assembly) 13:31 <+detonate> về phần chia dữ liệu thành các gói và gửi đi một cách có trật tự thì đã hoạt động 13:31 <+detonate> sang 3) 13:31 <jrandom> tuyệt 13:31 <godmode0> xin lỗi bước 2) I2P có vấn đề gì với các cuộc tấn công không? 13:31 <bla> detonate: Tuyệt! Bạn có thể cập nhật cho mọi người trên diễn đàn không? 13:32 <+detonate> bla: chắc rồi 13:32 <tracker> Về azneti2p, xem ở đây: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 có vẻ download được, nhưng không seed. 13:32 <jrandom> godmode0: các chiến lược sắp xếp khác nhau sẽ cho phép người dùng lựa chọn mức ảnh hưởng của tấn công predecessor (tiền nhiệm) 13:33 <microsoft> ai đang vận hành i2p.net nên thêm nhiều buzzword Enterprise Class Solutions vào trang. 13:33 <+detonate> ai đó cần đảm bảo DHT tracker mới cũng không cư xử sai, liên quan đến plugin Azureus 13:33 <tracker> Các thử nghiệm cục bộ của tôi có vẻ xác nhận điều này, tôi có thể download bằng Azureus nhưng không seed. 13:34 <jrandom> hmm ok hay đấy tracker, cảm ơn - tôi biết họ đã cập nhật vài thứ và phát hành b34 tối qua, nhưng có vẻ còn việc phải làm 13:34 <jrandom> detonate: điểm hay 13:35 <tracker> Điểm hay detonate, tôi tắt DHT vì Azureus chết sau vài giờ với 100% CPU khi nó bật. 13:35 * jrandom muốn nhắc lại rằng plugin azneti2p vẫn còn ở giai đoạn beta khá sớm, và các hệ quả về ẩn danh của Azureus chưa được kiểm tra đầy đủ 13:36 <jrandom> dù tôi chắc họ thích có người thử nghiệm, những ai cần ẩn danh có lẽ nên thận trọng 13:36 <tracker> Mặt khác, i2p-bt hoạt động rất tốt. Trừ việc nó không đóng các tunnels, nhưng theo tôi thì không quá tệ. 13:37 <jrandom> ồ, việc đó vẫn xảy ra với bạn à tracker? tôi chưa tái hiện được 13:37 <jrandom> bạn đang dùng bản 0.1.7, đúng không? 13:37 <tracker> Đúng vậy. 13:38 <jrandom> ok tuyệt, nếu nó xảy ra thường xuyên với bạn tôi muốn hỏi nhờ bạn sau cuộc họp để lần nguyên nhân 13:39 <tracker> Có lẽ liên quan đến việc chạy trên XP thay vì Linux hay Unix. Đóng tunnel hoạt động với Azureus, nên tôi đoán là do I2P-BT. 13:39 <jrandom> hmm đúng, i2p-bt dùng SAM, còn Azureus dùng trực tiếp i2p SDK 13:40 <tracker> Nhân tiện. Tôi đã gửi bạn một báo cáo bug trên diễn đàn. Timestamper bị chết trên các cvs-build mới nhất của I2P. 13:40 <jrandom> à hay, cảm ơn, hôm nay tôi chưa xem PM ở đó 13:41 <jrandom> trên -5 hay -4? hay sớm hơn? 13:42 <jrandom> à, -4. ok tuyệt 13:42 <jrandom> cảm ơn, tôi sẽ sửa cái đó cho 0.5.0.1 13:42 <jrandom> ok, ai còn gì cho 3) azneti2p không? 13:43 <tracker> Nó cũng xảy ra trên -5 13:43 <jrandom> bạn có khai báo server sntp rõ ràng, đúng không? 13:44 <tracker> Có. Hai cái của nước chúng tôi. 13:44 <jrandom> tôi vừa kiểm tra source và exception xảy ra nếu số # concurring servers (mặc định = 3) lớn hơn số # servers được chỉ định (mặc định mới là 3) 13:44 <jrandom> ok tuyệt, đó là một sửa nhỏ để % # servers 13:45 <jrandom> ok, nếu không còn gì cho azneti2p, chuyển sang 4) cổ điển ??? 13:46 <jrandom> ai còn điều gì muốn nêu trong cuộc họp? 13:46 <tracker> Tốt. Tôi vừa gửi bạn các lỗi log từ router khi đóng i2p-bt trên diễn đàn. 13:47 <jrandom> 'k ok, cảm ơn 13:47 <cervantes> không có gì ngoài: làm tốt lắm với đợt triển khai 0.5, trông như nó sẽ rất ngon khi các bug được xử lý 13:48 <tracker> Ừ, các bản build CVS mới nhất chạy rất tốt bên này. 13:48 <jrandom> cảm ơn, với sự giúp đỡ của bạn và phần còn lại của các tester 0.5-pre chúng tôi đã dọn dẹp được một đống vấn đề 13:49 <jrandom> hiệu năng tốt hơn tôi mong đợi, dù vẫn chưa đạt thông lượng cao như trước. còn nhiều thứ để tối ưu 13:49 <cervantes> lạ là các bản pre ổn định hơn... với tôi, nhưng tôi chạy chúng trên máy khác ;-) 13:49 <jrandom> (và mấy con bug chết tiệt này để đưa độ tin cậy về đúng mức) 13:50 <jrandom> heh ừ, nhưng mạng -pre là 5-7 routers, tất cả cực kỳ ổn định trên các kết nối rất rất nhanh 13:50 <cervantes> :) 13:51 <cervantes> đăng ký tôi vào đợt thử pre 0.6 nhé :) 13:51 <jrandom> heh 13:51 <tracker> Có lẽ tôi nên tham gia mạng pre tiếp theo. Cung cấp một kết nối rất không ổn định và chậm ;). 13:51 <jrandom> việc chuyển sang 0.6 có lẽ còn dễ hơn, tôi hy vọng, vì ta chỉ cần thêm địa chỉ router mới vào routerInfo (địa chỉ UDP) 13:51 <jrandom> heh word 13:51 <cervantes> Tôi có thể đưa chia sẻ 1TB lên online... 13:52 <jrandom> chắc chắn chúng ta sẽ cần rất nhiều trợ giúp với việc thử nghiệm 0.6, bao gồm đủ loại cấu hình mạng 13:52 <hobbs> lệnh ssh '~C' khá hay 13:52 <laberhorst> đây có sẽ là một bước nữa không tương thích chứ? 13:53 <Myo9> Có ai biết NNTP servers nào đang chạy không? 13:53 <jrandom> laberhorst: không, 0.6 sẽ tương thích ngược 13:53 <jrandom> Myo9: không biết, chúng có thể đang chạy nhưng bị dính bug 0.5-0 13:54 <jrandom> bản 0.5.0.1 sẽ sửa nhiều vấn đề, và khi ra, rất khuyến nghị nâng cấp 13:54 <laberhorst> vậy cứ build một bản test 0.6 và đưa cho tester 13:54 <cervantes> chúng ta có thể làm cho traffic BT chỉ dùng các router lỗi thời... như vậy sẽ khuyến khích người ta nâng cấp ;-) 13:54 <laberhorst> vậy là tiệc nâng cấp lớn vào ngày mai 13:54 <jrandom> sẽ có thông báo trên diễn đàn và mailing list khi sẵn sàng 13:54 <jrandom> đúng đó laberhorst 13:54 <jrandom> heh cervantes ;) 13:55 <laberhorst> *háo hức test giúp bạn* 13:55 <jrandom> Hiệu năng BT khá tốt trên 0.5, tôi đã thấy nhiều chuyển file lớn thành công trên các tracker 13:55 <laberhorst> pload rate: 8.85 kB/s 13:55 <jrandom> (và IRC không bị ảnh hưởng như trước, ngoài các vấn đề với tunnel của duck) 13:55 <tracker> Còn tùy bạn gọi là lớn thế nào ;) 13:56 <jrandom> tracker: tôi đang nghĩ đến một file 874MB cụ thể có khá nhiều lượt tải thành công ;) 13:56 <jrandom> nhưng đúng, với vài người thì thế là nhỏ 13:56 <laberhorst> chắc chỉ là phim người lớn cổ điển 13:56 <laberhorst> tôi đoán ;-) 13:57 <laberhorst> hy vọng từ ngày mai, router của tôi sẽ không tham gia >3000 tunnels 13:57 <tracker> Ok, thế là lớn. 13:57 <laberhorst> hoặc, nếu vậy thì mạng THỰC SỰ lớn 13:57 <jrandom> heh laberhorst 13:58 <jrandom> ok, ai còn gì nữa cho cuộc họp? 13:58 <laberhorst> nhân tiện, tham gia >3000 có phải là đồng nghĩa với một router tốt, tin cậy trong I2P với kết nối nhanh không? 13:58 <+detonate> tôi sẽ đưa Boondock Saints lên sau khi tôi lấy House tối nay :) 13:59 <+detonate> sẽ là khoảng 4.1GB ngon lành :) 13:59 * laberhorst chỉ muốn cảm ơn các developer vì dập bug nhanh 13:59 <+detonate> có vẻ nhu cầu lớn 13:59 <laberhorst> ồ, cũng có vài ảnh đĩa DVD ở đây nữa, 13:59 <hobbs> detonate: ồ, đúng rồi. House. :) 13:59 <tracker> cervantes, bạn đã nâng cấp lên phpBB 2.0.12 chưa 13:59 <laberhorst> nhưng hãy đợi đến khi 0.5.0.1 ra 13:59 <+detonate> cũng sẽ test kỹ 0.5.0.1 14:00 <+detonate> ừ 14:00 <+detonate> tôi định vậy 14:00 <jrandom> dĩ nhiên chỉ những người đã sở hữu bản hợp pháp của các file đó mới nên tải xuống. chỉ để thử nghiệm thôi 14:00 <jrandom> *khụ* 14:00 <tracker> rofl 14:01 * jrandom ghi chú mpaa.i2p 14:01 <+detonate> heh 14:01 <laberhorst> ồ, tôi có thể tạo ảnh ISO từ Debian, Fedora, SuSE, các bức ảnh tôi chụp,... 14:01 <laberhorst> vậy là rất nhiều nội dung hợp pháp 14:01 <laberhorst> nếu bạn chỉ muốn test, /dev/random là RẤT lớn 14:01 <Ragnarok> không phải lúc nào 14:02 <laberhorst> nhân tiện, cho những cuối tuần cô đơn: cat /dev/random | grep linux :-) 14:02 <jrandom> heh 14:02 <frosk> /dev/random thường cạn sạch, tôi thích /dev/urandom :) 14:02 <frosk> hoặc /dev/jrandom mới, cải tiến 14:02 <jrandom> không, cái đó toàn core dump suốt 14:03 <jrandom> và cần nghỉ đêm 14:03 <Ragnarok> cách tốt nhất để tạo entropy cho /dev/random là gì? 14:03 <laberhorst> chúng ta thực sự nên lập quỹ 'mua cho jrandom vài lon bia' 14:03 <frosk> gọi là nghỉ ngơi hay gom entropy :) 14:03 <hobbs> Ragnarok: Tùy bạn thực sự muốn nói gì. Lấy một phần cứng RNG sẽ là cách 'tốt nhất' :) 14:03 <jrandom> Ragnarok: phụ thuộc vào OS của bạn (và việc bạn có phần cứng hay không ;) 14:04 <tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Luôn thú vị ;) 14:04 <jrandom> chúng tôi sẽ thực sự đóng gói một triển khai Fortuna trong một bản build sắp tới, và sẽ cần tìm kiếm các nguồn entropy khác nhau 14:04 <Ragnarok> không có phần cứng :P 14:04 <susi23> . o O ( Tôi tưởng ai dùng I2P cũng biết vì sao không nên dùng /dev/urandom ) 14:05 <cervantes> tracker: các lỗ hổng bảo mật được xử lý trong 2.0.12 thì mod_rocinante của tôi vô tình đã sửa, nên tôi chưa bận tâm nâng cấp 14:05 <hobbs> susi23: khi chỉ để nghịch ngợm thì tôi nghĩ ổn ;) 14:05 <ant> <Nolar> ai ở đây làm bản port BT bằng Python? 14:05 <jrandom> Nolar: đó là duck 14:06 * duck huýt sáo 14:06 <ant> <Nolar> duck: tại sao các bạn đổi kích thước khối request thành 128k? 14:06 <susi23> . o O ( người tiếp theo sẽ gợi ý: while true; do echo $RANDOM>> largefile; done ) 14:06 <ant> <Nolar> đó là lý do az không thể seed cho bạn 14:06 <tracker> cervantes: Ok 14:06 <ant> <Nolar> chúng tôi chặn các request> 64k 14:06 <laberhorst> chà, tôi cần thêm mp3 14:06 <frosk> susi23: để grep linux vào một buổi tối rảnh rỗi, /dev/urandom là ổn :) 14:07 <jrandom> à, luôn như vậy à? nếu nhớ không lầm i2p-bt dùng 128k đã một thời gian 14:08 <ant> <Nolar> ừ, như vậy từ đầu :) 14:08 <ant> <Nolar> có lý do gì dùng 128 không? 14:08 <ant> * duck xem qua cvs log 14:08 <jrandom> giữ cho pipeline đầy, I2P có độ trễ mà ;) 14:08 <jrandom> với 32KB, về cơ bản đó là cửa sổ cố định kích thước 1 14:09 <jrandom> nên mỗi message bị chặn chờ ACK, trong khi 128KB cho phép 4 message bay trong RTT 14:09 <@duck> đúng, kích thước slice tối đa cho phép theo đặc tả BT 14:09 <ant> <Nolar> chà, có hai cách xử lý: 1) chúng tôi nâng giới hạn lên 128k phía chúng tôi, hoặc 2) bạn đơn giản pipeline nhiều request hơn 14:09 <cervantes> i2pbt nhanh nhạy hơn trước một chút... có lẽ bạn có thể giảm xuống... 14:10 <@duck> schni, schna, schnappi 14:10 <ant> <Nolar> vậy, thay vì tạo một request 128k, gửi hai cái 64k chẳng hạn 14:10 <hobbs> duck: haha... thứ đó lan ra cả thế giới. 14:10 <@duck> tại sao bạn chặn 128k? 14:11 <cervantes> *rùng mình* europop 14:11 <laberhorst> duck: làm ơn im đi KHÔNG thì tôi bắn hạ bạn! 14:11 <tracker> Đôi khi tôi hối hận vì đã học tiếng Đức vài năm trước... 14:11 <laberhorst> không europop, thật sự không phải POP 14:11 * cervantes ra lệnh Vương quốc Anh đẩy lùi biên cương trước khi một bài như thế vào bảng xếp hạng 14:11 <laberhorst> tracker: đừng bận tâm, ổn mà 14:12 <ant> <duck> giờ là (2^17)-13 14:12 <ant> <Nolar> duck: giới hạn đó đã có một thời gian, nhưng một lý do hay là các khối 128K mất thời gian để upload..... 16KB (mặc định của chúng tôi) cho phép điều khiển request mịn hơn 14:12 <ant> <duck> 13 bytes là độ dài lệnh bittorrent 14:12 <ant> <duck> sẽ không vấn đề với (2^16)-13 14:12 <laberhorst> một số nhạc thực sự nực cười, nhưng nhạc industrial thực thụ thì, boh, không 14:13 <ant> <duck> hay quay về mặc định? 14:13 <jrandom> giảm xuống 64KB có vẻ đơn giản nhất (đó có phải là tham số CLI lúc này không?) 14:13 <ant> <duck> --download_slice_size 14:14 <ant> <Nolar> câu hỏi của tôi là, bạn có lý do thuyết phục để giữ khối 128K không, trông hơi lớn, đặc biệt với I2P 14:14 <ant> <Nolar> thay vì chỉ pipeline nhiều request nhỏ hơn? 14:14 <ant> <duck> Tôi không có lý do. 14:14 <tracker> laberhorst: Thỉnh thoảng tôi bắt được vài kênh Đức qua vệ tinh. Đặc biệt viva và cái "Theater Kanal" thực sự khủng khiếp... 14:15 <ant> <Nolar> một vấn đề với khối lớn là khi tôi choke bạn, tôi vẫn phải gửi nốt chunk 128k đó 14:15 <jrandom> Tôi không nhớ bản BT nguyên thủy có biết pipeline không, nhưng chắc khá đơn giản (đặc biệt vì tôi không phải người làm ;) 14:15 <ant> <Nolar> mất kha khá thời gian 14:15 <laberhorst> tracker: viva chỉ thú vị vào giờ "hard rock", còn lúc khác "xin đừng xem", còn theater, tôi không biết 14:15 <jrandom> với I2P, 128KB không thực sự lớn, vì có độ trễ cố hữu cỡ vài giây 14:15 <ant> <Nolar> có thể làm rối chunk/unchoke 14:16 <@duck> jrandom: còn hợp lý không nếu trừ 13 byte overhead của bittorrent để nó vừa trong một thông điệp SAM? 14:16 <jrandom> duck: không, vì lib streaming đã giảm xuống thành các thông điệp 16KB rồi, nên cứ để 64KB 14:17 <@duck> ok, vậy là 2**16 14:17 <jrandom> (và rồi các tunnels bẻ các thông điệp 16KB đó thành các mảnh 996 byte..) 14:17 <ant> <Nolar> vấn đề với 128k là nếu tôi upload khoảng 12 k/s, thì sẽ mất hơn 10 giây để xong khối đó 14:18 <cervantes> wow gần bằng độ trễ trên IRC... 14:18 <jrandom> đó là 1-10 RTT (trong khi trên mạng thường, 10-500) 14:18 <+detonate> tôi đã sẵn sàng dùng khối 512K 14:18 <ant> <Nolar> bạn cũng có thể thử pipeline các khối 16KB 14:18 <jrandom> heh 14:18 <+detonate> vậy 64 được ưu tiên? 14:19 <ant> <Nolar> tất cả client BT theo tôi biết dùng khối 16KB 14:19 <ant> <duck> đã sửa trong CVS; 14:19 <jrandom> tuyệt, cảm ơn duck! (và Nolar!) 14:19 <ant> <duck> mong nó sẽ xuất hiện trong bản 0.1.8 cùng với một số tinh chỉnh SAM I2CP 14:19 <tracker> laberhorst: Tên đầy đủ là "ZDF Theater" hay gì đó. Và họ nói họ phát sóng chương trình văn hoá trình độ cao. Tôi thực sự hy vọng những gì họ phát không phải là tinh hoa văn hoá Đức ;) 14:19 <jrandom> ok, heh, tôi vừa nhớ ra là chúng ta vẫn đang trong cuộc họp 14:19 <jrandom> ai còn gì cho cuộc họp không? 14:20 <ant> <Nolar> vậy nếu muốn một chunk 128k, ta chỉ việc tạo 8 request đồng thời 14:20 <susi23> . o O ( và bỏ 448 byte còn lại? ) 14:20 <jrandom> đúng đúng 14:20 <laberhorst> tracker: ồ, đó là kênh phụ nhỏ... arte hoặc 3sat thì thú vị hơn nhiều 14:20 <laberhorst> và arte là Đức/Pháp :-) 14:20 <ant> <Nolar> nếu uploader có thể lấp đầy request như vậy, toàn bộ 128k nên được đẩy vào luồng pipe I2P 14:20 <jrandom> hay 14:21 <cervantes> . o O ( tự hỏi vì sao anh ấy nghe được mọi thứ susi đang nghĩ ) 14:21 <ant> <Nolar> vậy, có lẽ đáng để thử các kích thước khối 16KB so với 32KB so với 64KB 14:21 <jrandom> ừ 14:21 <jrandom> chừng nào đã pipeline, I2P không quan tâm 14:21 <ant> <Nolar> tuyệt 14:22 <jrandom> tốc độ ở 16KB mà không pipeline thì khá tệ, hoặc ít nhất trước đây là vậy 14:22 <tracker> laberhorst: Ok, tôi sẽ thử xem có bắt được arte vài ngày tới không... 14:22 <ant> <duck> tôi đề nghị để việc tinh chỉnh này cho 0.2 14:22 <ant> <duck> vì nó sẽ bao gồm các cải tiến bittorrent 3.9.1 14:22 <jrandom> ừ, DTSTTCPW 14:22 <susi23> . o O ( ồ cái đó dễ... con người quá dễ đoán... ) 14:23 <ant> <duck> có thể tái cấu trúc hoàn toàn code mạng 14:23 <cervantes> http://www.gavelstore.com 14:24 <jrandom> ok, tôi nghĩ vậy là đủ lúc này, mọi người nên kiểm tra mailing list và site trong vài giờ nữa vì bản 0.5.0.1 sắp ra 14:24 <ant> <Nolar> ừ, tôi hiểu vì sao các request 16KB đơn lẻ lại chậm 14:24 * jrandom tải về một cái búa quan tòa 14:24 * jrandom *baf* đóng cuộc họp