Cuộc họp các nhà phát triển I2P - 30 tháng 12, 2003

<jrandom> 0) chào <jrandom> 1) trạng thái router <jrandom> 2) i2ptunnel <jrandom> 3) IM <jrandom> 4) kế hoạch 0.3 <jrandom> 5) đồng bộ thời gian <jrandom> 6) ??? <jrandom> hello mihi, polo <polo> hello ! <mihi> chào jrandom <jrandom> 0) chào <jrandom> :) <rsk> chào <i2p> <duck> chào <jrandom> 1) trạng thái router <jrandom> 0.2.3.3 đã phát hành, và có vẻ hoạt động ổn <jrandom> dĩ nhiên vẫn còn nhiều việc phải làm <jrandom> nhưng đây sẽ là bản phát hành 0.2 cuối cùng <jrandom> 0.3 sẽ thêm peer profiling để cho phép router tránh các router tệ <jrandom> (và 0.3.1 là đại tu các transport) <jrandom> hola Ophite1 <Ophite1> Chào. <rsk> vậy 0.3 sẽ có thêm overhead? <jrandom> có và không <jrandom> sẽ có peer testing, nhưng tập trung hơn <rsk> chúng ta có thấy tăng tốc với chọn đường đi (path selection) không? <jrandom> có <jrandom> đã có các bộ tính toán 'liveliness', và sẽ bổ sung các bộ tính toán độ trễ (latency) và thông lượng (throughput) mới <jrandom> ngoài ra mọi người sẽ có thể tinh chỉnh ưu tiên riêng cho các peer cụ thể <jrandom> ví dụ, nếu bạn biết muốn ưu tiên peer X hơn peer Y, bạn sẽ có thể cho họ một điểm cộng trọng số ngẫu nhiên nào đó <mihi> sẽ có tắt an toàn (clean shutdown) chứ? *g* <jrandom> đó thực ra là câu hỏi hay, mihi <jrandom> i2p đang đến mức cần một giao diện quản trị. <jrandom> Job chạy lâu nhất đang kìm hãm hoạt động là GenerateStatusConsoleJob <jrandom> mà giờ có thể mất tới 4–6 giây <jrandom> (giữ chân mọi thứ khác) <jrandom> cần chuyển sang async và theo yêu cầu. <jrandom> nhưng tôi không muốn viết một web listener / v.v. <jrandom> có lẽ ngược lại - một servlet khởi động router và giao tiếp với nó <mihi> bạn không cần một web server đầy đủ. chỉ cần khi thấy GET, trả về dữ liệu của bạn. <jrandom> đúng <jrandom> đúng, những thứ đó cũng nên có trong 0.3. <mihi> và khi thấy thứ khác (như SHUTDOWN), làm theo ý bạn. tất nhiên chỉ từ localhost ;) <jrandom> ôi thôi mà <mihi> như vậy ai đó có thể làm một chương trình quản trị đẹp <jrandom> đúng <mihi> bạn có một số trigger bằng file đúng không? chúng có được tài liệu hóa ở đâu không? >>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] yêu cầu PING 1072820995 từ jrandom <jrandom> những cái đó ở IDN, không phải trong chính router <jrandom> nhưng đó có thể là hướng tốt <jrandom> đó là một hệ thống cực kỳ đơn giản <jrandom> ý hay, đi hướng đó thôi <jrandom> (và tôi có thể tái sử dụng đoạn mã đó :) <i2p> <duck> cái filestuff kỳ diệu này bắt đầu trông giống plan9 <jrandom> lol <mihi> nhưng file trigger cần polling <jrandom> đúng rồi mihi, đọc một thư mục mỗi 30 giây cũng không tệ lắm <mihi> nhưng một ServerSocket#accept thì rẻ hơn. <mihi> vì nó sẽ không tốn thời gian. (miễn là OS tốt) <mihi> ok, file trigger còn hơn không, đúng vậy. <jrandom> server socket sẽ cho phép quản trị từ xa <jrandom> (khi phù hợp) <jrandom> không biết nữa. <jrandom> cần bàn tiếp. <jrandom> (hoặc nếu ai đó muốn nhảy vào viết code... :) <mihi> và server socket cũng có thể cung cấp routerConsole. <jrandom> đúng <jrandom> ok, 2) i2ptunnel <jrandom> :) <jrandom> i2ptunnel vẫn rất ngon, và có vẻ chúng ta muốn thêm một API dựa trên socket để điều khiển nó <i2p> <anon> kế hoạch ic2cp2pc của aum tạm hoãn à? <jrandom> đúng, ci2cp đã chết yểu, được thay bằng API dựa trên socket để điều khiển I2PTunnel <jrandom> tôi nghĩ tôi có thể thêm cái API đó trong vài ngày tới, để anh ấy có thể bắt tay vào phần triển khai <mihi> chỉ cần dùng một socket, gọi in.readLine() và đưa dòng đó vào runCommand() ;) <rsk> API mang lại gì cho i2p? <jrandom> khá giống vậy mihi (ngoại trừ nó định dạng kết quả và gửi trả theo cách chuẩn hóa) <mihi> với một "logger" phù hợp để gửi trả commands. <mihi> s/commands/results/ <jrandom> rsk> nó cho phép nhà phát triển ứng dụng xây client và server socket chạy trên i2p mà không phải xử lý các nhu cầu mã hóa của I2CP <jrandom> đúng đúng <jrandom> i2ptunnel /đúng là/ có overhead trong trường hợp có nhiều i2ptunnel <jrandom> bất kể JVM <jrandom> các client i2ptunnel tạo một destination mới cho mỗi client liên hệ, và router sẽ hoạt động kém đi nhiều khi số lượng local destination tăng. <rsk> à <jrandom> điều này là do nhu cầu ẩn danh của mạng gắn với cách mã hóa của chúng ta hoạt động <jrandom> đối với các ứng dụng chỉ muốn mở một hoặc hai tunnel tới một peer, API mới này sẽ RẤT TUYỆT <jrandom> nhưng với các ứng dụng cần nói chuyện với nhiều peer khác, I2CP là con đường nên đi. <jrandom> (vì đó là một destination đơn, được multiplex bởi i2cp) <jrandom> tôi đoán theo một cách nào đó, đó là cân bằng TCP vs UDP xưa nay <jrandom> mihi> bạn có suy nghĩ hay ý tưởng nào cho tương lai của i2ptunnel không? <rsk> rsk> công việc IP over i2p, hay VPN đang tiến triển thế nào? <mihi> jrandom: ai đó viết một streaming API tốt, rồi để i2ptunnel dùng nó. <mihi> tương tự cho naming server. <mihi> có lẽ thêm một số sequence number nếu không ai làm những thứ trên. <mihi> điều đó sẽ đồng nghĩa với thay đổi không tương thích. <jrandom> thay đổi không tương thích không xấu, chúng ta vẫn đang đầu giai đoạn phát triển <jrandom> (nếu ta cũng có thể tăng kích cỡ ID lên hai hoặc bốn byte mỗi phía?) <mihi> dù sao streaming API sẽ là thay đổi không tương thích. và nếu i2p hoạt động, ta không cần sequence number. <jrandom> rsk> tạm hoãn, đến khi ai đó có thời gian theo đuổi? ≡ rsk/#i2p nghĩ rằng thay đổi không tương thích là loại tốt nhất <jrandom> đúng vậy mihi <mihi> ID hiện là 3 byte, vậy sao lại *tăng* lên 2 byte? <jrandom> mihi> thật ra, tôi muốn dần loại bỏ mode=GUARANTEED và hiện thực nó trong streaming API ≡ mihi/#i2p cũng vậy <jrandom> để i2p = IP, không phải TCP hay UDP <jrandom> chết tiệt ước gì tôi có thêm 14 giờ mỗi ngày. <mihi> chỉ 14 thôi à? ;) <jrandom> ;) <jrandom> các id 3 byte không phải được suy ra bởi cả hai phía của kết nối sao? hay tôi đang rối <mihi> mỗi phía có một ID 3 byte, tuy nhiên, chỉ cần gửi một cái tại một thời điểm. <jrandom> có lẽ tôi sẽ hiện thực streaming API, bỏ GUARANTEED, và thêm cái socket controller đó tiếp theo. <jrandom> à ok <mihi> xem /apps/i2p/i2ptunnel/java/src/protocol.txt <jrandom> đúng đúng <mihi> nhân tiện, ai để nhầm file *ở đó* vậy? ≡ jrandom đổ lỗi cho eco ;) <jrandom> đợi đã, không, bạn đặt chúng ở đó mà <jrandom> phải không? <jrandom> ồ khoan, không, tôi đã import chúng ≡ jrandom tự đổ lỗi mình ngốc. <jrandom> (la la la) <jrandom> chết tiệt. ok, ừ, làm streaming API và socket controller sẽ cho phép tôi nghiền ngẫm bản tuyên ngôn peer testing / profiling / selection <jrandom> tôi sẽ đăng cái đó trong vài ngày tới để lấy ý kiến <jrandom> (và như vậy tôi sẽ bớt dính vào router. variety++) <jrandom> mihi> còn gì về i2ptunnel nữa không? <mihi> không như tôi biết <jrandom> tuyệt <jrandom> (cảm ơn lần nữa vì dành thời gian góp ý mấy thứ này, tôi biết bạn bận với fiw và nhiều thứ khác) <jrandom> ok, thecrypto không có ở đây, nhưng anh ấy đang tiến bộ với ứng dụng IM. <jrandom> (đó là mục 3 của chương trình nghị sự) <jrandom> 4) kế hoạch 0.3 <jrandom> 0.3.0 ~= các phần peer profiling, và giờ cũng sẽ bao gồm streaming API và cái socket controller cho i2ptunnel <jrandom> nhưng, nếu bạn chưa đoán ra, nó sẽ không phát hành vào 1 tháng 1 <jrandom> 15 tháng 1 là khả năng xa. xem tình hình thế nào. <jrandom> 0.3.1 không phải một tháng làm việc đầy đủ, nên có thể không cần lùi. <jrandom> ngoài ra, lộ trình vẫn khá đúng hướng và phản ánh nơi chúng ta đang tiến tới <jrandom> 5) đồng bộ thời gian <jrandom> một FAQ mới được đăng tại http://wiki.invisiblenet.net/iip-wiki?I2PTiming <jrandom> mihi, bạn có đề xuất về tùy chọn thứ tư ở đó (xây dựng hệ thống timing trong-i2p của riêng chúng ta)? <jrandom> chào brawl <mihi> ừ. ∙φ∙ brawl giờ được biết là eco_ <eco_> chào mọi người <jrandom> ồ chào eco <mihi> chúng ta vừa thảo luận về streaming API / tunnel API <mihi> rồi chỉnh sửa getTimeMillis của riêng bạn để hiệu chỉnh điều đó. <Ophite1> mihi: Không, không nên. <jrandom> mihi> vậy nếu kẻ tấn công tạo 1000 node với thời gian sai, mọi người sẽ toi đời <jrandom> (vì giá trị trung bình sẽ lệch ngẫu nhiên) <mihi> nếu kẻ tấn công tạo 1000 node, ai cũng toi đời rồi...? <rsk> chẳng phải nó sẽ tự hiệu chỉnh sao? <Ophite1> mihi: OK, 3. <jrandom> không, chúng ta nên xử lý được chuyện đó mihi. <mihi> ok, vậy chỉ dùng giá trị trung bình nếu độ lệch chuẩn nhỏ hơn khoảng 1 giây. <rsk> nếu mọi người có cùng một thời gian thì bạn ổn, dù thời gian đó sai, đúng không? <jrandom> rsk> nếu cả 1000 node đồng bộ, nhưng nếu tất cả đều ngẫu nhiên thì sao <mihi> chỉ dùng những thời gian đủ gần nhau. nếu không, chọn 3 node mới. <jrandom> mihi> đúng, chúng ta có thể hiện thực NTP (về cơ bản làm như bạn nói, dùng một loạt giá trị trung bình ứng viên để dần tiến gần đến thời gian đúng <mihi> nhưng ta không cần bận tâm hết mọi thứ (như độ trễ ping), như NTP làm. <Ophite1> nếu không làm vậy, mihi, thời gian sẽ từ từ trôi lùi. ≡ mihi/#i2p nghĩ rằng như vậy còn hơn để người dùng tự đặt thời gian. <jrandom> vậy bất kỳ ai ngẫu nhiên chọn 3 node bị lệch đó sẽ bị đẩy vào mạng riêng của riêng họ? <jrandom> thế còn tùy chọn thứ ba - <jrandom> i2p có một thành phần kiểm tra với máy chủ NTP thật qua NTP hoặc SNTP <mihi> nếu bạn chỉ có các node lệch trong netDB của bạn, bạn cũng đang ở trên mạng riêng đó... <jrandom> thay vì tái phát minh cái bánh xe <Ophite1> mặc dù tôi phần nào thích phương án đó... <Ophite1> NTP không được ký, nó có thể bị tấn công MITM. <Ophite1> hoặc DNS cache poisoning nhắm vào, ví dụ, time.nist.gov <jrandom> đúng Ophite1, nhưng với 200.000+ máy chủ SNTP hoặc NTP, đó là một tập rất lớn để tấn công. <jrandom> chúng ta chắc chắn sẽ không đồng bộ từ time.nist.gov. <Ophite1> kết nối từ i2p đến máy chủ thời gian của NSA có thể khiến vài người nhíu mày, nhỉ? :) <jrandom> và nếu kẻ tấn công nhắm vào time.nist.gov, mọi người ở khắp nơi đều bị ảnh hưởng <jrandom> hehe <mihi> vậy thì kết hợp cả hai. hỏi một máy chủ ntp "thật" và hàng xóm của bạn. nếu cả hai nói giống nhau, thì ổn. <jrandom> vậy là còn /nhiều/ code hơn ;) <jrandom> nhưng đúng, hợp lý. <Ophite1> Thú vị đó. Vậy nếu chúng không trùng? <Ophite1> chọn máy chủ ntp khác? <jrandom> từ chối peer đó. <mihi> thử máy chủ ntp khác và một peer khác. <mihi> cho đến khi bạn có một kết quả trùng. rồi từ chối tất cả các peer trước đó. ≡ mihi/#i2p gõ chậm hơn jrandom :( <Ophite1> khớp trong một ngưỡng nhất định, ví dụ 1 giây? <jrandom> 1 giây là được. <jrandom> chấp nhận các peer lệch tới khoảng 30 giây (để xử lý lag) <Ophite1> 1 giây có ổn trên các kết nối RẤT NẶNG không? <jrandom> 1 giây để sync, 30 giây cho trao đổi. <Ophite1> tôi từng thấy độ trễ trên DSL lên đến 5 giây khi làm vài trò xấu với nó. <jrandom> với tcp hay udp? <Ophite1> nhưng vậy thì, trong trường hợp đó, máy đó có lẽ không phải thứ bạn muốn đồng bộ thời gian theo đâu ;) <jrandom> đúng <Ophite1> udp. <jrandom> hmm 'k <Ophite1> bạn sẽ nghĩ nó bị drop chứ :) <i2p> <duck> tôi nghĩ vấn đề hơn là cho người dùng biết rằng đang có vấn đề <jrandom> duck> đúng vậy. <i2p> <duck> chỉ sau khi lần mò log lớn họ mới thấy đồng hồ của họ lệch (nếu họ tìm ra) <Ophite1> Có thể. Đại loại vậy. <i2p> <duck> hoặc là port đã bị chiếm <jrandom> một giao diện quản trị sẽ rất hay. <i2p> <duck> thế giới tốt đẹp hơn khi mọi người dùng NTP kết nối tới máy chủ stantrum (sp) 2 cục bộ của họ CTCP Cloaking hiện [Bật] <jrandom> có lẽ chúng ta sẽ có bản 0.4 với một mớ dọn dẹp và các thứ cho người dùng cuối, trước khi lên 1.0? <jrandom> đúng (stratum) <i2p> <duck> chỉ các client Windows là không có khả năng có cái đó <i2p> <duck> nhưng họ cũng không có khả năng ổn định <jrandom> Windows có NTP <i2p> <duck> vậy ai quan tâm <Ophite1> duck: Windows XP và Windows Server 2003 có NTP. <jrandom> dễ hơn với Unix rất nhiều <Ophite1> mặc định sync tới time.windows.com nếu tôi nhớ đúng. <jrandom> có danh sách thả xuống cho các lựa chọn khác <Ophite1> Đó là phần thiết yếu của Windows Product Activation. <Ophite1> không thể hết hạn nếu bạn không biết thời gian :) <jrandom> hehe <mihi> không có lựa chọn ở trường đại học của tôi... tất cả đồng hồ lệch 1 đến 5 giờ. nhưng có lẽ tôi cũng không được phép chạy i2p ở đó... <Ophite1> mihi: i2p nên cố gắng đặc biệt để hoạt động trong tình huống như vậy... <jrandom> mihi> tuyệt! bạn có thể giúp thử nghiệm chế độ ẩn :) <jrandom> nhân tiện, mùa hè này tôi sẽ đi đây đi đó <jrandom> có lẽ tôi sẽ offline, không mang laptop. <i2p> <duck> ý nghĩ ngoài lề: ntp.duck.i2p :) <Ophite1> Nhìn thế này: Brianna Kazaa tải một client chia sẻ tệp ẩn danh mới ngầu mà bạn thân cô ấy bảo là rất tuyệt và cho phép bạn chat bí mật các kiểu. Chúng ta có muốn bảo cô ấy rằng cô ấy cần chỉnh đồng hồ trong vòng 30 giây (lấy ở đâu ra?)? Hay chúng ta muốn nó cứ thế mà chạy? <jrandom> nhưng tôi sẽ đảm bảo tôi vẫn có thể lên I2P chỉ với các máy công cộng. CTCP Cloaking hiện [Tắt] <jrandom> khỏi phải nghĩ Ophite1. cứ chạy (có tài liệu cho dân geek) <jrandom> duck> bootstrap ;) <jrandom> và i2p sẽ /không/ cần root. <Ophite1> Ý tôi là vậy. <Ophite1> jrandom: bạn có chạy một router trên máy mà bạn không có root không? <jrandom> vậy thì, kết hợp giữa tùy chọn 3 và 4 <Ophite1> tùy chọn 3.5 nghe hay đấy ;) <jrandom> Ophite1> tôi sẽ chạy cả trăm cái :) <mihi> tùy chọn 3.1415926... <jrandom> (và sang phòng lab tiếp theo, chạy thêm trăm cái nữa) <Ophite1> Ồ. Pie. Ngon.;) <Ophite1> jrandom: tôi nói là bạn không có root cơ mà. Nghiệp dư. :) <jrandom> lol <jrandom> vậy về cơ bản là vậy. <jrandom> cho đến khi phần thời gian được triển khai, mọi người nên dùng tùy chọn 1 hoặc 2. <jrandom> với tùy chọn 2, nếu ai đó có thể viết vài tài liệu, tôi sẽ rất cảm kích <Ophite1> như vậy tạm chấp nhận được vì chúng ta Chưa Sẵn Sàng cho Brianna Kazaa và các bạn ;) <mihi> jftr: tôi sẽ không thử "hidden operation". tài khoản đại học của tôi đã bị khóa một lần và tôi không muốn bị chặn lần nữa... <Ophite1> mihi: Bạn là bài test tốt nhất mà chúng tôi có thể có. <jrandom> Ophite1 > không để thử. <jrandom> 'k mihi, chúng ta sẽ tìm cách, và khi sẵn sàng bạn sẽ có thể dùng nó. <Ophite1> OK, có lẽ không nên thử. Một số trường đủ gắt để đuổi bạn chứ không chỉ chặn. <Ophite1> Tôi biết một người ở trường đại học chống chia sẻ tệp và ủng hộ RIAA nhất ở Mỹ. Anh ấy vận hành một dumpsite 2gbit. <jrandom> lol hay đấy <Ophite1> Tôi hiểu rằng rất rất ít người liều đến vậy. <jrandom> ok, thế là đủ về đồng bộ thời gian. <jrandom> eco_> hi. có gì về bt bạn muốn nói không? {hoặc để đến tuần sau} <Ophite1> nhưng hãy nhớ rằng phần lớn Internet trong tương lai có lẽ sẽ trở thành môi trường đại học/doanh nghiệp. i2p có thể bị cấm. i2p RẤT CÓ THỂ bị các ISP lớn xem là lạm dụng. i2p vẫn sẽ phải hoạt động. <Ophite1> Tôi có vài ý tưởng thú vị theo hướng đó sẽ trình bày vào dịp sau. <jrandom> chuẩn <Ophite1> (transport) <rsk> i2p bị các ISP lớn xem là lạm dụng, đọc hợp đồng của bạn đi <Ophite1> rsk: chạy một proxy cache phân tán? <rsk> chạy bất kỳ 'server' nào <Ophite1> rsk: Trừ khi nó chuyển tiếp đến SMTP hoặc WWW. <jrandom> chạy bất kỳ loại dịch vụ nào <jrandom> đúng <Ophite1> rsk: Hehe, tôi có giải pháp cho chuyện đó ;) <eco_> jrandom: có thể cập nhật ngắn <jrandom> sàn là của bạn :) <eco_> tôi đang port client BitTorrent dựa trên Java là snark (www.klomp.org/snark) để làm quen với i2p <eco_> bản port đầu chạy trên i2ptunnel, gọi trực tiếp các lớp Java <eco_> trạng thái hiện tại: chạy được với 2 peer, mọi thứ loạn lên khi > 2, các tunnel không được dọn dẹp, nên khởi động lại rất mệt <eco_> ETA: cuối tuần này ≡ eco_/#i2p nhận ra rằng điều này có thể bị xem là > 2003 <jrandom> w00t! ≡ jrandom hack time.nist.gov <eco_> một bản port "thực" có lẽ sẽ cắt giảm overhead của các tunnel, nhưng đó là bước tiếp theo <jrandom> ngon ≡ eco_/#i2p trả lại sàn cho mc jrandom <jrandom> 'k, tôi nghĩ thế là hết <jrandom> 6) ??? <jrandom> ai còn gì nữa không? ≡ eco_/#i2p muốn bày tỏ lời cảm ơn vì công việc tuyệt vời mà jrandom cùng mọi người đã làm đến giờ <eco_> và rằng giấc ngủ có ích cho home sapiens, dù jrandom dường như chứng minh điều này là sai <jrandom> ;) <jrandom> mọi người nghĩ sao về việc họp ở đây thay vì iip, cho đến khi i2p đủ tin cậy? <jrandom> cá nhân tôi, tôi mệt mỏi vì các buổi họp bị xé nát mỗi tuần. <i2p> <anon> lilo tệ quá! <eco_> chúng ta có thể đang làm nhiều người không tham gia được khi sang đây <jrandom> đúng vậy, tôi biết. <jrandom> nếu chúng ta có thể có một cầu nối iip<-->đây <i2p> <duck> IIP đang loại mọi người ra mỗi ngày <jrandom> như vậy sẽ tốt. <jrandom> đúng. <jrandom> thật không may, iip không dùng được cho một cộng đồng phát triển cần độ tin cậy. <i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html <i2p> <duck> đó là code mà eyeKon v.v. dựa trên <jrandom> và dù tôi thích tách ra tự code, mọi người đưa ra những ý tưởng rất hay và làm những thứ quan trọng ≡ rsk/#i2p đang viết một script cập nhật Windows <i2p> <duck> về lý thuyết nó có thể kết nối tới 3 máy chủ và mirror từng cái <jrandom> chuẩn duck, có lẽ tôi sẽ thử chạy một cái trên i2p.dnsalias.net <jrandom> ping flood từ địa ngục ;) <eco_> irc ở duck.i2p hôm nay khá tốt, vượt iip <jrandom> đồng ý <jrandom> tuy nhiên rớt tôi vài lần. <jrandom> có lẽ tuần sau sẽ tin cậy hơn <eco_> nó nằm trong tay bạn :-) <jrandom> độ tin cậy có lẽ sẽ chưa cải thiện cho đến 0.3, còn khoảng ~2 tuần nữa <jrandom> (1 tuần cho mấy thứ tunnel/streaming, 1 tuần cho peer profiling / testing) <jrandom> rồi sẽ có những bug gì đó phát sinh :) <jrandom> tuy nhiên phải nói là tôi rất phấn khích khi stream audio từ aum tối qua <jrandom> và ardvark đã stream được 42 phút không cần buffering! <jrandom> vậy có lẽ chúng ta có thể đủ tin cậy <jrandom> (router cục bộ của tôi chỉ phttp, có lẽ là một nguyên nhân nhỏ) <jrandom> ok, còn ai có gì nữa không? <i2p> <duck> không nghĩ ra điều gì ≡ eco_/#i2p cũng vậy ≡ jrandom kết thúc... ≡ jrandom *baf* đóng cuộc họp