Tóm tắt nhanh
Có mặt: ant, aum, bla, cervantes, detonate, duck, fedo, frosk, jrandom, legion, maestro^, mancom, named, postman, Ragnarok, septu_ssh
Nhật ký cuộc họp
13:06 <@jrandom> 0) chào 13:06 <@jrandom> 1) 0.5.0.2 13:06 <@jrandom> 2) cập nhật mail.i2p 13:06 <@jrandom> 3) cập nhật i2p-bt 13:06 <legion> vậy nó liên quan đến các máy chủ IRC? 13:06 <@jrandom> 4) ??? 13:06 <@jrandom> 0) chào 13:06 <@jrandom> ghi chú trạng thái hàng tuần đã lên @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html 13:07 <fedo> chào 13:07 <+postman> chào 13:07 <frosk> chào mọi người 13:07 <@jrandom> legion: không, liên quan đến các bug của i2p, đang được xử lý 13:07 <bla> chào 13:07 <legion> ok 13:07 <@jrandom> nói về các bug đang xử lý, hãy nhảy vào 1) 0.5.0.2 :) 13:07 <cervantes> chào 13:07 <cervantes> -- Đã ngắt kết nối 13:08 <@jrandom> hêhê 13:08 <ant> <mihi> chào mọi người 13:08 <@jrandom> 0.5.0.2 đã phát hành, và dù kết nối IRC của bạn đôi lúc có thể lag, nó sẽ hồi lại ;) 13:08 <@jrandom> woa chào mihi 13:09 <cervantes> chào mihi 13:09 <@jrandom> các ghi chú trạng thái nêu tổng quan về tình hình hiện tại và các ưu tiên trước mắt 13:10 <@jrandom> thứ đáng sợ mà tôi đang cố lần ra có thể thấy ở http://localhost:7657/oldstats.jsp#router.invalidMessageTime 13:10 <bla> Với tôi, có thể nói 0.5.0.2 đã cải thiện độ tin cậy RẤT LỚN so với 0.5.0.1: lỗi không thể liên lạc được với đích hầu như không còn xảy ra nữa 13:10 <@jrandom> các con số đó lẽ ra phải rất rất nhỏ, nhưng tiếc là không 13:10 <@jrandom> ngon đó bla 13:11 <@jrandom> ừ, 0.5.0.2 chắc chắn là một cải tiến, và mọi người nên nâng cấp NGAY 13:11 <bla> 375,932.22 trong 10 phút vừa rồi bên tôi.... 13:11 <@jrandom> thật ra giá trị cụ thể không phải vấn đề, mà là tần suất của chúng 13:11 <@jrandom> (sự kiện mỗi khoảng thời gian) 13:12 <@jrandom> những thông điệp đó nhiều khả năng là do các router 0.5 gây ra, và một phần do router 0.5.0.1, đó là lý do tôi muốn mọi người nâng cấp NGAY 13:12 <@jrandom> cũng có thể là do thứ khác, nhưng tôi muốn loại trừ nó trước 13:12 <bla> jrandom: tôi nhận khoảng 200 mỗi giờ ở đây 13:13 <@jrandom> bla: giờ này tôi có 93, nhưng đỉnh cao hơn nhiều (hàng nghìn) 13:13 <@jrandom> dù sao, thống kê cụ thể này được công bố trong netdb 13:13 <bla> jrandom: Thế khi phát hành 0.5.0.3 loại bỏ 0.5-0 khỏi mạng bằng phần mềm thì sao? 13:14 <@jrandom> vậy chúng ta có thể nhìn quanh và xem người khác có giá trị gì ;) 13:14 <@duck> 309,854.24 đỉnh 5,473,314.59 13:15 <@duck> dán nhầm cái khác rồi, hả 13:15 <@jrandom> bla: chắc chắn. Tôi đã thêm một ít code trong bản 0.5.0.2 để làm tương thích tiến mà 0.5.0.1 và 0.5 không có 13:16 <@jrandom> duck: khó mà có # sự kiện không nguyên ;) 13:16 <bla> jrandom: Tốt. Ít nhất như vậy cho phép bạn kiểm thử giả thuyết invalid-messages-are-due-to-0.5-0 trong môi trường có kiểm soát 13:16 <@jrandom> bla: ừ, nhưng sẽ tuyệt nếu mọi người cập nhật trước ;) 13:17 <@jrandom> (và cho những ai đang đọc ở nhà: http://www.i2p.net/download là bạn của bạn ;) 13:17 <maestro^> jr: các con số lệch router.invalidMessageTime tính theo ms? 13:17 <@jrandom> maestro^: đúng 13:18 <@jrandom> (hay còn gọi là các giá trị lệch cực kỳ điên rồ) 13:18 <legion> Đây là báo cáo mạng nhỏ [version|Number of nodes][0.5|6][0.5.0.1|39][0.5.0.2|107] 13:18 <@jrandom> ừ, mọi người đã cập nhật rất tốt 13:18 <legion> Vậy vẫn có vài người chạy 0.5 và nhiều người chạy 0.5.0.1 13:18 <maestro^> vậy có ý tưởng nào họ đang lag ở đâu không? 13:18 <bla> jrandom: Freenet có một cờ trong mỗi bản phát hành chỉ định phiên bản node tối thiểu mà nó sẽ giao tiếp. Code tương thích tiến mới có kiểu như vậy không? 13:19 <@jrandom> maestro^: có rất nhiều lý do khiến người dùng 0.5 và 0.5.0.1 bị lag. 13:19 <@jrandom> bla: tương tự 13:19 <maestro^> hay là do lệch đồng hồ trên các node? 13:20 <@jrandom> maestro^: lệch đồng hồ, một số bug tuần tự hóa, bug 100% CPU 13:20 <@jrandom> ok, đó là trọng tâm của tôi lúc này, cố đưa độ tin cậy thông điệp lên lại 13:21 <@jrandom> ai có câu hỏi/bình luận/lo lắng gì về 0.5.0.2 không? 13:21 <ant> * mihi có một router 0.4.2.5 trên ổ cứng ở đây chưa khởi động từ 22/12... nhưng nghĩ tốt hơn là xóa đi... 13:21 <@jrandom> hêhê 13:21 <@jrandom> ờ, cái đó sẽ không nói chuyện với nhiều router đâu ;) 13:21 * postman có một bản sao lưu cài đặt 0.4 cuối cùng của mình :) 13:21 <ant> <mihi> câu hỏi của tôi là nâng cấp hay xóa. 13:22 <@jrandom> xóa 13:22 <@jrandom> (sao lưu bất kỳ khóa đích nào) 13:22 <@jrandom> không còn quy trình nâng cấp từ trước 0.5 nữa 13:22 <legion> Có lẽ phát hành một cập nhật khác, ví dụ 0.5.0.2-1 chỉ cho phép kết nối từ 0.5.0.2 hoặc mới hơn, sẽ tốt? 13:22 <@jrandom> legion: như vậy sẽ chia tách mạng 13:22 <@jrandom> mọi người chỉ cần nâng cấp. 13:23 <@jrandom> (và chúng ta nên tìm cách lách qua những ai không nâng cấp) 13:24 <legion> ừ cho đến khi những người chạy node lỗi thời cập nhật ;) 13:24 <@jrandom> chia tách mạng làm hại tất cả chúng ta, không chỉ họ 13:25 <legion> Có lẽ nếu có thông báo cập nhật trong console của router hoặc gì đó để họ biết họ đang chạy phiên bản lỗi thời? 13:25 <@jrandom> ừ, cái đó khá hay 13:25 <@jrandom> hy vọng có thể buộc nó với trình cập nhật nữa 13:26 <legion> ừ, tôi biết, phân mảnh là không tốt... 13:26 <@jrandom> smeghead đang làm một số thành phần chính cho việc đó, nhưng không chắc có gồm thông báo / tải xuống không 13:26 <@jrandom> (vậy ai muốn giúp làm cái đó, liên hệ nhé!) 13:27 <@jrandom> ok, chuyển sang 2) cập nhật mail.i2p 13:27 <@jrandom> postman: ping 13:27 <+postman> có 13:27 <bla> jrandom: nếu nhớ không nhầm thì smeghead đang làm gì đó liên quan ký số (để khi bạn nhận thông báo cập nhật, ít nhất bạn biết nó là thật, không phải phishing/spyware/linh tinh) 13:28 * postman cầm mic 13:28 <legion> hừm, có lẽ nếu có tính năng tự động cập nhật tích hợp, nơi cập nhật được tải qua i2p và các node chỉ việc tải về rồi khởi động lại êm ái. 13:28 <@jrandom> đúng đó bla 13:28 <ant> <Gatak> À, tiện thể. I2P có chạy được sau NAT ngay cả khi bạn không mở được cổng không? 13:28 <@jrandom> Gatak: chưa. một số người sẽ làm được ở 0.6, số khác ở 2.0 13:29 <@jrandom> legion: hoan nghênh các bản vá 13:29 <ant> <Gatak> 2.0 trời, còn xa lắm =) 13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;) 13:29 <+postman> ờm, tôi bắt đầu nhé? 13:29 <aum> chào buổi sáng mọi người 13:30 <@jrandom> mic là của bạn, postman (xin lỗi ;) 13:30 <@jrandom> chào aum, kịp cuộc họp rồi 13:30 <@jrandom> (chà! /me im lặng lại) 13:30 <cervantes> Gatek: http://www.i2p.net/roadmap 13:30 <+postman> đầu tiên, tôi muốn nói là chúng ta đã đạt 300 tài khoản đăng ký tại postman.i2p rồi 13:30 <@jrandom> w00t 13:30 <+postman> số lượng thư từ/đến Internet đang tăng đều và một lần nữa chứng minh rằng chúng ta cần tiến xa hơn 13:31 <cervantes> *kít la* 13:31 <+postman> sau khi nói chuyện với jr vài tuần trước, chúng tôi thống nhất phát hành v2mail cùng với I2P 1.0 13:31 <+postman> trạng thái gần đây: smtp proxy viết bằng java, thiết kế để chạy trên mọi node, đã xong 13:31 <@jrandom> hay lắm! 13:32 <+postman> POP3 proxy viết bằng java được 80% còn thiếu phần maildir engine 13:32 <+postman> sẽ có một webmanager vẫn cần tinh chỉnh nhiều (xong 15%) 13:32 <+postman> giao tiếp liên node ở mức 40% - chúng tôi đã thử trao đổi bản ghi dữ liệu bằng HTTP/XML 13:33 <+postman> có vẻ chạy khá tốt và nhanh nữa 13:33 <+postman> ngay cả khi một relay node hỏng/tắt vài ngày, nó sẽ được đồng bộ trong vài phút sau khi lên mạng lại 13:33 <@jrandom> đỉnh 13:33 <+postman> tôi nghĩ chúng ta khá đúng tiến độ 13:34 <+postman> có một điều đáng chú ý 13:34 <bla> postman: Làm tốt lắm! Một câu hỏi: Nhiều node không thể nhận hoặc gửi dữ liệu trên cổng 25 (ít nhất là trực tiếp). Chủ node có thể chỉ định điều này (hay sẽ tự phát hiện)? 13:34 <cervantes> hay 13:34 <+postman> bla: để sau 13:34 <+postman> trong v2mail sẽ có một webapp chạy cục bộ 13:34 <+postman> với cái này bạn có thể quản lý các proxy cục bộ của mình VÀ xin một "relayaccount" 13:35 <+postman> relayaccount này sau đó sẽ được dùng để gán addess/domain của bạn với các relay 13:35 <+postman> các relay sẽ tự đồng bộ thông tin 13:35 <@jrandom> hay 13:35 <+postman> ngay cả các tính năng như sổ địa chỉ / khóa công khai và các thứ sẽ hoạt động với giao diện CỤC BỘ 13:36 <+postman> vậy ý tưởng là có một trình quản lý tập trung nơi bạn làm mọi thứ về thư tín 13:36 <+postman> dữ liệu liên quan được truyền tới MỘT trong các relay rồi được đồng bộ giữa các relay 13:36 <+postman> và trình quản lý nền web này sẽ chạy ngay trên node của bạn 13:37 <+postman> khi node của bạn online, các relay sẽ chuyển thư xếp hàng cho destination/domain/địa chỉ của bạn 13:37 <+postman> nó sẽ được chuyển đến smtp proxy cục bộ của bạn 13:37 <+postman> bạn thậm chí có thể kích hoạt toàn bộ bằng ETRN :) 13:37 <aum> chào lại 13:37 <aum> tôi muốn nêu một điểm thảo luận trong cuộc họp này, nếu được 13:37 <+postman> tương lai là vậy đó mọi người :) 13:37 <+postman> . 13:38 <@jrandom> nghe ngầu đó postman 13:38 * postman trả mic lại 13:38 <@jrandom> aum: tuyệt, có thể sẽ có thời gian ở mục 4) 13:38 <+postman> ừ, tôi rất phấn khích :) 13:38 <@jrandom> postman: vậy với người dùng bình thường, smtp proxy sẽ có maildir cục bộ, và pop3 proxy sẽ đọc/v.v., đúng chứ? 13:39 <+postman> đúng, smtp proxy có MDA 13:39 <+postman> và sẽ chuyển thư vào các maildir cục bộ 13:39 <+postman> thậm chí có thể tạo nhiều tài khoản/người dùng cục bộ 13:39 <cervantes> postman: các relay có theo dõi quota của bạn v.v. và truyền thông tin như vậy lẫn nhau không? 13:39 <+postman> và ánh xạ tới các tài khoản của domain bạn 13:39 <+postman> cervantes: có 13:39 <septu_ssh> xin lỗi, tôi có thể hỏi postman về cơ chế thanh toán/chống spam trong mô hình mới không? 13:40 <+postman> septu_ssh: bạn đã đọc tài liệu nào trên trang web chưa? 13:40 <+postman> cervantes: nó không phải thời gian thực hoàn hảo 13:40 <+postman> cervantes: nhưng tôi thấy ổn với việc cập nhật trao đổi thông tin quota sau vài phút 13:40 <septu_ssh> postman: đang xếp hàng để đọc :/ 13:40 <septu_ssh> nhưng nếu đã được tài liệu hóa thì ổn 13:40 <cervantes> postman: ừ tôi đoán vậy 13:41 <+postman> septu_ssh: www.postman.i2p/inout.html 13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html 13:41 <+postman> cervantes: chuyện này không nghiêm trọng đâu - quota là một giới hạn hợp lý 13:41 <cervantes> postman: ngay cả khi ai đó có thể gửi đến nrelays * quota người nhận cũng không phải điều tệ 13:41 * septu_ssh là bungle 13:41 <+postman> cervantes: ừ 13:42 <+postman> mục tiêu chỉ là ngăn bất kỳ ai thật sự lạm dụng dịch vụ 13:42 <+postman> trong các thử nghiệm, tôi có 3 relay và chúng rất nhanh 13:42 <@jrandom> postman: tôi quên, cái này có hỗ trợ smtp relay cục bộ nói chuyện trực tiếp với smtp relay của người khác, thay vì nảy qua các node của bạn không? 13:42 <+postman> cervantes: trong vòng 10 giây là chúng đã đồng bộ :) 13:43 <@jrandom> (hoặc có lẽ để sau) 13:43 <+postman> jrandom: các i2p mail relay sẽ được vận hành bởi vài người và là đích ưu tiên để định tuyến thư 13:43 <cervantes> postman: bạn có thể đưa vào một độ trễ tăng theo hàm mũ cho hàng đợi gửi 13:43 <cervantes> nếu nó trở thành vấn đề 13:43 <+postman> jrandom: nên gửi đến các đích khác có thể hữu ích trong một số trường hợp 13:44 <@jrandom> ừ, nhưng nguy hiểm trong những trường hợp khác 13:44 <cervantes> vậy càng gửi nhiều thư thì thời gian xếp hàng càng lớn... sẽ cho các relay thời gian bắt kịp 13:44 <+postman> jrandom: nhưng nếu chủ một node công khai IMIO destination của mình thì có thể bị spam không kiểm soát :) 13:44 <@jrandom> chính xác 13:44 <@jrandom> mặt khác, nếu các i2p mail relay thù địch thì cũng vậy 13:45 <+postman> jrandom: đúng, đó là một cấu trúc kiểu WOT 13:45 <@jrandom> </tinFoil> 13:45 <+postman> jrandom: tôi không thể ngăn một operator relay phân phối quota bằng 0 cho địa chỉ của bạn 13:45 <@jrandom> ok tuyệt. ừ, chưa cần lo chuyện đó bây giờ 13:45 <+postman> :) 13:46 <+postman> ok 13:46 <+postman> . 13:46 <@jrandom> ok hay lắm, cảm ơn cập nhật. Rất nhiều thứ thú vị 13:46 <@jrandom> ok, chuyển sang 3) i2p-bt cập nhật 13:46 <@jrandom> duck: ping 13:46 <@duck> chào 13:47 <@duck> Hôm qua BitTorren 4.0.0 được phát hành 13:47 <ant> <dm> nghe giống tiếng Đức 13:47 <@duck> mà chúng tôi gần như đã chờ trước khi bắt đầu 0.2 13:47 <@duck> đã viết tasklist / todo: http://pastebin.ca/raw/7037 13:47 <@duck> (xin lỗi www của tôi hiện đang down) 13:48 <@jrandom> hay 13:48 <legion> chúng ta đang nói về mốc thời gian thế nào cho 0.2? 13:48 <@duck> mục tiêu là 4 tuần 13:49 <legion> hay 13:49 <@duck> như bạn thấy RawServer (phần giao tiếp với i2p) là tác vụ lớn nhất 13:50 <@duck> . 13:50 <@duck> thăm dò nhanh: 13:50 <legion> ừ, tôi biết rõ điều đó :) 13:50 <@duck> ai dự định tạo một fork i2p-bt? 13:50 <@jrandom> hay đó, có gì mọi người có thể làm để giúp không? 13:50 <@jrandom> hêhê 13:51 <ant> <dm> i 13:51 * jrandom nhặt một cái thìa 13:51 <ant> <dm> m sẵn sàng giúp 13:51 <legion> i 13:51 <ant> <dm> m gay 13:51 <legion> Tôi đang làm một fork 13:52 <@duck> tốt, vậy tôi biết ai không nên coi trọng. 13:52 <@duck> thật sự, tôi nghĩ như vậy là ngớ ngẩn; gom nguồn lực có thể đưa bạn đi xa hơn nhiều 13:53 <@jrandom> hoặc có lẽ nếu có cách hay hơn, bạn có thể thuyết phục duck làm theo cách đó? 13:53 <named> Tôi sẽ viết một fork bằng qbasic, xin hãy coi tôi nghiêm túc. 13:53 <@duck> Tôi sẽ cố gắng làm quá trình mở hơn, để người khác thấy những gì được lên kế hoạch v.v. 13:53 <ant> <dm> sự cởi mở của bạn không làm chúng tôi lung lay. FORK! FORK! FORK! FORK! 13:53 <@duck> nếu bạn có bất kỳ đề xuất nào khác 13:54 <ant> * dm nhấc legion lên vai. 13:54 <legion> hừm, có thể đúng, dù với những gì tôi đang làm tôi nghi rằng bạn không muốn tôi làm bẩn quá trình phát triển i2p-bt chính ;) 13:54 <ant> <dm> FORK! FORK! FORK! FORK! 13:54 <@jrandom> legion: bạn đang làm gì mà duck sẽ không muốn hỗ trợ? 13:55 <@duck> legion: chúc mừng, nếu bạn google 'i2p bittorrent', thì một thông báo "Windows I2P Bittorrent Version 1.0" đứng #1 13:55 <@jrandom> trời 13:56 <bla> jrandom: Gì? 13:56 <+postman> jrandom: ừ, họ sẽ xé toạc cái mạng này sớm thôi :) 13:56 <bla> ;) 13:56 <named> 1.0? Chết tiệt, tôi đang dùng 0.1.8! 13:56 <Ragnarok> trời 13:57 <legion> ôi trời, thật sao?! Tôi không thể tin được... điên rồ. 13:57 <@duck> dù sao, tôi không nghĩ có nhiều điều mới để nói về chuyện này 13:57 <legion> bản 1.0 của tôi dựa trên 0.1.8, nếu bạn chạy 0.1.8 thì ổn. 13:58 <@jrandom> (và bản 1.0 là một .exe mà chưa ai rà soát, tùy bạn mạo hiểm) 13:58 <legion> Tôi đặt tên và đánh số tệ, xin lỗi lần nữa. 13:58 <ant> <dm> 1.0>> 0.1.8 13:58 <ant> <dm> bất kỳ ngày nào trong tuần 13:59 <@duck> hơi liên quan: 13:59 <@jrandom> ok, còn gì nữa ở 3) i2p-bt, hay chúng ta chuyển sang 4) ??? 13:59 <+postman> legion: khi nào sẽ có mã nguồn tải xuống? 13:59 <frosk> "I2P-BT 0.1.8 chạy khá tốt và ổn định đến giờ. Cá nhân tôi không thấy lý do để cập nhật lên I2P-BT 1.0" (thấy trên diễn đàn) 13:59 * jrandom thở dài 13:59 <@duck> tháng trước bram cohen có một buổi nói chuyện về bittorrent ở một trường đại học nào đó 14:00 <@duck> khá thú vị: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent 14:00 <@duck> (bài học rút ra về các chương trình p2p lớn, thêm vài chi tiết bittorrent được giải thích) 14:00 <@duck> . 14:01 <@jrandom> chuẩn 14:01 <@duck> postman: legion đã phát hành một ít mã nguồn 14:01 <ant> <dm> đó có phải người phát minh BT không? 14:01 <@duck> nhưng theo smeghead thì nó không giống với file .exe 14:01 <@jrandom> dm: đúng 14:01 <legion> Có một mã nguồn cho developer bạn có thể tải từ http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2 14:02 <+postman> ok, sẽ xem 14:02 <ant> <dm> exe có phải biên dịch trực tiếp từ source đó không? 14:03 <legion> thật ra mã nguồn 1.0 về cơ bản chỉ là 0.1.8 với một patch từ smeghead, biên dịch và đóng gói gọn gàng. 14:04 * cervantes đi tới 4)??? và đợi mọi người theo kịp 14:04 <ant> <dm> câu hỏi vẫn chưa được trả lời 14:04 <ant> <dm> Legion, anh có hay không đã ra lệnh code red??? 14:04 <@jrandom> *khụ* 14:04 <legion> Có lẽ chúng ta nên quay lại chủ đề, thảo luận về client bt của tôi chuyển sang #itorrent 14:05 <@jrandom> ok, 4) ??? 14:05 <@jrandom> còn điều gì khác mọi người muốn nêu không? 14:05 <@jrandom> aum: bạn có gì không? 14:06 <ant> <dm> stasher đã trở lại? 14:06 <legion> Tôi thấy vài hành vi kỳ lạ với 0.5.0.2 trong các giai đoạn lưu lượng nặng... 14:06 <aum> có 14:06 <aum> tôi muốn nêu câu hỏi về tự động tạo/quản lý tunnel 14:07 <ant> <dm> tiếp đi 14:07 <+detonate> có một null pointer exception trong cái systray trên Windows, tôi vừa để ý 14:07 <aum> thật 1337 khi web console giờ cho phép con người tạo/xóa/quản lý tunnel thủ công 14:07 <@jrandom> detonate: bạn có thể ném nó lên bugzilla không? 14:07 <aum> nhưng tôi cũng tin mạnh mẽ rằng luôn phải có cách đáng tin cậy và tiện lợi để các chương trình quản lý tunnel nữa 14:08 <@jrandom> aum: không ai phản đối. chúng ta cần nó, và sẽ có. chỉ là chưa phải bây giờ. 14:08 <ant> <dm> không làm qua SAM được à? 14:08 <aum> tôi nhận thấy khi quay lại i2p gần đây là thư viện pysam không còn hoạt động 14:08 <septu_ssh> tôi cũng có câu hỏi nhanh sau aum 14:08 <aum> khá thất vọng 14:08 <@jrandom> giao thức SAM hoạt động, pysam thì không 14:08 <Ragnarok> nó có bao giờ chạy chưa? 14:09 <aum> có 14:09 <aum> pysam từng hoạt động rất tốt 14:09 <legion> Trong những giai đoạn như vậy có hơn 1000 tunnel mà node của tôi tham gia và vài giây lag và trễ. 14:09 <@jrandom> legion: ừ, số tunnel là do các bản build cũ 14:09 <cervantes> à mymodesty 14:09 <cervantes> ờ pymodesty 14:09 <aum> hiện tôi đang viết một module 'i2ptunnel.py', định nghĩa các class cho phép quản lý tunnel dễ dàng 14:10 <legion> vậy nếu không kết nối với các bản build cũ, mạng sẽ mượt hơn nhiều? 14:10 <@jrandom> ok, tôi không biết đó có phải giải pháp dài hạn đúng không, nhưng nếu nó bắc cầu cho bạn bây giờ thì tốt 14:10 <@jrandom> legion: những tunnel đó không phải vấn đề 14:11 <aum> ừ, giao diện class có thể giữ nguyên dù cơ chế bên dưới thay đổi 14:11 <@jrandom> ok 14:11 <legion> không phải sao? 14:12 <legion> Khi có ít tunnel thì hầu như không có lag và trễ... 14:12 <cervantes> legion: xin lỗi aum đang nêu vài câu hỏi, bạn đợi chút nhé 14:12 <legion> nghe có vẻ lạ với tôi. 14:13 <legion> ok 14:13 <@jrandom> tôi chỉ lo rằng ta cần cân nhắc những gì đã thành công trước đây - web config hoạt động và được duy trì vì mọi người đều dùng nó. có lẽ tốt nhất là làm cho ứng dụng bạn đang viết chạy với việc tạo tunnel thủ công TRƯỚC, như vậy sẽ hiệu quả hơn? 14:13 <@jrandom> để luôn có thứ gì đó đang dùng i2ptunnel.py, nhằm stress nó 14:13 <aum> có vẻ chúng ta đang bế tắc 14:13 <+detonate> jrandom:được chứ 14:14 <ant> <dm> vậy chuyển sang đi 14:14 <aum> tôi không muốn đầu tư thời gian phát triển app của mình cho đến khi tôi có một API quản lý tunnel mà tôi có thể tin cậy 14:14 <septu_ssh> \o. - ý muốn nêu 14:14 <cervantes> thực tế tôi không thể tưởng tượng giao diện tunnel sẽ được làm lại hoàn toàn trong vài tháng tới... 14:14 <@jrandom> nhưng chắc chắn bạn thấy rằng chúng ta có thể thêm một cái một cách đơn giản 14:14 <cervantes> vậy giải pháp tạm thời là khả thi 14:15 <named_> Web config không thể có một kiểu api nào đó để chương trình của aum điều khiển sao? 14:15 <@jrandom> named_: có thể 14:16 <@jrandom> thêm gì đó để cho phép điều khiển an toàn qua URL là đơn giản, nhưng chỉ có ý nghĩa nếu có thứ cần đến nó 14:16 <@jrandom> nếu không nó sẽ bị bỏ không 14:16 <aum> named_: cái đó sẽ hay, và có thể hoạt động nếu có một mật khẩu hardcoded trong config mà các chương trình client cần POST cùng với các trường điều khiển tunnel 14:16 <cervantes> cá nhân tôi muốn thấy toàn bộ hệ thống tunnel được làm lại hoàn toàn, nếu bạn đưa giao diện quản lý tunnel vào ngay từ đầu thì bạn sẽ không phải lo nỗ lực thêm để duy trì một giao diện riêng biệt 14:17 <@jrandom> ừ, các proxy cần khá nhiều việc, mà tôi đã né tránh nhiều nhất có thể :) 14:17 <aum> SAM tốt cho một số tình huống, dở cho những tình huống khác 14:17 <cervantes> nhưng đó là chuyện về sau... 14:17 <fedo> ( 14:18 <@jrandom> aum: nhưng như giải pháp tạm thời, bạn không thể dùng một trong ba phương pháp sẵn có sao? 14:18 <cervantes> ví dụ nếu chính webinterface dùng api thì sẽ không có gánh nặng bảo trì 14:18 <@jrandom> đúng. web interface dùng TunnelControllerGroup 14:19 <aum> dùng SAM trở nên khó khi muốn dùng các thư viện sẵn có phụ thuộc nhiều vào các TCP sockets chuẩn 14:19 <aum> jrandom: I2PTunnel CLI không hoạt động cho việc mở server tunnels, nên hiện tôi đang viết code dùng TunnelControllerGroup 14:19 <@jrandom> aum: các thư viện hiện có cần được kiểm toán cẩn thận. ví dụ, chính tiện ích gzip cũng lộ dữ liệu nhạy cảm 14:19 <aum> đang code đây 14:21 <@jrandom> Tôi chắc là CLI chạy được với server tunnels, nhưng dùng TunnelControllerGroup thì được ưu tiên nếu bạn cần theo cách đó 14:21 <@jrandom> ok, còn ai có gì muốn nêu không? 14:22 <septu_ssh> Câu hỏi của tôi liên quan đến phiên bản phân tán của hosts.txt, hiện có một bảng DHT dùng cho routerInfo, liệu không thể mở rộng thành phiên bản phân tán của DNS? DNS DHT có thể chứa ánh xạ từ www.bla.i2p đến SHA của eepsite, và các mục sẽ được ký bởi một 'I2P registrar'... ý kiến? phản biện? 14:22 <mancom> một câu hỏi về lộ trình: 0.6 vẫn dự kiến vào tháng Tư chứ? 14:22 <@jrandom> septu_ssh: dữ liệu không định tuyến đưa vào netDb là bước qua xác tôi ;) 14:23 <septu_ssh> jrandom: không phải cùng một db 14:23 <septu_ssh> một db phân tán khác 14:23 <aum> jrandom: bạn thấy báo lỗi của tôi chưa? lệnh CLI 'server' /không hoạt động/ 14:23 <maestro^> septu_ssh: không có i2p registrar nào cả 14:23 <@jrandom> septu_ssh: có nhiều khía cạnh nguy hiểm của đặt tên, với vài thỏa hiệp then chốt. bạn đã xem thảo luận về đặt tên trên ugha.i2p chưa? 14:24 <@jrandom> septu_ssh: à, một DHT chạy trên I2P chắc chắn có thể dùng để phân phối các mục, dù những tên đó sẽ không an toàn nếu được coi là các mục toàn cục 14:26 <@jrandom> aum: tôi dùng nó hàng ngày cho đến vài tuần trước, bạn đã thấy phản hồi của tôi chưa? 14:26 <@jrandom> maestro^: đó là kế hoạch 14:26 <@jrandom> à, mancom: 14:26 <cervantes> aum: tôi có một phản hồi cho mail i2plist đó từ jr, nó chưa đến được bạn, hay vấn đề vẫn còn? 14:26 <septu_ssh> lý do duy nhất tôi gợi ý 'registrar' là vì nếu không va chạm có thể xảy ra 14:26 <@jrandom> septu_ssh: hãy chấp nhận va chạm :) 14:26 <@jrandom> tên vừa duy nhất toàn cục, dễ đọc, phân tán và an toàn là không tồn tại 14:27 <septu_ssh> nó cũng có thể xảy ra trong host.txt nếu chỉnh tay, nhưng vấn đề vẫn thế 14:27 <@jrandom> bỏ điều kiện đầu tiên, là ổn 14:27 <aum> jrandom: tôi có streaming.jar trong classpath (cp) 14:27 <septu_ssh> postman quản lý một nút trung tâm cho mail, vậy có một yếu tố tin cậy nào đó trong mạng, chắc chắn ai đó sẽ tin một registrar quản lý không gian tên? 14:27 <@jrandom> ok hay, và nó vẫn trả về stacktrace đó chứ aum? 14:28 <aum> có 14:28 <@jrandom> septu_ssh: postman chỉ đóng vai trò trung tâm cho các outproxy và inproxy của postman 14:28 * Ragnarok thật sự cần ngó tới việc viết tài liệu sổ địa chỉ... 14:28 <aum> khi tôi chạy CLI thủ công, làm genkeys, rồi làm 'server' dùng privkeyfile do genkeys tạo ra 14:28 <@jrandom> septu_ssh: sẽ không ai tin ai đó để quản lý không gian tên. kiểm duyệt == gây áp lực lên registrar đó. 14:28 <maestro^> thực ra mỗi người là registrar của chính mình 14:29 <maestro^> bạn tin bạn bè bạn và họ tin bạn 14:29 <aum> chết tiệt, tôi đã lấy nhầm classpath cũ 14:29 * aum thử lại 14:30 <ant> <dm> ok, tôi sẽ là registrar. 14:31 <ant> <dm> tôi sẽ công tâm hết mức... ổn chứ? 14:31 <septu_ssh> hừm, ok, vậy quay lại bảng vẽ ẩn dụ... 14:31 <@jrandom> septu_ssh: một nơi tốt để xem lại là http://zooko.com/distnames.html :) 14:32 <@jrandom> ai cũng muốn nó, nhưng cái họ muốn thì không an toàn. chúng ta có một giải pháp an toàn, nhưng ta từ bỏ tính duy nhất toàn cục 14:33 <septu_ssh> hừm, ok 14:33 <@jrandom> ok, còn ai có gì nữa muốn nêu cho cuộc họp không? 14:33 <cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134 14:33 <aum> jrandom - ok, CLI 'server' giờ chạy, nhưng tôi không nhận được 'job number' cho tunnel 14:34 <@jrandom> hừm đúng, nó chạy mãi 14:34 <aum> à, tôi phải làm 'list' để lấy số job 14:36 <@jrandom> ok hay, nếu không còn gì nữa... 14:36 * jrandom lên dây cót 14:36 * jrandom *baf* kết thúc cuộc họp