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

16:10 <jrandom> 0) chào 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet, I2P, and darknets (mạng tối/riêng tư) (ôi trời) 16:10 <jrandom> 3) Tấn công bootstrap tunnel 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) chào 16:10 * jrandom vẫy tay 16:10 <jrandom> ghi chú tình hình hàng tuần đã đăng tại http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 16:10 <dust> yay, chạy rồi. cảm ơn Gregor 16:10 <cervantes> chào 16:11 <+fox> <blx> heloa 16:11 <jrandom> ok, vào mục 1) 0.6.1.3 16:11 <jrandom> mọi người cập nhật khá nhanh, cảm ơn! 16:12 <jrandom> mọi thứ có vẻ ở trạng thái hợp lý, nhưng tôi không có gì nhiều ngoài những gì trong ghi chú tình hình 16:12 <jrandom> ai có câu hỏi/bình luận/lo ngại gì về 0.6.1.3 không? 16:13 <jrandom> nếu không, ta nhảy sang 2) Freenet, I2P, và darknets (ôi trời) 16:13 <cervantes> 609 peer đã biết! 16:14 <cervantes> (w00t) 16:14 <jrandom> ừ, mạng đã tăng trưởng 16:14 <+fox> <blx> oh my! 16:14 * cervantes đang mở kèo cá cược xem bao lâu đến mốc 1000 16:14 <jrandom> heh 16:14 <tethra> heheh 16:15 <tethra> chúng ta cược bằng tiền số chứ? ;) 16:15 <cervantes> nhưng nó cho thấy lõi I2P gần đây vững đến mức nào khi số người dùng tăng nhanh 16:16 <cervantes> thôi... jrandom đã vô tình quyên góp hết tiền bia năm nay rồi 16:16 <jrandom> hehe 16:16 <jrandom> ok, về mục 2), tôi không chắc còn gì để thêm (chắc chúng ta đã bàn nát rồi). ai có câu hỏi/bình luận/lo ngại gì không? 16:18 <cervantes> như anh nói, nếu không gì khác thì nó đã kích thích vài thảo luận bảo mật liên quan gián tiếp, tức 3) 16:18 <jrandom> nếu không, ta có thể đi nhanh đến 3) Tấn công bootstrap tunnel 16:18 <jrandom> ừ, đúng vậy 16:19 <jrandom> vấn đề Michael nêu ra định lượng hóa một quan điểm chung tôi vẫn có, nhưng thật tốt khi làm nó rõ ràng 16:20 <jrandom> sẽ có thêm thảo luận về kiểu tấn công mới hơn tối nay (khi tôi viết xong phản hồi), còn kiểu trước có vẻ không đáng lo 16:21 <jrandom> mọi người thấy hợp lý chứ, hay có câu hỏi hay lo ngại gì không? 16:22 <cervantes> heh... nghĩa là mọi người đều ổn với nó hoặc họ chẳng hiểu đầu đuôi vấn đề là gì 16:23 <cervantes> tôi xin vào nhóm “không biết thì sướng” 16:23 <jrandom> heh về cơ bản đó là một tấn công khi bọn xấu tình cờ là endpoint outbound của mọi tunnel bạn đã từng dựng 16:23 <jrandom> lúc bạn mới khởi động, “mọi tunnel bạn từng dựng” là con số rất nhỏ (vd. 0, 1, 2) 16:24 <jrandom> nhưng sau vài giây, con số đủ lớn để biến (c/n)^t thành một giá trị rất rất nhỏ 16:25 <tethra> (c/n)^t là... 16:25 <jrandom> (đây là một lý do vì sao chúng ta không khởi động i2cp listener - và vì thế, i2ptunnel/etc - cho đến một lúc sau khi khởi động) 16:25 <jrandom> c == # peer thông đồng (kẻ xấu), n == # peer trong mạng, t == # tunnel bạn đã dựng. 16:25 <cervantes> đúng... 16:25 <tethra> à 16:26 <jrandom> nên khi t tăng, xác suất tấn công thành công trở nên rất nhỏ 16:26 <cervantes> vậy để khả dĩ thì bạn phải bắt đầu dùng router cho tác vụ nhạy cảm trong vòng vài phút sau khi nó khởi động? 16:26 <jrandom> (hoặc, dù sao cũng nhỏ hơn xác suất chiếm hết mọi hop trong một tunnel) 16:26 <tethra> à, tôi hiểu 16:27 <jrandom> cervantes: ngay lập tức, trước khi tunnel thứ 3 được dựng 16:27 <jrandom> (giả sử bạn dùng tunnel 3 hop) 16:27 <cervantes> khá là khó xảy ra 16:28 <cervantes> xét theo tình huống sử dụng 16:28 <jrandom> chuẩn rồi. 16:28 <jrandom> và vì chúng ta dựng hơn 3 tunnel lúc khởi động trước khi cho client nào chạy, nên đây không chỉ là vấn đề xác suất 16:28 <jrandom> nhưng dù sao định lượng cuộc tấn công cũng tốt 16:29 <cervantes> có đáng để để router quay thêm chút để phòng mọi khả năng không? 16:30 <cervantes> hoặc quay mạnh hơn... 16:30 <jrandom> có thể. nếu bỏ qua thời gian thiết lập kết nối và cả việc chọn peer không ngẫu nhiên, thì khả năng gần như bằng 0 16:31 <tethra> vậy là đáng “woot!” chứ? 16:32 <jrandom> ừ, nhưng từ góc độ kỹ thuật, ta không nên bỏ qua các đặc điểm đó ;) 16:32 <jrandom> nên, với 0.6.2 ta có thể xem xét trong lúc làm lại phần chọn/sắp xếp peer cho tunnel, để đảm bảo nó hành xử hợp lý 16:34 <jrandom> ok, nếu không còn gì về 3), chuyển sang 4) I2Phex 16:34 <jrandom> sirup không có đây, và tôi chưa thấy striker trên irc - redzara, bạn ở đây chứ? 16:36 <+redzara> có 16:36 <+redzara> Lượt đầu gần xong: port bản mod của Sirup lên phex cvs mới nhất. 16:36 <jrandom> nice1! 16:36 <+redzara> tiếp: Lượt hai: diff từ code của Sirup sang code phex gốc dùng trong bản phát hành ban đầu, để chắc là tôi không quên gì :) 16:37 <+redzara> có thể hoàn tất cuối tuần này 16:37 <jrandom> tuyệt quá 16:37 <+redzara> Lượt ba: refactor lớp giao tiếp (comm layer) với GregorK 16:37 <+fox> <GregorK> hy vọng bạn biết trong Phex CVS mới nhất, code tải xuống chưa ổn định và file tải xuống không tương thích với các bản phát hành trước 16:38 <jrandom> đây là I2P, chúng ta quen với bất ổn rồi :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> Với lượt cuối, vì hiện tôi chưa liên lạc được với GregorK, nên sẽ khá khó :( 16:38 <jrandom> GregorK: anh khuyên tích hợp theo cách nào? 16:39 <+fox> <GregorK> à giờ bạn đã liên lạc được với tôi ;) 16:39 <jrandom> ờ 'k redzara, hai lượt đầu đã đủ lớn rồi :) 16:39 <+redzara> GregorK: chào anh 16:40 <+redzara> GregorK: Tôi đã đọc kỹ toàn bộ code 16:40 <+fox> <GregorK> tôi có ý tưởng về cách dựng một layer... tôi có thể chuẩn bị tốt nhất có thể rồi xem nó khớp đến đâu và cần đổi gì 16:40 <+fox> <GregorK> toàn bộ?? wow... 16:40 <+redzara> Gregork: đúng, tất cả!! 16:41 <cervantes> anh ấy còn biết cỡ đồ lót của anh nữa 16:41 <Rawn> :D 16:41 <+fox> <GregorK> hay quá... lần sau đi mua sắm tôi chỉ cần hỏi bạn... 16:43 <+fox> <GregorK> sẽ tốt nếu có ai đó từ đội i2phex tham gia đội phex nữa.. 16:43 <jrandom> redzara: vậy chúng ta có bản phát hành I2Phex 0.1.2 với kết quả lượt hai trước khi trộn hết vào plugin layer trong Phex chính không? hay làm một lần luôn? 16:43 <+redzara> Xin lỗi, nhưng tôi không hiểu/không nói/không đọc/không viết tiếng Anh đủ tốt để cười với điều bạn viết 16:43 <+fox> <GregorK> như vậy cũng giúp sửa các lỗi ở cả hai phía 16:44 <jrandom> GregorK: hy vọng ta sẽ tìm cách để phía I2P chỉ là một plugin mỏng trong Phex, đúng không? 16:44 <jrandom> hay anh nghĩ hai bên nên tách biệt? 16:44 <+redzara> jrandom: Tôi nghĩ ta có thể có Phex 2.6.4 chạy trên I2P, với tôi I2Phex là dừng 16:45 <jrandom> dừng? 16:45 <+fox> <GregorK> tôi không chắc có thể làm như vậy ngay từ đầu, nhưng tôi nghĩ phần chính có thể tách ra thành plugin. 16:45 <jrandom> hay đấy, chắc sẽ nhiều việc lắm 16:46 <jrandom> nhất là khi nhìn vào thứ như java.net.URL (có thể rò rỉ truy vấn DNS ngay khi khởi tạo, v.v.) 16:46 <+redzara> jrandom: dừng, kết thúc 16:46 <+Ragnarok> grr 16:47 <jrandom> ok đúng rồi redzara, khi ta chạy được Phex 2.6.4 trên I2P, tôi đồng ý, sẽ không còn nhiều lý do cần I2Phex 16:47 <+fox> <GregorK> đúng... tôi nghĩ Phex dùng lớp apache URI ở vài chỗ để lách vụ này.. nhưng chỉ khi cần 16:48 <jrandom> à đúng, tôi nhớ đã nghịch thư viện đó, có vẻ ổn 16:49 <jrandom> bọn tôi chắc chắn sẽ giúp audit chút về ẩn danh/bảo mật trước khi đẩy cho người dùng cuối qua i2p 16:49 <jrandom> (không có ý nói Phex có vấn đề, chỉ là ứng dụng nào cũng có vấn đề, và hy vọng ta có thể giúp xử lý) 16:50 <+fox> <GregorK> với vài thứ như dùng Socket và tương tự tôi có ý tưởng tích hợp mượt... nhưng chỗ khác như các tính năng dùng UDP... tôi chưa chắc cách tốt nhất 16:50 <+fox> <GregorK> ồ tôi chắc Phex có nhiều vấn đề. :) 16:50 <jrandom> à, socket sẽ dễ, nhưng có thể ta cần tắt vài thứ khác. udp dùng cho gì - truy vấn nhanh à? 16:51 <+fox> <GregorK> hiện chỉ bootstrap 16:51 <+fox> <GregorK> UDP Host Cache.. thay cho GWebCache 16:52 <jrandom> àhh, ok. 16:52 <+redzara> Vậy ta không cần nếu có GwebCache tử tế? 16:53 <+fox> <GregorK> đúng... nhưng GWebCache chuẩn cũng có vấn đề bảo mật... 16:53 <+redzara> GregorK: không phải trong I2P tôi nghĩ vậy 16:54 <jrandom> à, phần đó có thể vượt qua - I2PSocket có xác thực - bạn biết ‘destination’ của peer bên kia, nên họ không thể nói “Tôi là, ờ... whitehouse.gov.. đúng thế!” 16:54 <jrandom> nhưng bạn nói đúng, đó là thứ cần kiểm chứng 16:54 <+fox> <GregorK> cũng có truyền tường lửa-tới-tường lửa sẽ là chủ đề UDP ta muốn triển khai khi có tình nguyện viên :) 16:54 <jrandom> à, trong I2P không cần truyền tường lửa-tới-tường lửa - I2P phơi bày không gian địa chỉ end-to-end hoàn toàn mở :) 16:55 <jrandom> nhưng... ồ, đó là thứ có thể hữu ích 16:55 <jrandom> nếu người dùng Phex có “0 hop tunnels”, họ sẽ được vượt NAT/ truyền tường lửa-tới-tường lửa miễn phí với tốc độ khá ổn 16:55 <+fox> <GregorK> một cái nữa là broadcast truy vấn trong LAN... để chia sẻ nội dung dễ hơn trong mạng riêng 16:56 <jrandom> (0 hop tunnels cung cấp mức độ chối bỏ hợp lý (plausible deniability) mà không cần peer trung gian nào mang lưu lượng) 16:57 <jrandom> hmm, broadcast LAN thì hay, nhưng tôi không chắc i2p thực sự cần (vì biết peer ở đâu là rủi ro ẩn danh :), nên có lẽ nên tắt tính năng đó khi dùng plugin I2P? 16:58 <cervantes> *tắt theo mặc định 16:58 <+fox> <GregorK> ừ hiện chưa có.. nhưng trong trường hợp này người dùng thường biết nhau để dựng mạng riêng.. 16:58 <jrandom> ồ đúng cervantes 16:58 <jrandom> đúng đúng GregorK 16:59 <+fox> <GregorK> có thay đổi gì về giao diện người dùng không?? 17:00 <+bar> ờ, ta sẽ không cần cờ :) 17:00 <jrandom> ít nhất, khả năng có vài tùy chọn cấu hình liên quan đến I2P sẽ hữu ích. 17:01 <jrandom> tôi nghĩ sirup đã chuyển một số hiển thị sang dùng ‘destinations’ của I2P thay vì hiển thị IP + cổng, nên tôi nghĩ là ổn 17:01 <+redzara> Còn bitzyKhông phải lúc này, nhưng cờ và quốc gia là không dùng 17:01 <jrandom> bitzy? 17:01 <+redzara> xin lỗi, copy/paste nhầm :( 17:02 <+fox> <GregorK> bạn có thể cung cấp danh sách tùy chọn cấu hình và tính năng tùy chọn bạn cần không? 17:03 <jrandom> Chắc chắn ta sẽ gửi. một host+port mà I2P đang chạy và vài drop-down về tinh chỉnh hiệu năng/ẩn danh là đủ 17:03 <jrandom> ta sẽ gửi chi tiết 17:02 <cervantes> [x] Super transfer speed mode 17:02 <+fox> <GregorK> à bitzi dùng để định danh file.. đó có là vấn đề ẩn danh không? 17:03 <vulpine> <redzara> GregorK: Tôi đang chuẩn bị, nhưng cơ bản là không có thay đổi 17:03 <+fox> <GregorK> :) hỏi nhà mạng của bạn cervantes... 17:03 <redzara> GregorK: có thể, tôi đang làm 17:04 <cervantes> GregorK: heh dân UK.... không hy vọng ;-) 17:04 <+fox> <GregorK> nếu bạn truyền file giữa 2 Phex trên cùng PC.. truyền nhanh như chớp ;) 17:05 <cervantes> hay... tôi có nhiều phim hay có thể chia sẻ với chính mình :) 17:05 <cervantes> * gạch dòng đó khỏi biên bản họp * 17:06 <bar> jrandom đề cập trước rồi, nhưng đây lại là ý tưởng điên: 17:06 <+bar> hay tích hợp i2p vào Phex, để người dùng thông thường có 0-hop tunnels? 17:07 <+fox> <GregorK> tôi nghĩ hiển thị cờ và IP+cổng đến từ đối tượng HostAddress.. sẽ bị ẩn bởi layer mới.. nên bạn có thể hiển thị cái khác 17:07 <+bar> (để có plausible deniability và udp firewall hole punching (đục lỗ UDP qua tường lửa)) 17:08 <+fox> <GregorK> không chắc tôi thực sự hiểu ý đó ;) 17:08 <+bar> chắc tôi cũng vậy ;) 17:09 <jrandom> GregorK: về cơ bản nghĩa là người dùng Phex sẽ nói chuyện trực tiếp với nhau, nhưng có chối bỏ hợp lý, vì họ có thể nói chuyện gián tiếp 17:09 <+bar> jrandom, chắc anh hiểu ý tôi, anh nói rõ hơn được không? 17:09 <jrandom> họ cũng được NAT traversal của I2P miễn phí, cùng an toàn dữ liệu và chống bị ISP/v.v. nghe lén 17:09 <+redzara> GregorK: nên anh phải loại tất cả code liên quan host+port + IsLocalIP + Is PrivateIP + ... 17:10 <jrandom> mặt khác (MỘT mặt khác RẤT LỚN), nó sẽ không thể nói chuyện với client gnutella không chạy trên I2P 17:10 <jrandom> (dù cuối cùng, tất cả sẽ chạy ;) 17:10 <+fox> <GregorK> Tôi nghĩ bước đầu tiên - và bản thân nó đã đủ lớn - là đưa i2p và phex xích lại gần. 17:10 <jrandom> đồng ý 17:10 <+bar> (chết tiệt, tôi không nghĩ đến điều đó) 17:11 <+bar> ừ, chắc chắn. 17:11 <jrandom> đây là chuyện “ngựa bay”. hãy làm những thứ thực tế trước 17:11 <+fox> <GregorK> rồi sau khi xem nó hoạt động tốt đến đâu ta quyết định bước tiếp.. 17:11 <jrandom> chính xác 17:12 <+fox> <GregorK> redzara: Tôi muốn có hai implementation của HostAddress: một cho i2p và một như hiện tại. 17:14 <+redzara> Gregork: không vấn đề, tôi đã comment toàn bộ code trong bản mod, bạn có thể dễ dàng dựng hai implementation. Cho tôi hoàn tất phần việc ban đầu trước nhé 17:14 <+fox> <GregorK> chắc chắn.. không vấn đề.. 17:14 <jrandom> :) ok, vậy redzara, bạn nghĩ ta có thể có bản thử alpha dựa trên Phex-2.4.2 mới vào tuần tới không? 17:15 <jrandom> (cho phần lượt 2. lượt 3 của bạn sẽ tốn thêm công tích hợp vào dòng chính) 17:15 <+redzara> jrandom: next có vẻ ổn với tôi 17:16 <jrandom> ok tuyệt 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> ok, khá phấn khích đây, sẽ tuyệt nếu chạy trơn tru 17:17 <jrandom> ai còn gì nêu cho 4) I2Phex không, hay ta lướt qua 5) Syndie/Sucker? 17:17 <cervantes> I2P chắc chắn hưởng lợi từ những killer apps như vậy 17:18 <+fox> <GregorK> nhân tiện có mailing list CVS của Phex cho mọi thay đổi CVS trong Phex... nếu hữu ích 17:18 <jnymo> *ehem*.. quá hữu ích 17:18 <jrandom> ok hay lắm, cảm ơn GregorK 17:18 <jrandom> chắc chắn rồi cervantes 17:19 <jrandom> ok, về 5), tôi không thực sự có gì thêm ngoài những gì đã có 17:19 <jrandom> dust: bạn ở đây chứ? 17:19 <+redzara> GregorK: Cảm ơn nhưng xử lý một phiên bản đã đủ với tôi :) 17:19 <jrandom> hehe redzara 17:19 <dust> Dạo này tôi không có nhiều thời gian rảnh, nhưng nếu có tôi nghĩ sẽ thử xử lý vụ addresses.jsp này, thêm ‘RSS’ vào menu dropdown giao thức ở đó rồi xây một đường đi qua Updater, Sucker tới BlogManager. 17:20 <dust> trừ khi ai có ý tưởng hay hơn 17:20 <jrandom> quá đã 17:20 <jrandom> nghe hoàn hảo đấy. 17:21 <jrandom> nhưng, hmm, có thể cần thêm trường (cái “đăng vào blog nào” và “tiền tố tag gì”)... 17:21 <jrandom> có lẽ một form/bảng riêng sẽ hợp lý, nhưng cũng có thể không 17:22 <dust> ồ, tôi tưởng addresses.jsp là cho một blog duy nhất (vì phải đăng nhập mới vào đó?) 17:22 <jrandom> à, đúng, ý hay 17:23 <jrandom> phần updater hơi mù mờ, nhưng bạn nói đúng 17:23 <dust> (đến đó tính) 17:23 <jrandom> ừ 17:24 * jnymo nghĩ www.i2p.net có thể mở một kiểu ‘café bán đồ lưu niệm’ 17:24 <jnymo> với áo eyetoopie ghi “I am Jrandom” ;) 17:24 * mrflibble vẫn đang theo kịp “flamewar”, có vẻ xoáy thành một flamewar đúng nghĩa :) 17:24 <jrandom> heh jnymo 17:25 <jrandom> ừ, thread đó nhiều nội dung lắm 17:25 <jrandom> ok, có lẽ đưa ta đến 6) ??? 17:25 <jrandom> ai còn gì muốn nêu trong cuộc họp không? 17:25 <+bar> có, một ghi chú nhanh về vấn đề symmetric nat (NAT đối xứng) (mới đi dò xét chút): 17:25 <+nickless_head> jrandom: tôi biết sự thật! 17:25 <+fox> <blx> kaffe? 17:25 <mrflibble> ôi, xin lỗi jr 17:26 <jnymo> nhưng nghiêm túc.. hầu như dự án mã nguồn mở nào đủ lớn cũng có mục bán đồ lưu niệm riêng 17:26 <+nickless_head> jrandom: tôi có bằng chứng chắc chắn anh đã hack trang chủ last.fm! 17:26 <+nickless_head> (phần “bạn sẽ nhận được gì khi đăng ký” có ghi ‘a pony’) 17:26 <jrandom> jnymo: tôi nghĩ bạn đúng, ta nên xem xét hướng đó, cũng có thể là cách gây quỹ hay 17:27 <jnymo> jrandom: chính xác 17:27 * mrflibble sẽ mua áo phông 17:27 <+bar> quay lại symmetric nat, 17:27 <+bar> theo tôi, khác với những NAT đã hỗ trợ, không có mẹo kỳ diệu nào cả. cách duy nhất làm đúng là nghiên cứu và khảo sát từng hành vi của từng symmetric nat và dùng introducers (nút giới thiệu) để thăm dò. 17:28 <jrandom> blx: bản kaffe CVS mới nhất hỏng bét. gói crypto không có trong source, prng không khởi tạo được, và url handler không xử lý nổi file:// :( 17:28 <jnymo> Chắc bạn cũng không muốn mặc nó nơi công cộng cho đến khi i2p có vài nghìn người dùng ;) 17:28 <+bar> (tôi tin ví dụ Hamachi và Skype làm udp hole punching từ sau symmetric nats theo cách này) 17:28 <+nickless_head> jnymo: cốc thì tuyệt :) 17:28 <+bar> dựa trên những gì tôi đọc trên mạng, thuật toán dự đoán symmetric nat khá tệ. 17:28 <jrandom> hmm bar 17:28 <mrflibble> hehe, tôi sẽ không in nick của mình đâu. ồ, và tôi vẫn còn sống/chưa bị bắt dù tôi có áo IIP 17:28 <jrandom> ừ, tôi cũng đọc vậy 17:29 <+bar> tôi sẽ thử gom thêm tài liệu hay và liên quan về chủ đề này. 17:29 <+redzara> Câu hỏi nhỏ: tỉ lệ phần trăm byte truyền lại trung bình trong 0.6.1.3 là bao nhiêu? 17:29 <jrandom> cảm ơn bar 17:29 <+fox> <jme___> bar, các dự đoán họ có được có nhất quán không? 17:29 <+fox> <jme___> bar, để tôi nói lại :) 17:29 <+fox> <blx> jrandom, buồn khi nghe vậy 17:30 <jrandom> redzara: tiếc là tôi quên không đưa cái đó vào netDb. nhưng lúc này tôi thấy 2.6 và 3.8 17:30 <jrandom> blx: tôi cũng vậy :( 17:30 <+fox> <jme___> bar, khi bạn phân tích hành vi hộp nat và tìm công thức dự đoán. nó có luôn đúng với hộp nat đó không? hay lúc đúng lúc sai? 17:30 <jrandom> blx: tôi biết họ đang trộn với classpath, hy vọng khi xong sẽ ổn 17:30 <+fox> <blx> có lẽ tôi sẽ không tham dự được 17:30 <jrandom> blx: bạn yêu cầu riêng kaffe, hay chỉ cần OSS/DFSG? 17:31 <+fox> <blx> phần mềm tự do 17:31 <+fox> <blx> dfsg bạn có thể nói vậy 17:31 <jnymo> nếu một người dùng i2p muốn dùng máy chủ thuê cho i2p, thì có công ty dịch vụ lưu trữ nào thoáng và rẻ nên chọn? 17:31 <+bar> jme___: Hamachi được cho là trung gian thành công 97% các lần thử kết nối. tôi đoán có vài NAT tỏ ra gần như ngẫu nhiên khi gán cổng 17:32 <jrandom> ok, tôi chắc ta sẽ xoay được blx. kaffe từng chạy được, và ta không phụ thuộc vào thứ gì riêng của Sun 17:32 <jrandom> jnymo: tôi dùng sagonet.net, nhưng họ tăng giá từ 65/tháng lên 99/tháng (nhưng đường truyền nhanh với 1250GB/tháng) 17:32 <jrandom> tôi biết ở Đức có vài nhà rẻ nữa 17:33 <+fox> <jme___> bar, 97% thì tuyệt 17:33 <jrandom> redzara: bạn thấy tỉ lệ truyền lại là bao nhiêu? 17:33 <+bar> jme___: ừ, nên tôi đoán hầu hết symmetric nat đều dự đoán được 17:33 <+fox> <blx> jrandom, tôi thật sự quan tâm vụ này :) 17:33 <+fox> <jme___> bar, bạn sẽ làm gì? relay, udp hole punching, cnx reversal.. còn kỹ thuật nào khác không? 17:33 <jnymo> 99 có đắt trung bình không? 17:34 <+redzara> jrandom giữa 3;8 và 4.2 17:34 <jrandom> jme___: ta dùng UDP, không cần connection reversal :) 17:35 <+bar> jme___: tôi không chuyên, có thể tuần sau tôi sẽ có thêm thông tin (nhưng ngửi thấy mùi profiling + udp hole punching ;) 17:35 <jrandom> jnymo: với 1250GB thì không. tôi thấy 60-120USD/tháng cho 50-100GB/tháng 17:35 <jrandom> bar: có lẽ UPnP sẽ là cách tốt hơn? 17:35 <+fox> <jme___> jrandom, ngay cả với udp nó vẫn hữu ích :) 17:35 <+redzara> jrandom: nhưng chỉ một số node gây tác động lớn, có lẽ mấy node cũ 17:35 <+fox> <jme___> vulpine: ok 17:35 <jrandom> dù điều đó chỉ giúp những người có thể điều khiển NAT của họ 17:36 <+fox> <jme___> upnp nên được hỗ trợ nhưng không độc quyền so với các cách khác 17:36 <jrandom> ờ, ta đang làm mọi thứ hiện nay mà không cần UPnP 17:36 <+fox> <jme___> vì upnp không được tất cả nat hỗ trợ, còn xa mới vậy 17:36 <jrandom> đúng, ví dụ NAT của ISP 17:36 <+bar> jrandom: nếu không có vấn đề bảo mật với upnp, tôi đoán cũng không hại gì. dù Hamachi không dùng upnp 17:36 <+fox> <jme___> ở đây ‘must’ = để đạt kết nối tối đa 17:37 <+fox> <jme___> ok quay lại c++ của tôi :) 17:38 <jrandom> đúng jme___, dù nếu ta làm được hole punching cho symmetric ngoài cone/restrited, thì rất ổn 17:38 <jrandom> l8s jme___ 17:38 <jrandom> ừ, lý tưởng là nếu ta không cần nó 17:39 <jrandom> ok, ai còn gì muốn nêu trong cuộc họp không? 17:41 <jrandom> nếu không... 17:41 * jrandom lên dây cót 17:41 * jrandom *baf*s tuyên bố kết thúc cuộc họp