Cuộc họp các nhà phát triển I2P - 05 tháng 9 năm 2017

20:00:00 <zzz> 0) Chào 20:00:00 <zzz> 1) cập nhật 0.9.32 (zzz) 20:00:00 <zzz> 2) nhắc nhở email xin tài trợ 34C3 (zzz/echelon) 20:00:03 <zzz> 0) Chào 20:00:05 <zzz> Chào 20:00:44 <zzz> 1) cập nhật 0.9.32 (zzz) 20:00:58 <R4SAS> Chào 20:01:09 <zzz> ok, str4d đã thực hiện một số cập nhật UI, và tôi đã bắt đầu triển khai prop 141 nhưng vẫn chưa check-in gì cả 20:01:37 <zzz> chúng ta đang đúng tiến độ cho một đợt phát hành đầu tháng Mười 20:01:49 <i2pr> [Slack/str4d] Chào 20:02:03 <zzz> Tôi nghĩ str4d muốn đề xuất nhánh benchmark của mình, anh ấy nên làm sớm? Tôi đã bình luận trong ticket của anh ấy 20:02:20 <psi_> ừ 20:02:36 <i2pr> [Slack/str4d] Tôi mới chỉ push một chỉnh sửa UI nhỏ đến giờ; tôi còn nhiều thứ nằm local giải quyết thêm nhiều vấn đề, nhưng tôi cần đi qua quy trình git -> mtn của mình 20:03:09 <i2pr> [Slack/str4d] Tôi sẽ xem các bình luận về benchmark và hoàn thiện / push cái đó vào cuối tuần này 20:03:57 <zzz> ok tôi cần trao đổi với bạn lúc nào đó về quy trình phát hành của chúng ta. Chúng ta có các ticket mức blocker cho .31 mà chưa được đóng, có lẽ cần nhấn mạnh phải đóng chúng trước khi phát hành 20:04:08 <zzz> nếu không thì “blocker” còn có ý nghĩa gì 20:04:23 <i2pr> [Slack/str4d] Đúng 20:04:36 <zzz> còn gì nữa ở mục 1) không? 20:06:01 <zzz> 2) nhắc nhở email xin tài trợ 34C3 (zzz/echelon) 20:06:11 <psi> đợt phát hành này có yêu cầu loại bỏ các hostname không? 20:06:15 <psi> trong RI 20:06:25 <psi> lag quá 20:06:33 <zzz> xem văn bản đề xuất để biết thảo luận về việc di trú 20:06:45 <psi> ok 20:07:07 <i2pr> [Slack/str4d] -1 nếu đưa vào bản phát hành này mà không bàn về các biện pháp giảm thiểu zombie 20:07:08 <zzz> ok liên quan đến 34C3, nếu bạn muốn được tài trợ hoặc vé miễn phí thì BẮT BUỘC phải email cho echelon trước ngày 30/9 20:07:43 <zzz> ngoài ra, echelon có gặp một số sự cố máy chủ, nên nếu bạn không nhận được ACK từ anh ấy rằng đã nhận email của bạn, hãy gửi lại 20:08:46 <zzz> chúng tôi có nhiều kinh phí cho mọi người nhưng bạn phải yêu cầu. Chúng tôi sẽ không tài trợ cho những ai hỏi sau khi hết tháng 20:09:48 <zzz> vì vậy một lần nữa hãy đảm bảo rằng echelon đã xác nhận đã nhận yêu cầu của bạn 20:10:03 <zzz> chúng tôi sẽ đặt ngân sách tại cuộc họp tháng sau 20:10:19 <zzz> còn gì nữa ở mục 2) không? 20:10:36 <i2pr> [Slack/str4d] Không từ phía tôi. 20:11:26 <zzz> còn gì nữa cho cuộc họp không? 20:11:54 <psi> tôi có một việc 20:12:02 <zzz> psi nói đi 20:12:03 <psi> nhưng nó dài và nhàm chán 20:12:09 <psi> đó là ý tưởng về các tunnel đi ra được căn chỉnh 20:12:36 <psi> ban đầu tôi giới thiệu nó với bạn như một kỹ thuật giảm tải cho OBEP 20:12:45 <psi> đó là một tác dụng phụ hay 20:12:53 <psi> nhưng đó không phải là mục đích ban đầu 20:13:10 <psi> mục đích ban đầu là giảm rớt gói 20:13:59 <zzz> ok, vậy bạn muốn thảo luận gì về nó? 20:14:08 <psi> câu hỏi của tôi là: Java I2P có triển khai các tunnel đi ra được căn chỉnh không? 20:14:22 <psi> hay nó quá thử nghiệm đối với các bạn? 20:14:53 <psi> tôi không quen với mã của Java I2P bằng i2pd 20:14:57 <zzz> không thể trả lời ngay vì tôi quên chi tiết. Nếu bạn viết ra và đăng ở đâu đó tôi sẽ sẵn lòng đưa ra câu trả lời 20:15:09 <psi> được 20:15:15 <psi> tôi đoán bạn có thể kết thúc họp 20:15:26 <psi> ý tưởng là OBEP == IBGW 20:15:35 <psi> với một hop bổ sung trên tunnel OB 20:15:38 <eche|offf> tôi chưa có gì 20:15:43 <psi> để OBEP == IBGW 20:16:14 <psi> để giảm rớt gói và áp lực lên OBEP 20:16:30 <psi> (đổi lại là nhiều tunnel hơn) 20:16:51 <zzz> ok, vì bạn đã triển khai rồi, bất kỳ dữ liệu nào về lợi ích sẽ rất hữu ích 20:17:10 <zzz> còn gì nữa về các tunnel đi ra được căn chỉnh không? 20:17:31 <psi> nhận xét ban đầu của tôi là RTT ban đầu giống như về sau 20:17:44 <psi> nói cách khác, không có đột biến RTT ban đầu 20:17:57 <psi> có thể do giảm áp lực lên OBEP 20:18:03 <psi> nhưng đó chỉ là giả định 20:18:15 <psi> tôi muốn thử nghiệm điều này trên một testnet, mà chúng ta có bằng docker. 20:18:25 <i2pr> [Slack/str4d] Nếu có gì chúng ta có thể biến thành benchmark hiệu năng, LMK 20:18:25 <psi> để thu thập các con số cứng v.v. 20:19:01 <psi> ừ tôi cũng vậy, tôi đang bí một benchmark hiệu năng tốt 20:19:18 <psi> tôi đã dùng ping ICMP qua OpenVPN 20:19:23 <i2pr> [Slack/str4d] Thực ra cái này giống một chỉ số hơn, vì nó cũng phụ thuộc vào hiệu năng mạng, và có thể khác nhau tùy vị trí endpoint 20:19:27 <psi> có lẽ không phải cách tốt nhất 20:19:48 <i2pr> [Slack/str4d] Nhưng nếu chúng ta có thể tạo một benchmark lặp lại được, tôi muốn thêm nó vào bộ tôi dự định bắt đầu thu thập 20:20:18 <psi> hiện tôi dùng là: thời gian để kết nối qua DTLS và sau đó đo độ trễ bằng ping 20:20:31 <psi> tôi nghĩ cái đó không port được sang Java I2P 20:20:45 <psi> trừ khi SOCKS5 UDP hoạt động 20:20:49 <psi> hoặc tôi làm vài thứ với SAM 20:21:23 <zzz> còn gì nữa về các tunnel đi ra được căn chỉnh không? 20:21:31 <psi> các tunnel đi ra được căn chỉnh vẫn còn mang tính thử nghiệm và tôi chưa biết việc tăng số lượng tunnel có đáng hay không 20:21:49 <psi> nên cần nghiên cứu thêm và nó đang được nghiên cứu ngay lúc này bên i2pd 20:21:56 <psi> tôi sẽ báo bạn biết 20:22:12 <i2pr> [Slack/str4d] Tuyệt, cập nhật cho tôi về phần khoa học ở #i2p-science :slightly_smiling_face: 20:22:20 <psi> ok 20:22:21 <zzz> tuyệt, cảm ơn cập nhật, psi 20:22:25 <zzz> còn gì nữa về các tunnel đi ra được căn chỉnh không? 20:22:53 <psi> một điều cuối: có thể đáng để làm thêm điều gì đó ngoài việc căn chỉnh các tunnel, tức là thứ gì đó giống rend spec của Tor 20:23:17 <psi> còn đó là gì thì tôi chưa biết và sẽ suy nghĩ to lên trong #i2p-science 20:23:20 <psi> (mời tham gia) 20:23:29 <psi> hết rồi 20:23:41 <i2pr> [Slack/str4d] Tôi hết rồi 20:23:49 <zzz> còn gì nữa cho cuộc họp không? 20:24:28 <psi> tôi ổn 20:25:15 <zzz> cảm ơn mọi người, hẹn gặp lại trong 4 tuần nữa, cũng là thời điểm phát hành .32 20:26:10 * zzz ***bafffs*** xong cuộc họp