Cuộc họp nhà phát triển I2P - 18 tháng 5, 2004

14:07 <jrandom> 0) chào 14:07 <jrandom> 1) tình trạng testnet 14:07 <jrandom> 2) SAM 14:07 <jrandom> 3) cập nhật roadmap 14:07 <jrandom> 4) MyI2P 14:07 <jrandom> 5) ??? 14:07 <jrandom> 0) chào 14:07 * jrandom vẫy tay 14:08 <Nightblade> chào 14:08 * jteitel vẫy tay đáp lại 14:08 <jar> chào 14:08 <duck> chào 14:08 <Masterboy> :P 14:08 <jrandom> ghi chú trạng thái hàng tuần đã đăng tới http://dev.i2p.net/pipermail/i2p/2004-May/000239.html 14:09 <jrandom> xin lỗi nếu hôm nay tôi hơi lơ ngơ, lịch ngủ còn lộn xộn hơn thường lệ 14:09 <jrandom> dù sao, chuyển sang 1) tình trạng testnet 14:10 <duck> việc đa dạng hóa sẽ tự diễn ra với một mạng lớn hơn, phải không? 14:10 <jrandom> đúng, và/hoặc các ngưỡng chọn peer (nút ngang hàng) ít lệch hơn 14:11 <jrandom> ví dụ, nếu ngưỡng tốc độ là trung vị thay vì trung bình, chúng ta sẽ có số peer nhanh bằng một nửa số peer đáng tin cậy 14:11 <jrandom> trái với tình hình hiện nay nơi tốc độ bị lệch mạnh 14:12 <Masterboy> ừ thì mạng đã tự hồi phục, vậy cũng không tệ 14:12 <jrandom> đúng, nhưng mất lâu hơn mức đáng ra, và bộc lộ những cách có thể cải thiện 14:13 <jteitel> mạng đã hồi phục ư? Tôi vẫn không thể kết nối đến i2p irc ổn định 14:13 <jrandom> các hồ sơ peer không suy giảm đủ nhanh, hoặc không thăng hạng ứng viên mới hiệu quả 14:14 <jrandom> nó cũng kích hoạt một chuỗi sự kiện thứ cấp - quá tải các router không đủ khả năng chịu tải (do profiling chưa đủ), khiến một số router quá tải cạn bộ nhớ và tắt 14:15 <human> ayeee ayeee ayeee! 14:15 <jrandom> đó là một quá trình tiến triển, jteitel - một số vấn đề chúng ta thấy liên quan đến sự cố netDb 14:15 <jrandom> chào human 14:15 <jteitel> Ồ, OK 14:16 <_cervantes_> một router gặp trục trặc không thể chuyển bớt tunnels sang một peer khác à? 14:16 <ugha_node> Wow, Tốc độ suốt đời: 8.87KBps gửi 8.35KBps nhận. 14:16 <Nightblade> jteitel: Tôi vừa kết nối được sau vài lần thử... vẫn đang đợi lệnh /join thực thi 14:16 * BrianR nhìn quanh. 14:16 <jrandom> không - một router đơn giản có thể bỏ một tunnel (nếu lẽ ra không nên nhận ngay từ đầu) 14:16 <ugha_node> (Và tôi đã khởi động lại router nửa giờ trước) 14:16 <BrianR> chết tiệt. Tôi muộn rồi. 14:17 <BrianR> jrandom: (Cảm ơn đã xếp myi2p về cuối chương trình nghị sự) 14:17 <jrandom> ugha> ừ, mọi người phải gánh phần của ba con nhanh đó 14:17 <jrandom> hehe :) 14:18 <duck> đó là một cuộc tấn công hay 14:18 <ugha_node> jrandom: Rõ ràng rồi. 14:18 <_cervantes_> vậy chẳng phải sẽ tốt hơn nếu cứng rắn hơn và từ chối tunnels ở ngưỡng thấp hơn sao 14:19 <jrandom> đúng đấy cervantes - hiện các router không bao giờ từ chối một tunnel trừ khi chúng không thể tới hop tiếp theo 14:19 <jrandom> chúng ta sẽ muốn đưa vào một cơ chế điều tiết nào đó, có thể dựa trên kích thước jobQueue / avg lag, v.v. 14:20 <jrandom> ngoài ra, chúng ta phải đảm bảo không cố xây quá nhiều tunnels cùng lúc, như đã xảy ra khi một phần lớn trong số đó thất bại 14:20 <_cervantes_> hoặc đơn giản cho phép người dùng đặt ngưỡng dựa trên phần cứng/bandwidth mà họ biết là mình có sẵn 14:20 <jrandom> (do các peer nhanh+đáng tin cậy bị offline) 14:20 <_cervantes_> ít nhất ở giai đoạn này 14:20 <jrandom> ồ đó là ý hay - cho phép mọi người đặt rõ ràng số lượng tối đa tunnels tham gia. 14:21 <jrandom> chúng ta sẽ đưa vào bản rev. tiếp theo. hay lắm. 14:21 <ugha_node> Nghe như logic mờ vậy. 14:21 <jrandom> chúng ta phải xử lý quá tải, và chỉ việc xếp hàng thông điệp trong bộ nhớ chắc chắn không hiệu quả 14:21 <duck> (chào fvw) 14:21 <_cervantes_> sẽ tốt nếu có một dạng thống kê tổng hợp về hiệu năng tunnel... kiểu tải có thể gây ra trên bộ xử lý dùng benchmark 14:22 <_cervantes_> nhân tiện tôi đã đưa server của mình offline.... nó nhận một đống tunnels và tôi vẫn chưa biên dịch jbigi ;-) 14:22 <jrandom> xem http://localhost:7655/routerStats.html#Tunnels 14:23 <jrandom> à! đúng, jbigi là thứ chúng tôi muốn khuyến khích mọi người sử dụng 14:23 <BrianR> Có ý kiến gì về việc phân bổ ngân sách băng thông cho các tunnels không? 14:24 <jrandom> hiện dự kiến cho 3.0 (với giới hạn băng thông tổng thể cho toàn bộ router @ 0.4.1) 14:24 <jrandom> nhưng có giới hạn băng thông theo từng tunnel sớm hơn cũng không hại gì 14:25 <fvw> Có khôn ngoan không khi bỏ công vào việc này quá sớm, trong khi dễ hơn nhiều và chính xác hơn nếu làm ở kernel của các HĐH mà đa số người dùng/người thử hiện tại đang chạy? 14:25 <_cervantes_> điều tôi muốn thấy là cài đặt độ sâu theo từng tunnel (có lẽ đã khả dụng rồi) 14:25 <_cervantes_> ví dụ tôi biết mình có thể tin máy chủ của mình.... nên tôi không muốn phải đi qua _x_ hops để đến đó 14:25 <jrandom> fvw> điểm hay, nhất là vì hiện chúng ta không ngốn quá nhiều băng thông 14:26 <jrandom> hmm cervantes - đúng, mỗi client có thể chỉ định độ dài tunnels của họ, nhưng tôi không chắc đó đúng là thứ bạn muốn 14:26 <_cervantes_> không 14:26 <jrandom> cervantes - tôi nghĩ thứ bạn muốn là QoS (chất lượng dịch vụ) nơi bạn có thể rút ngắn kết nối cho một peer cụ thể 14:26 <_cervantes_> ví dụ... 14:26 <_cervantes_> đúng rồi 14:27 <jrandom> (mà vốn được lên kế hoạch cho i2p 4.0, nhưng hơn một năm nữa == vô tận) 14:27 <_cervantes_> trong trường hợp này cũng chọn độ sâu theo từng i2p host 14:27 <BrianR> fvw: Đúng, nhưng một i2p cần biết đại khái các thành viên tiềm năng của tunnel có bao nhiêu băng thông sẵn có để đưa ra quyết định xây tunnel khôn ngoan... 14:27 <_cervantes_> à ok 14:27 <_cervantes_> :) 14:27 <jrandom> nhưng đó là ý tưởng hay và khả thi về mặt kỹ thuật, hoan nghênh các bản vá :) 14:28 <_cervantes_> bản vá đã trên đường qua thư.... kèm tấm séc 5000 thỏi e-gold 14:28 <_cervantes_> ;-) 14:28 <jrandom> BrianR: có lẽ có thể đi nửa chừng - theo dõi nó đang tham gia bao nhiêu tunnels, cũng như lượng băng thông các tunnels đó đang dùng, và dùng điều đó như một phần quyết định có chấp nhận hay từ chối một yêu cầu tạo tunnel? 14:28 <jrandom> hề 14:30 <jrandom> ok, có ai còn gì cho tình trạng testnet không? 14:30 <Masterboy> còn nghịch lý của tôi thì sao? 14:30 <Masterboy> :) 14:30 <jrandom> kế hoạch của tôi là ra 0.3.1.3 với các cập nhật vào thứ Năm hoặc thứ Sáu 14:31 <jrandom> Masterboy: tôi chưa có thời gian xem log của bạn, nhưng chúng ta sẽ giải quyết 14:31 <_cervantes_> thứ Sáu 2005? 14:31 <_cervantes_> hay đấy 14:31 <Masterboy> k 14:31 <jrandom> ok, chuyển sang 2) SAM 14:31 <Masterboy> giờ thì ta biết ai đang chạy router lỗi thời.. 14:32 * jrandom trao mic cho dev SAM.pm quả cảm của chúng ta 14:33 <jrandom> (là bạn đó BrianR :) 14:33 <BrianR> Đợi một chút.. :) 14:33 * duck hò reo 14:33 <jrandom> trong lúc đó, dm hay firerabbit có ở đây không? 14:33 -!- Irssi: #i2p: Tổng cộng 26 nick [0 ops, 0 halfops, 0 voices, 26 normal] 14:33 * jrandom kiểm tra /names, không. thôi vậy 14:33 <jrandom> (vậy là không có cập nhật thư viện sam .net/C#) 14:34 <duck> mấy thứ .py còn hiện hành không? 14:34 <duck> hay đã bị khai tử bởi các cải tiến SAM 14:34 <jrandom> không chắc 14:34 <BrianR> Ok. Tôi quay lại rồi. 14:34 <Nightblade> Thư viện C của tôi có vẻ hoạt động... tuy tôi chưa viết ứng dụng để dùng nó 14:34 <jrandom> tuyệt nightblade! 14:35 <Nightblade> Có ai ở đây từng lập trình GTK+/C trên Windows không? 14:35 <human> duck: client lib cần một thay đổi nhỏ để hỗ trợ versioning 14:35 <_cervantes_> "hello world"? 14:35 <human> duck: phần còn lại chắc hoạt động không vấn đề 14:35 * jrandom gợi ý một datagram như tftp làm bài test sam lý tưởng :) 14:35 <Nightblade> ừ, cái gì cũng được... GTK có chạy tốt trên windows không.....? 14:35 <jrandom> (hoặc thậm chí SAM streaming thay vì datagram hay raw) 14:36 <jrandom> hay đó BrianR - .pm và samcat tiến triển sao rồi? 14:36 <BrianR> Net::SAM đang ở CVS ở dạng phần lớn chưa chạy được. 14:36 <BrianR> Tôi hy vọng sẽ giũ sạch mọi lỗi và làm cho datagram và raw hoạt động trước cuối tuần. 14:37 <BrianR> Cần thêm chút việc để hoàn thiện OO đẹp cho streams. 14:37 <Nightblade> ờ đúng, tôi không đụng tới datagram hay raw... chỉ stream 14:37 <Nightblade> nhưng đó cũng là tất cả những gì tôi sẽ dùng 14:37 <fvw> human: Bạn đã cân nhắc wxWindows chưa? Nó khá hữu ích cho kiểu đó (dù tôi không nghĩ có target GTK cho Windows) 14:37 <jrandom> tuyệt BrianR 14:38 <BrianR> Vợ đang giục tôi đi ăn tối với cô ấy. Tôi có thể sẽ không kịp quay lại buổi thảo luận myi2p. Tôi đã đăng mô hình đe dọa (threat model) và mấy thứ fileserver ngớ ngẩn lên node 208 14:38 <human> fvw: có port GTK cho Windows (GIMP chạy trên Windows mà) 14:38 <jrandom> hay đó nightblade, tốt nhất là triển khai cái cần thiết trước 14:38 <human> fvw: s/client/port/ 14:38 <jrandom> heh 'k BrianR, cảm ơn 14:38 <fvw> human: Ý tôi là target gtk trên Windows cho wxWindows (mà tôi vừa gợi ý bạn dùng) 14:38 * fvw vẫy tay với BrianR. Chúc ngon miệng. 14:38 <human> fvw: à... tôi không rõ về vxWidgets (vxWindows' new name :-) 14:39 <human> fvw: nhưng là Nightblade nói về GTK+, không phải tôi :-) 14:40 <fvw> Ối, mắt tôi lệch rồi, bỏ qua tôi đi. 14:40 <Nightblade> Tôi không quen C++ bằng C 14:40 <Nightblade> theo như tôi biết, GTK là thư viện GUI C đa nền tảng duy nhất 14:40 <Nightblade> không phải tôi đặc biệt thích GTK 14:40 <fvw> không quan trọng lắm, wxWindows có thể tiếp cận dễ dàng từ C. 14:40 <Nightblade> hmm 14:40 <Nightblade> ừ có lẽ tôi cũng sẽ xem qua 14:40 <Nightblade> tôi biết C++ nhưng chưa viết chương trình lớn nào bằng nó 14:41 * fvw cũng không phải coder C++, nhưng tôi đã dựng một bộ xem giao dịch khá lớn cho một công ty vận tải bằng nó cách đây không lâu mà không gặp rắc rối. 14:42 <Nightblade> tôi chắc wxwindows có port Windows trưởng thành hơn 14:42 <Nightblade> so với gtk 14:42 <fvw> rất có thể, ừ. 14:43 <Nightblade> (ok tiếp tục họp) heh 14:43 <jrandom> :) 14:43 <jrandom> ok, nhảy sang 3) cập nhật roadmap 14:44 * jrandom đã lơ là cập nhật http://www.i2p.net/roadmap trong tháng vừa rồi 14:44 <jrandom> nhưng giờ đã cập nhật lại hiện tại 14:44 <jrandom> đáng tiếc rõ ràng chúng ta sẽ không ra 0.4 vào tuần tới 14:44 <duck> (1.1, 2.0, 3.0 cũng cập nhật chứ?) 14:45 <jrandom> vâng thưa 14:45 * Masterboy đã đọc và thích - không vội, chúng ta không cháy đâu.. 14:46 <duck> ai đó cũng nên cập nhật wikipedia/infoanarchy nữa :) 14:46 <jrandom> ồ, có lẽ tôi nên bỏ "SAM bridge and client libraries implemented and tested" khỏi 0.4 14:46 <jrandom> heh ừ, đó là lý do tôi !thwapped iA lúc trước khi họ chỉ copy trang wiki 14:46 <jrandom> (họ nên chỉ trỏ tới /roadmap, không nên nhân bản nội dung) 14:47 <Masterboy> SAM xong rồi à? 14:47 <jrandom> nó hoạt động được rồi, dù công việc trên các client library bổ sung vẫn đang tiếp diễn 14:47 <jrandom> s/are/is/ 14:48 <jrandom> ok, trừ khi còn câu hỏi/quan ngại nào về roadmap, chuyển sang 4) MyI2P 14:50 <jrandom> dù tôi đã ngừng tự làm myi2p, chúng tôi đã mở công việc này thành một bounty - http://www.i2p.net/node/view/216 14:50 <jrandom> một phần nghĩa là chúng ta cần làm rõ yêu cầu, và có một số tranh luận về những yêu cầu đó nên là gì 14:51 <Masterboy> tôi rủ bạn tôi tham gia, anh ấy bảo quá nhiều việc quá ít tiền;P ừ thì anh ấy là nhà tư bản;) 14:51 <Masterboy> tôi thì đề nghị code nó.. 14:52 <jrandom> luôn hoan nghênh viết code cho nó :) 14:53 <jrandom> câu hỏi kiến trúc còn bỏ ngỏ hiện nay là xử lý thế nào với những người không thể chạy i2p router / myi2p node mọi lúc 14:53 <Nightblade> chỉ cần có một i2p isp đáng tin 14:53 <jrandom> hai đề xuất là hoặc dùng nhà cung cấp dịch vụ lưu trữ, hoặc tách hệ thống ra để dùng một bộ lưu trữ nền phân tán 14:54 <_cervantes_> phương án sau là giải pháp lý tưởng dài hạn 14:54 <_cervantes_> *latter 14:54 <duck> (và là một bounty khác) 14:55 <_cervantes_> hoặc một dịch vụ proxy webcache... 14:55 <jrandom> đúng - nếu chúng ta đi theo nhà cung cấp dịch vụ lưu trữ (hoặc node chạy cục bộ), khi DHT (bảng băm phân tán)/v.v. sẵn có, chúng ta có thể đẩy ngày càng nhiều nội dung vào DHT 14:55 <jrandom> _cervantes_: đó về bản chất là bộ lưu trữ nền phân tán - các bộ đệm dữ liệu không đáng tin 14:57 <deer> * Masterboy tự hỏi bogobot ở đâu 14:57 <jrandom> phần khó là có được chức năng kiểm soát truy cập cần thiết - với các bộ đệm dữ liệu không đáng tin/bộ lưu trữ nền phân tán, ACL (danh sách kiểm soát truy cập) về cơ bản là mã hóa 14:57 <jrandom> nhưng một “kênh bên” cho thảo luận này đến từ ba điểm được một người ẩn danh nêu ra @ http://www.i2p.net/node/view/215#comment-105 14:57 <_cervantes_> và nội dung có ký 14:58 <jrandom> đúng, cả hai cách đều cần có nội dung ký 15:00 <_cervantes_> đây là chỗ mô hình của hypercubus có giá trị... nhưng tuyệt đối không phải giải pháp “nhanh” 15:00 <jrandom> từ các thảo luận trên irc tối qua, chúng tôi tập trung vào “mô hình đe dọa của livejournal” - những tấn công mà người dùng LJ quan tâm và những cái họ không 15:01 <wilde> ưu tiên hàng đầu, là làm được một MyI2P cơ bản trước 15:02 <jrandom> đúng, và để triển khai myi2p cơ bản, chúng ta phải biết kiến trúc triển khai 15:03 <jrandom> với mô hình đe dọa LJ cho người dùng không thể chạy node riêng, tôi không nghĩ chúng ta cần đi theo hướng bộ đệm dữ liệu không đáng tin 15:03 <jrandom> và tại sao ai đó dùng myi2p nếu họ chỉ cần mô hình đe dọa của lj? vì nó ẩn danh 15:04 <jrandom> chúng ta có thể tiếp tục theo đuổi một hệ thống lý tưởng hóa, nhưng có quy luật lợi ích giảm dần 15:04 -!- Irssi: #i2p: Tổng cộng 24 nick [0 ops, 0 halfops, 0 voices, 24 normal] 15:05 <jrandom> đó là lý do tôi thiên về giữ bounty theo hướng hiện tại - chúng ta có thể bổ sung các phương án khác sau, khi hệ thống cơ bản ra mắt 15:05 -!- duck_ giờ có tên là duck 15:06 <jrandom> dù sao, tôi nghĩ đó là tất cả cho 4) MyI2P, trừ khi ai có gì khác muốn nêu 15:06 <jrandom> nếu không, chuyển sang 5) ??? 15:07 <_cervantes_> hmm bạn cần một cái búa chủ tọa to :) 15:07 <jrandom> tôi quên đề cập eepsite mới của morph.i2p trong biên bản cuộc họp, và nickster.i2p giờ có public fproxy! 15:08 <jrandom> (và sungo.i2p đã bật webcam chạy rồi :) 15:08 <_cervantes_> heh... 15:08 <_cervantes_> i2pr0n 15:08 <jrandom> ai còn gì muốn nêu không? 15:10 <jrandom> nếu không, vậy là chúng ta chạm mốc 70 phút 15:10 <deer> <Masterboy> không 15:10 * jrandom tổng kết 15:10 * jrandom *baf* kết thúc cuộc họp