I2P डेवलपर बैठक - 05 सितंबर, 2017

20:00:00 <zzz> 0) हाय 20:00:00 <zzz> 1) 0.9.32 अपडेट (zzz) 20:00:00 <zzz> 2) 34C3 फंडिंग ईमेल रिमाइंडर (zzz/echelon) 20:00:03 <zzz> 0) हाय 20:00:05 <zzz> हाय 20:00:44 <zzz> 1) 0.9.32 अपडेट (zzz) 20:00:58 <R4SAS> हाय 20:01:09 <zzz> ठीक है, str4d ने कुछ UI अपडेट किए हैं, और मैंने prop 141 के इम्प्लीमेंटेशन पर काम शुरू कर दिया है लेकिन अभी तक कुछ भी चेक-इन नहीं किया है 20:01:37 <zzz> हम अक्टूबर की शुरुआत में रिलीज़ के लिए ट्रैक पर हैं 20:01:49 <i2pr> [Slack/str4d] हाय 20:02:03 <zzz> मुझे लगता है str4d अपनी बेंचमार्क ब्रांच को prop करना चाहता है, उसे यह जल्द करना चाहिए? मैंने उसके टिकट पर टिप्पणी की है 20:02:20 <psi_> हाँ 20:02:36 <i2pr> [Slack/str4d] अब तक मैंने केवल एक मामूली UI परिवर्तन पुश किया है; मेरे पास लोकली और भी बदलाव हैं जो कई और मुद्दों को संबोधित करते हैं, लेकिन मुझे अपने git -> mtn प्रोसेस से गुजरना होगा 20:03:09 <i2pr> [Slack/str4d] मैं बेंचमार्क टिप्पणियाँ देखूंगा और इसे इस हफ्ते के अंत तक पूरा/पुश कर दूंगा 20:03:57 <zzz> ठीक है, मुझे किसी समय आपसे हमारे रिलीज़ प्रोसेस के बारे में बात करनी है। .31 के लिए हमारे पास कुछ ब्लॉकर टिकट थे जो बंद नहीं हुए थे, शायद हमें इस पर जोर देना चाहिए कि रिलीज़ से पहले वे बंद हों 20:04:08 <zzz> वरना फिर ब्लॉकर का मतलब ही क्या है 20:04:23 <i2pr> [Slack/str4d] सही 20:04:36 <zzz> 1) पर और कुछ? 20:06:01 <zzz> 2) 34C3 फंडिंग ईमेल रिमाइंडर (zzz/echelon) 20:06:11 <psi> क्या इस रिलीज़ में होस्टनेम्स हटाने की ज़रूरत है? 20:06:15 <psi> RI में 20:06:25 <psi> उफ़, लैग 20:06:33 <zzz> माइग्रेशन चर्चा के लिए प्रस्ताव के पाठ को देखें 20:06:45 <psi> kk 20:07:07 <i2pr> [Slack/str4d] ज़ॉम्बी शमन पर चर्चा के बिना इसे इस रिलीज़ में रखने पर -1 20:07:08 <zzz> ठीक है 34C3 के संदर्भ में, अगर आपको फंडिंग या फ्री टिकट चाहिए तो आपको 30 सितम्बर तक echelon को ईमेल करना ही होगा 20:07:43 <zzz> इसके अलावा, echelon के कुछ सर्वर इश्यूज़ थे, तो अगर आपको उनसे यह ACK (प्राप्ति-पुष्टि) नहीं मिला कि उन्हें आपका ईमेल मिला है, तो इसे फिर से भेजें 20:08:46 <zzz> हमारे पास लोगों के लिए पर्याप्त फंड उपलब्ध हैं लेकिन आपको अनुरोध करना होगा। महीने के अंत के बाद अनुरोध करने वालों को हम फंड नहीं करेंगे 20:09:48 <zzz> तो फिर से सुनिश्चित करें कि echelon ने आपके अनुरोध की रसीद की पुष्टि की है 20:10:03 <zzz> हम अगले महीने की बैठक में बजट तय करेंगे 20:10:19 <zzz> 2) पर और कुछ? 20:10:36 <i2pr> [Slack/str4d] मेरी तरफ से नहीं। 20:11:26 <zzz> बैठक के लिए और कुछ? 20:11:54 <psi> मेरे पास कुछ है 20:12:02 <zzz> psi बोलो 20:12:03 <psi> लेकिन यह लंबा और उबाऊ है 20:12:09 <psi> वह aligned outbound tunnels वाला आइडिया है 20:12:36 <psi> शुरू में मैंने इसे आपको OBEP (आउटबाउंड एंडपॉइंट) लोड रिडक्शन तकनीक के रूप में समझाया था 20:12:45 <psi> वह एक अच्छा साइड-इफ़ेक्ट है 20:12:53 <psi> पर वह मूल उद्देश्य नहीं था 20:13:10 <psi> मूल उद्देश्य पैकेट ड्रॉप को कम करना था 20:13:59 <zzz> ठीक है, तो आप इसके बारे में क्या चर्चा करना चाहेंगे? 20:14:08 <psi> मेरा सवाल है: क्या Java I2P aligned outbound tunnels को इम्प्लीमेंट करेगा? 20:14:22 <psi> या यह आपके लिए बहुत प्रयोगात्मक है? 20:14:53 <psi> मैं Java I2P के कोड से उतना परिचित नहीं हूँ जितना i2pd से हूँ 20:14:57 <zzz> अभी जवाब नहीं दे सकता क्योंकि मैं विवरण भूल गया हूँ। अगर आप इसे लिखकर कहीं पोस्ट कर दें तो मैं खुशी से आपको जवाब दूँगा 20:15:09 <psi> ठीक है 20:15:15 <psi> मेरा ख्याल है आप मीट बंद कर सकते हैं 20:15:26 <psi> आइडिया यह है कि OBEP == IBGW (इनबाउंड गेटवे) 20:15:35 <psi> OB tunnel पर एक अतिरिक्त हॉप के साथ 20:15:38 <eche|offf> अब तक मेरी तरफ से कुछ नहीं 20:15:43 <psi> ताकि OBEP == IBGW 20:16:14 <psi> पैकेट ड्रॉप और OBEP प्रेशर कम करने के लिए 20:16:30 <psi> (और अधिक tunnels की कीमत पर) 20:16:51 <zzz> ठीक है, चूँकि आपने इसे पहले ही इम्प्लीमेंट कर दिया है, फायदे पर कोई डेटा बहुत सहायक होगा 20:17:10 <zzz> aligned outbound tunnels पर और कुछ? 20:17:31 <psi> मेरे शुरुआती अवलोकन यह हैं कि शुरुआती RTT (राउंड-ट्रिप टाइम) बाद के समान ही होता है 20:17:44 <psi> यानि, शुरुआती RTT स्पाइक नहीं होता 20:17:57 <psi> संभवतः OBEP पर प्रेशर कम होने के कारण 20:18:03 <psi> पर यह सिर्फ एक अनुमान है 20:18:15 <psi> मैं इसे एक टेस्टनेट पर टेस्ट करना चाहता हूँ, जो हमारे पास docker के साथ है। 20:18:25 <i2pr> [Slack/str4d] अगर इसे किसी performance benchmark में बदला जा सकता है, LMK (बताइए) 20:18:25 <psi> ताकि ठोस आँकड़े इकट्ठा किए जा सकें आदि 20:19:01 <psi> हाँ, यहाँ भी वही, मैं एक अच्छे perf benchmark के लिए उलझन में हूँ 20:19:18 <psi> मैं openvpn पर icmp ping का उपयोग कर रहा हूँ 20:19:23 <i2pr> [Slack/str4d] दरअसल यह बेंचमार्क से ज्यादा एक metric होगा, क्योंकि यह नेटवर्क परफॉर्मेंस पर भी निर्भर करेगा, और endpoint लोकेशन्स पर निर्भर करते हुए अलग हो सकता है 20:19:27 <psi> शायद यह सबसे अच्छा तरीका नहीं है 20:19:48 <i2pr> [Slack/str4d] लेकिन अगर हम *कर* पाते हैं एक रिपीटेबल बेंचमार्क, तो मैं उसे उस सूट में जोड़ना चाहूँगा जिसे मैं इकट्ठा करना शुरू करने की योजना बना रहा हूँ 20:20:18 <psi> अभी मैं जो उपयोग करता हूँ वह है: DTLS के ज़रिए कनेक्ट होने में लगने वाला समय, और फिर ping के ज़रिए आगे की लैटेंसी माप 20:20:31 <psi> मुझे लगता है यह Java I2P के लिए पोर्टेबल नहीं है 20:20:45 <psi> जब तक कि socks5 udp काम न करे 20:20:49 <psi> या मैं कुछ SAM वाली चीज़ें करूँ 20:21:23 <zzz> aligned outbound tunnels पर और कुछ? 20:21:31 <psi> aligned outbound tunnels अभी भी प्रयोगात्मक हैं और मुझे नहीं पता कि बढ़ी हुई tunnel संख्या इसके लायक है या नहीं 20:21:49 <psi> तो और रिसर्च की ज़रूरत है और i2pd पर इस पर अभी रिसर्च हो रही है 20:21:56 <psi> मैं आपको बताऊँगा 20:22:12 <i2pr> [Slack/str4d] बढ़िया, #i2p-science में होती साइंस से मुझे अवगत कराते रहें :slightly_smiling_face: 20:22:20 <psi> kk 20:22:21 <zzz> बहुत बढ़िया, अपडेट के लिए धन्यवाद psi 20:22:25 <zzz> aligned outbound tunnels पर और कुछ? 20:22:53 <psi> एक आख़िरी बात: tunnels को align करने के अलावा कुछ और करना सार्थक हो सकता है, यानी Tor's rend spec जैसा कुछ 20:23:17 <psi> जहाँ तक कि वह क्या है, मुझे नहीं पता और मैं इसके बारे में #i2p-science में खुलकर सोचूँगा 20:23:20 <psi> (कृपया जुड़ें) 20:23:29 <psi> बस इतना ही 20:23:41 <i2pr> [Slack/str4d] मेरी तरफ से बस इतना ही 20:23:49 <zzz> बैठक के लिए और कुछ? 20:24:28 <psi> मेरी तरफ से सब ठीक है 20:25:15 <zzz> धन्यवाद सभी को, 4 हफ्तों में मिलते हैं, जो .32 रिलीज़ का समय होगा 20:26:10 * zzz ***bafffs*** मीटिंग समाप्त