Họp các nhà phát triển I2P - 28 tháng 12 năm 2004

13:06 <@jrandom> 0) chào 13:06 <@jrandom> 1) 0.4.2.5 13:06 <@jrandom> 2) 0.5 13:06 <@jrandom> 3) ??? 13:06 <@jrandom> 0) chào 13:06 * jrandom vẫy tay 13:06 <+postman> *vẫy* 13:06 <ant> <jnymo> hello 13:06 <@jrandom> ghi chú trạng thái ngắn gọn đã đăng @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html 13:07 <@jrandom> nhảy vào 1) 0.4.2.5 13:07 <@jrandom> như đã nói, mọi thứ cơ bản hoạt động ổn 13:08 <+postman> ừ, khá ấn tượng 13:08 <+postman> không còn lease timeout trên hệ thống của tôi nữa 13:08 <@jrandom> nhiều người thấy như bạn thấy, jnymo, với 0 participating tunnels, phần lớn do hiệu quả tăng & chọn peer (giờ ta biết hút băng thông từ máy của postman ;) 13:08 <ant> <jnymo> tôi cũng vậy 13:08 <@jrandom> hay đấy 13:08 <ant> <jnymo> và eepsites phản hồi nhanh 13:09 <+postman> :) 13:09 <ant> <jnymo> cảm ơn postman :) 13:09 <+postman> tổng băng thông là 29kb / 30.1kb/s 13:09 <frosk> ai cũng thấy ít được 'yêu' hơn, nhưng thực ra tình yêu chỉ đang được dùng hiệu quả hơn thôi 13:10 <ant> <jnymo> wow 13:10 <@jrandom> đỉnh đấy, postman 13:10 <mule2> tôi không nghĩ đó là lý tưởng. tốt hơn nên có một ít lưu lượng qua tất cả các nút 13:10 <ant> <jnymo> tôi chịu được nếu mọi người chỉ cần yêu tôi :( 13:10 <+postman> ừ 13:10 <mule2> như một dạng cover traffic (lưu lượng che phủ) 13:10 <@jrandom> mule2: vấn đề là tải hiện tại nhỏ hơn nhiều so với năng lực mạng 13:11 <@jrandom> tôi không nghĩ ta giữ được tình trạng năng lực lớn hơn tải lâu đâu 13:11 <ant> <jnymo> mule2, postman cũng hoạt động như một mixer.. nên khó biết gói của bạn đi đâu sau khi vào 13:11 <@jrandom> nên tôi không quá lo việc không đẩy dữ liệu qua các peer chậm 13:12 <mule2> có lẽ tối ưu hóa ít hoàn hảo hơn sẽ tốt cho ẩn danh 13:12 <@jrandom> mặt khác, nó cũng tạo động lực để nhiều người (triển khai &) dùng i2pcontent, để họ có thể mirror và nhận cover traffic ;) 13:12 <jdot__> có phải vấn đề bảo mật nếu một router xử lý hầu hết (gần như tất cả) các tunnel không? 13:13 <@jrandom> mule2: hãy làm nó tốt nhất có thể trước đã, rồi hãy bàn chuyện chủ động làm nó kém đi 13:13 <@jrandom> jdot__: chúng ta không có một router xử lý toàn bộ lưu lượng, nhưng thấy nhóm các router trên kết nối rất nhanh (colo, v.v.) xử lý nhiều hơn người dùng dialup/dsl/cable 13:14 <@jrandom> thêm nữa, tỷ lệ hỏng tunnel giảm nghĩa là ta chuyển đổi & thăm dò ít hơn 13:14 <mule2> có lẽ có thể phân phối lưu lượng, miễn là còn xa giới hạn router 13:14 <@jrandom> đúng, cơ chế từ chối tunnel theo xác suất có trong router và có thể bật theo giới hạn băng thông của router 13:15 <ant> <jnymo> ừ, nhưng thông lượng cao như vậy trên nút của postman làm cho việc phân tích nút của anh ấy khó hơn.. nên có thể gửi qua anh ấy an toàn hơn là mọi nút đều chỉ làm 1 KB/s.. 13:15 <@jrandom> (nhưng nếu postman không đặt giới hạn, ta không thể từ chối dựa trên % của cái đó ;) 13:15 <ant> <jnymo> những nhóm nút nhanh hơn tạo thành cấu trúc kiểu mix cascade, đúng không? 13:15 <@jrandom> ừ, đó là một cách nhìn 13:15 <lektriK> tôi có thể đóng cửa sổ Start I2P không? 13:15 * postman rất xin lỗi vì KHÔNG giới hạn băng thông của mình 13:16 <@jrandom> lektriK: tiếc là không hẳn, trừ khi bạn chạy i2p như một service (Xem http://localhost:7657/configservice.jsp) 13:16 <@jrandom> heh postman đừng lo, chúng tôi sẽ tự giảm tải khỏi router của bạn nếu/khi đạt tới công suất của router 13:17 <lektriK> Ok, nó báo service đã khởi động 13:17 <lektriK> giờ tôi có thể đóng nó chưa? 13:17 <@jrandom> lektriK: không/có - bạn có thể tắt router rồi khởi động lại qua start->run->"net start i2p" 13:18 <mule2> hiện tại, một vài router rất lớn có thể xử lý tất cả các tunnel, loại bỏ toàn bộ cover traffic khỏi các router khác. nhưng hãy nói tiếp sau cuộc họp. 13:18 <mule2> không muốn phàn nàn khi mạng hoạt động quá tốt :) 13:18 <@jrandom> hehe 13:20 <@jrandom> sẽ có một số khám phá thêm với 0.5, dù có các vấn đề liên quan đến ẩn danh nếu mở rộng quá xa. sẽ có thêm chi tiết cần xử lý cho 0.5 (và trong tài liệu có thể sẵn sàng tuần tới dưới dạng bản nháp đầu tiên) 13:21 <@jrandom> dù sao, còn ai có gì muốn nêu cho 0.4.2.5 không? 13:21 <@jrandom> hay chúng ta chuyển nhanh sang 2) 0.5? 13:21 <+postman> chuyển 13:21 <ant> <jnymo> rất ổn định... chuyển 13:21 <@jrandom> coi như đã chuyển 13:22 <@jrandom> 2) 0.5 13:22 <@jrandom> ừ. vẫn đang làm. sẽ có thêm thông tin khi sẵn sàng. 13:22 <ant> <Quadn-werk> Ngài Arthur C. Clarke vẫn sống :P 13:22 <ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1 13:22 <ant> <jnymo> .5 thú vị đấy 13:22 <@jrandom> ok, đó là tất cả tôi muốn nói về việc đó - ai có câu hỏi / điều gì cần bàn về nó không? 13:23 <@jrandom> ừ, chắc chắn có một số cải tổ quan trọng dựa trên những gì chúng ta học được 16 tháng qua 13:23 <@jrandom> (ờ quên, 18) 13:23 <+postman> jrandom: vậy 0.5 sẽ chủ yếu dùng hệ thống quản lý tunnel mới? 13:23 <ant> <Quadn-werk> arg, hy vọng tôi không làm gián đoạn cuộc họp :/ 13:23 <+postman> wow 13:23 <ant> <Quadn-werk> xin lỗi heh 13:23 <ant> <jnymo> heh. tôi có đề xuất 13:24 <@jrandom> đúng rồi postman, quản lý mới, pooling và xây dựng 13:24 <+postman> quadn: nhìn kìa - đoạn paste của bạn gây netsplit :) 13:24 <@jrandom> đồ khốn! 13:24 <ant> <Quadn-werk> ! 13:24 <@jrandom> có chuyện gì thế, jnymo? 13:24 <+postman> jrandom: mỗi tunnel vẫn sẽ là một local destination riêng chứ? 13:25 <@jrandom> hả gì cơ? 13:25 <@jrandom> sẽ không có thay đổi nào với i2ptunnel trong 0.5 13:25 <+postman> jrandom: ok 13:25 <@jrandom> (ít nhất, tôi không định thay đổi gì) 13:26 <mule> postman đang tiến hành intersection attack? 13:26 <ant> <jnymo> cho những ai không thấy dùng băng thông /chút nào/.. thế cho router tự xây tunnel có họ ở trong đó thì sao.. như ABCABCA 13:26 <+postman> mule: không, là lỗi của quadn :) 13:26 <ant> <jnymo> và đó sẽ là một dummy tunnel 13:27 <@jrandom> jnymo: quảng bá một router kiểu “này tôi dư băng thông, dùng tôi đi” là trò nguy hiểm 13:27 <+postman> jrandom: vậy những vấn đề nào sẽ được giải quyết bởi thiết kế lại (tóm tắt) 13:27 <ant> <jnymo> không chắc tôi có ý đó, jrandom 13:27 <@jrandom> nhưng hiện giờ có vẻ ta sẽ có hai bộ tunnel - cái bình thường, và cái thăm dò, trong đó loại sau được xây từ các peer ngẫu nhiên không bị lỗi 13:28 <ant> <jnymo> jrandom: ý tôi là tạo một dummy tunnel, và đặt chính mình ở giữa tunnel đó chỉ để mô phỏng một ít lưu lượng 13:29 <@jrandom> postman: làm cho việc liên hệ các peer trong một tunnel khó hơn nhiều, cho phép client chọn hiệu quả độ dài outbound tunnel của họ, và cung cấp các tùy chọn cần thiết để đối phó predecessor attack (với nhiều đánh đổi) 13:29 <@jrandom> (à, và cải thiện hiệu năng bằng cách bỏ đi nhiều lời gọi modPow) 13:29 <+postman> ok cảm ơn 13:29 <ant> <jnymo> postman: và per-hop tunnel IDs là một điểm lớn 13:30 <+postman> modPow? 13:30 <@jrandom> à jnymo. ừ, có nhiều tiềm năng để tạo đủ kiểu chaff traffic 13:30 <ant> <jnymo> như vậy, không có hai nút không liền kề nào biết họ ở cùng một tunnel, postman 13:30 <@jrandom> postman: lũy thừa mô-đun, ngốn CPU nặng & lãng phí bộ nhớ 13:31 <ant> <jnymo> jrandom: k cool 13:31 <+postman> k 13:31 <scintilla> jrandom, liên quan đến việc cho client chọn độ dài tunnel: có gì để ngăn người ta vặn nó lên 99 (hay gì đó) không? 13:31 <ant> <jnymo> sức mạnh CPU 13:32 <@jrandom> khi cần ta có thể thêm hashcash, nhưng các tunnel quá dài rồi cũng sẽ thất bại thôi 13:32 <scintilla> à đúng 13:32 <@jrandom> chúng ta thậm chí có thể thêm chút mánh — yêu cầu một tunnel phải có thông điệp tunnel hợp lệ được bơm qua trong vòng 60s kể từ khi tạo thì mới 'hợp lệ' 13:33 <@jrandom> (nên nếu tunnel dài 20 hop, họ sẽ mất quá lâu để xây hết các hop đó) 13:33 <scintilla> ý tưởng hay — như vậy mấy trò lố đó sẽ không kéo dài được lâu 13:33 <@jrandom> nhưng đó là đối phó hacker thôi. người dùng bình thường sẽ dùng giao diện được cung cấp 13:34 <ant> <jnymo> đúng, và bạn sẽ đặt một giới hạn nào đó, đúng chứ? 13:34 <ant> <jnymo> chúng ta sẽ có mức cao hơn tối đa 2 như hiện tại, đúng không? 13:34 <@jrandom> đúng, như menu thả xuống số hop trên /configclients.jsp hoặc /i2ptunnel/edit.jsp 13:35 <@jrandom> ồ tôi tưởng tối đa là 3 rồi? ok, nhưng đúng, sẽ có mức cao hơn 2 13:35 <ant> <jnymo> 3 tunnel, 2 hop 13:35 <@jrandom> à, ok 13:35 <@jrandom> đúng, 0.5 sẽ thêm vài tinh chỉnh quan trọng, như có ngẫu nhiên hóa các độ dài đó không, và ngẫu nhiên hóa bao nhiêu, v.v. 13:36 <frosk> tối đa quả thật là 3 13:36 <ant> <jnymo> hmm 13:37 <@jrandom> à, là 3 trên /configclients 2 trên i2ptunnel 13:37 <frosk> 0.5 vẫn đúng tiến độ cho tháng Một chứ? 13:37 <ant> <jnymo> à 13:37 <@jrandom> ừ frosk 13:37 <frosk> tuyệt 13:37 <@jrandom> tôi sẽ không chần chừ quá lâu với streaming lib, hứa ;) 13:37 <frosk> nghe như nhiều việc quá :) 13:38 <@jrandom> thực ra không tệ lắm, phần khó là làm thuật toán cho đúng 13:38 <@jrandom> (chi tiết với chả chi tiết ;) 13:39 <+postman> frosk: và tất cả đã trên giấy rồi 13:39 <+postman> :) 13:39 <ant> <jnymo> heh 13:39 <frosk> đúng :) 13:39 <@jrandom> phần lớn là vậy ;) 13:39 <@jrandom> ok, ai còn gì khác cho 2) 0.5 không? 13:39 <ant> <jnymo> không có gì 13:39 <frosk> el zilcho 13:40 <@jrandom> 'k, chuyển sang 3) ??? kiểu cũ 13:40 <@jrandom> chào 13:40 <@jrandom> ai còn điều gì muốn nêu không? 13:41 <ant> <jnymo> postman: không có inproxy SMTP/POP3 trên i2pmail.org, đúng không? 13:41 <cat-a-puss> Tôi vẫn thấy độ trễ lạ ở phía client... 13:41 <+postman> ờ không 13:41 <frosk> đoạn này lẽ ra tôi đưa chai rượu chúc mừng cho một năm phát triển tuyệt vời ;) 13:41 <+postman> jnymo: POP3 chỉ dành cho người dùng i2p 13:41 <@jrandom> cat-a-puss: à lúc nãy bạn ở đây tôi lỡ bỏ qua những tin đó 13:41 <+postman> jnymo: CÓ một SMTP inproxy làm MX cho miền i2pmail.org 13:42 <@jrandom> frosk: cạn ly 13:42 <ant> <jnymo> đúng đúng.. hay đấy.. 13:42 <cat-a-puss> Ví dụ tôi có hai local Destinations (Destination: đích trong I2P) và khi một cái cố kết nối đến cái kia thì có độ trễ và không bị giới hạn bởi CPU 13:42 <mule> cat-a-puss: bạn cũng đưa séc thưởng chứ? 13:42 * postman tặng một chai whiskey ngon 13:42 <@jrandom> cat-a-puss: đúng, bạn thấy độ trễ 0.5–1.0s đúng không? 13:42 <cat-a-puss> mule: gì cơ? 13:42 <cat-a-puss> jrandom: ừ 13:43 <@jrandom> cat-a-puss: hoàn toàn bình thường, là một phần của deferred SYN 13:43 <mule> xin lỗi, bình luận đó là của frosk 13:43 <ant> * jnymo lôi ra hộp rượu dở tệ 13:43 <mule> frosk: bạn cũng đưa séc thưởng chứ? 13:43 <@jrandom> (nó đợi một chút để gửi SYN và ACK liên quan phòng khi có thêm dữ liệu để gộp) 13:43 <scintilla> à FYI, tôi sắp nhận được cuốn sách có đặc tả thuật toán Fortuna... trong lúc đó tôi đang thử thu thập entropy trong Java mà không phá hỏng máy 13:44 <@jrandom> à, tuyệt vời 13:44 <ant> <jnymo> mmm, có người muốn tiến hành vài cuộc tấn công lên i2p 13:44 <ant> <jnymo> ai vậy? 13:44 <@jrandom> connelly 13:44 <cat-a-puss> Có cách nào ngăn điều đó, hay tôi chỉ cần cố tránh các kết nối sống ngắn khi có thể? 13:45 <ant> <jnymo> có tin gì về việc đó không, jr? 13:45 <@jrandom> cat-a-puss: có, có vài tùy chọn bạn có thể truyền khi tạo I2PSocketManager, để tôi lôi chúng lên 13:46 <@jrandom> jnymo: đó là intersection attack dài hạn, nên sau một thời gian anh ta sẽ có dữ liệu giúp xác định một số eepsite chạy trên router nào. tôi chắc anh ấy sẽ viết tóm tắt cho chúng ta khi có 13:46 <ant> <jnymo> scintalla: thuật toán Fortuna là gì? 13:46 <ant> <jnymo> jrandom: được rồi 13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100 13:48 <scintilla> đó là bộ sinh số giả ngẫu nhiên an toàn mật mã... thứ tuyệt đối thiết yếu cho mã hóa đáng tin cậy 13:48 <jdot__> đã có ai tình nguyện cho cuộc tấn công đó chưa? 13:48 <@jrandom> cat-a-puss: rồi nhớ flush() sau khi write() vào I2PSocket 13:48 <@jrandom> jdot__: ừ, anh ấy có 7 site tình nguyện 13:48 <cat-a-puss> jrandom: ok 13:49 <ant> <jnymo> liên quan đến cuộc tranh luận lớn về đặt tên.. 13:49 <ant> * jnymo cười khúc khích 13:49 <@jrandom> oh và i2p.streaming.initialAckDelay=1000 13:49 <@jrandom> hoặc thậm chí =100 13:49 * jrandom ném bùn vào jnymo 13:50 <ant> <jnymo> thực ra tôi có làm với x500 và công việc cho phép tôi có winSevers miễn phí 13:50 <ant> <jnymo> vậy có lẽ tôi sẽ dựng một DNS trung tâm cho mục đích thử nghiệm trong một hai tháng nữa 13:51 <@jrandom> heh, có một máy chủ đặt tên tập trung chạy trên .mil thì buồn cười chết đi được 13:51 <ant> <jnymo> dù nhét địa chỉ i2p vào winserver có thể không đơn giản.. không chắc 13:51 <ant> <jnymo> heh... dnsalias là chìa khóa 13:52 <@jrandom> nano đã làm vài thứ rất hay, tích hợp dnsjava với i2p 13:52 <ant> <jnymo> ooooh 13:53 <@jrandom> xem nano.i2p để biết thêm chi tiết 13:53 <ant> <jnymo> mà chẳng ai định nói với tôi.. à, cảm ơn 13:53 <@jrandom> nhưng như đã nói lần trước, mọi người nên đăng ý tưởng và suy nghĩ về đặt tên lên wiki 13:54 <@jrandom> ok, còn ai có gì muốn nêu cho cuộc họp không? 13:55 <ant> <jnymo> không 13:57 <@jrandom> ok vậy thì 13:57 * jrandom chuẩn bị 13:57 * jrandom *baf* tuyên bố kết thúc cuộc họp