I2P डेवलपर बैठक - 25 अप्रैल, 2005

16:12 <jrandom> 0) हाय 16:12 <jrandom> 1) नेट स्थिति और 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) हाय 16:13 * jrandom हाथ हिलाता है 16:13 <@cervantes> नमस्ते 16:13 <jrandom> साप्ताहिक स्थिति नोट्स यहाँ पोस्ट किए गए हैं @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 16:14 <jrandom> जब तक आप सब उसे सरसरी निगाह से देख लें, चलिए 1) नेट स्थिति पर चलते हैं 16:14 <jrandom> तो, जैसा कि आपमें से अधिकतर ने देखा होगा, हमारा नया रिलीज़ आ चुका है, और अब तक नतीजे काफ़ी सकारात्मक हैं 16:15 <@cervantes> (वाह!) 16:15 <jrandom> अभी भी जहाँ हमें होना चाहिए वहाँ नहीं पहुँचे हैं, लेकिन इसने लगभग वे मुख्य समस्याएँ सुलझा दी हैं जो हम देख रहे थे 16:15 <jrandom> हाँ, 2+ hop tunnels पर फिर से ठीक-ठाक tunnel build rates होना अच्छा है :) 16:16 * jrandom को 1hop tunnels के साथ एक दूसरे router पर 50%+ सफलता दर मिल रही है 16:17 <jrandom> मुझे लगता है 0.6.1.17 में हुई हाल की कुछ बदलाव भविष्य में इस तरह के congestion collapse (नेटवर्क जाम के कारण ढहना) से बचने में भी मदद करेंगे 16:17 <jrandom> उपयोगकर्ता को दिखने वाला परिणाम यह होगा कि कभी-कभी lease समाप्तियाँ दिखेंगी, लेकिन अपने आप बढ़ने के बजाय, यह back off कर लेगा 16:17 * cervantes azureus चालू करता है 16:18 <+Complication> आज सुबह, मैंने client tunnel (length 2 +/- 1) की सफलता दर लगभग 35% दर्ज की 16:18 <+Complication> अभी यह कम है, क्योंकि मैंने कुछ संशोधन करने की कोशिश की, और उन में से नवीनतम इतना अच्छा नहीं था :D 16:18 <@cervantes> jrandom: उसे ढूँढ निकालने के लिए बढ़िया काम - एक पल के लिए हम freenet जैसे दिखने लगे थे :) 16:19 <jrandom> *cough* ;) 16:20 <+fox> <inkeystring> jrandom: क्या आप backoff mechanism (बैकऑफ तंत्र) का संक्षेप में वर्णन करेंगे? मैं अभी freenet 0.7 के लिए कुछ वैसा ही बना रहा हूँ 16:21 <jrandom> inkeystring: हमने transport layer backoff mechanism लगाया हुआ था ताकि transport layer के overloaded होने पर किसी peer को भेजी जाने वाली transmissions कम की जा सकें, लेकिन वह पर्याप्त नहीं था 16:21 <@cervantes> *cough* मैंने freenet कहा? मेरा मतलब tor था 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: नया बदलाव यह था कि उसे एक ऊपरी स्तर तक प्रसारित किया जाए ताकि जब हमारा कम्युनिकेशन लेयर saturated हो, तो हम tunnels बनाना कोशिश करना बंद कर दें 16:22 <jrandom> (अधिक tunnel build प्रयास भेजने के बजाय) 16:22 <+fox> <inkeystring> धन्यवाद - क्या transport layer केवल तब back off करता है जब packets खो जाएँ, या receiver के पास flow नियंत्रित करने का कोई तरीका है? 16:23 * jrandom को याद पड़ता है कि toad के साथ congestion बनाम routing के प्रभाव पर कुछ बार चर्चा हुई थी (irc पर और मेरे पुराने flog पर), हालांकि मुझे कोई net-positive समाधान याद नहीं :/ 16:23 <jrandom> receiver NACK कर सकता है, और हमारे पास ECN के लिए hooks हैं, लेकिन उनकी ज़रूरत नहीं पड़ी 16:23 <+fox> <inkeystring> हाँ यह बहस freenet-dev पर फिर उठी है :-) अभी भी कोई जादुई समाधान नहीं 16:24 <+fox> <inkeystring> बढ़िया, जानकारी के लिए धन्यवाद 16:24 <+Complication> वे लोग आजकल UDP भी इस्तेमाल कर रहे हैं, है ना? 16:24 <jrandom> अभी, बहुत अधिक congested peers को दिक्कत per-peer throttling से नहीं, बल्कि peer comm के विस्तार से है 16:24 <+Complication> (transport protocol के रूप में) 16:24 <+fox> <inkeystring> breadth = peers की संख्या? 16:24 <jrandom> हाँ 16:25 <jrandom> बढ़ी हुई tunnel success rates के साथ, peers को सिर्फ एक tunnel बनाने के लिए सैकड़ों peers से बात करने की ज़रूरत नहीं रह जाती 16:25 <jrandom> तो वे सिर्फ 20-30 peers के साथ काम चला सकते हैं 16:25 <jrandom> (मेरा मतलब सीधे जुड़े peers) 16:26 <+fox> <inkeystring> मेरा ख्याल है यह NAT hole punching, keepalives आदि के लिए अच्छी खबर है? 16:26 <jrandom> दूसरी ओर, 2-300 सक्रिय SSU connections के साथ, 6KBps लिंक को दिक्कत होगी 16:26 <jrandom> हाँ 16:26 <+fox> <inkeystring> Complication: हाँ 16:27 <+fox> <inkeystring> (0.7 alpha में) 16:27 <+Complication> आहा, तो संभवतः वे भी कुछ मिलती-जुलती चीज़ों का सामना कर रहे हैं 16:27 <+Complication> आशा है कोई जादुई हल मिल जाए :D 16:27 <jrandom> हालाँकि अलग तरीके से। transport layer अपेक्षाकृत आसान मुद्दा है 16:27 <+fox> <inkeystring> मुझे लगता है उन्होंने कुछ SSU कोड दोबारा इस्तेमाल किया होगा... या कम से कम उन्होंने उसके बारे में बात की थी 16:27 <jrandom> (यानी 30+ साल से अच्छी तरह अध्ययन किया गया) 16:28 <jrandom> पर i2p (और freenet) में load balancing point-to-point links से ऊँचे स्तर पर काम करता है, और उसकी आवश्यकताएँ अलग हैं 16:28 <+fox> <inkeystring> हाँ, routing के साथ अंत:क्रिया ही पेचीदा है 16:29 <jrandom> हाँ, हालांकि i2p के लिए यह आसान है (हमें उस डेटा वाले विशेष peers नहीं ढूँढने होते, बस कोई भी जिसके पास हमारे tunnels में भाग लेने की क्षमता हो) 16:30 <+fox> <inkeystring> तो यदि आप एक overloaded peer से बचते हैं तो दक्षता का कोई नुकसान नहीं... 16:30 <+fox> <inkeystring> जबकि freenet में, एक overloaded peer के चारों ओर routing करने से path length बढ़ सकती है 16:30 <+fox> <inkeystring> खैर, माफ़ कीजिए ये OT हो गया 16:31 <jrandom> कोई बात नहीं, हालांकि यह समझाना कि 0.6.1.17 में बदलाव हमारे congestion collapse को क्यों प्रभावित करते हैं, प्रासंगिक था :) 16:31 <jrandom> ठीक है, 1) नेट स्थिति के लिए क्या किसी और के पास कुछ है? 16:32 <+Complication> अच्छा, जैसा पहले बताया, सिर्फ .17 चलाते हुए, मैंने bandwidth और सक्रिय peers में उल्लेखनीय आवधिकता देखी 16:32 <+Complication> और कुछ अन्य लोगों को भी यह अनुभव हुआ लगता है, हालांकि यह कितना सामान्य है इसका मुझे अंदाज़ा नहीं 16:33 <+Complication> मैं इसके मुख्य कारणों पर सोच रहा था, खासकर tunnel throttling के दृष्टिकोण से, पर अभी कोई समाधान नहीं 16:33 <+Complication> मैंने अपने ग्राफ़ कुछ सपाट दिखाने में सफलता पाई, लेकिन इसकी कीमत कुछ समग्र गिरावट के रूप में चुकानी पड़ी 16:33 <+Complication> ऐसे संशोधन आज़माए जैसे: 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (यह इसलिए था कि वह अपनी ही tunnels के लिए build attempts पूरी तरह से न रोके) 16:35 <jrandom> अच्छा, सही 16:35 <+Complication> (ओह, और स्वाभाविक रूप से loglevel अटपटा है, क्योंकि मैंने परीक्षण के लिए उन्हें बदल दिया था) 16:35 <jrandom> हमारे पास वहाँ कुछ कोड है जो periodicity को थोड़ा skew करने की कोशिश करता है, लेकिन वह ठीक से काम नहीं कर रहा (जाहिर है) 16:36 * perv ने अभी अपने सिस्टम का सत्यानाश कर दिया :( 16:36 <+Complication> लेकिन मैंने ऐसे कुछ काम किए, और tunnel counts के growth factor को घटाने की भी कोशिश की 16:36 <perv> reiser4 के लिए कोई undelete है क्या? 16:36 <jrandom> मूलतः, यदि हम ऐसे व्यवहार करें मानो tunnels वास्तव में जितनी जल्दी expire नहीं होतीं उससे पहले (randomly) expire हो जाती हैं, तो इससे मदद मिलनी चाहिए 16:36 <+Complication> अभी TunnelPool.java की बड़ी "countHowManyToBuild" फ़ंक्शन पढ़ रहा हूँ :D 16:36 <+Complication> लेकिन अभी इसे पूरी तरह नहीं पढ़ा है 16:37 <jrandom> (हालाँकि इससे स्पष्ट रूप से tunnel build frequency बढ़ेगी, जो 0.6.1.17 से पहले उचित नहीं होती) 16:37 <+Complication> perv: कुछ है 16:37 <jrandom> ह्म्म, वहाँ randomization डालना मुश्किल होगा Complication, क्योंकि हम उस फ़ंक्शन को काफ़ी बार बुलाते हैं 16:38 * perv रिकवरी कर gentoo पर स्विच करने पर विचार करता है 16:38 <jrandom> मेरा सुझाव होगा कि सफलतापूर्वक बनी tunnels के expiration time को randomize करने पर नज़र डालें 16:38 <+Complication> perv: निश्चित रूप से reiser, ext3 से बेहतर रहेगा 16:38 <+Complication> perv: लेकिन मुझे यह कंठस्थ नहीं 16:38 <+Complication> jrandom: सही, कभी-कभी इस तरह overbuild हो सकता है 16:38 <jrandom> (ताकि मौजूदा countHowManyToBuild को लगे कि उन्हें पहले ही ज़रूरत है, असल में होने से पहले) 16:38 <+Complication> (और कभी-कभी यह अनिवार्य रूप से overbuild कर देता है, जब tunnels टूटती हैं और यह उतावला हो जाता है) 16:40 <+Complication> ह्म्म, एक संभावना जिसके बारे में मैंने नहीं सोचा... 16:41 <+Complication> किसी भी तरह, मैं भी इसके साथ खेल रहा हूँ, पर अभी कोई उपयोगी निष्कर्ष नहीं 16:42 <jrandom> ठीक है, मैंने भी कुछ tweaks उस पर आज़माए हैं, शायद हम उन्हें अगले build में साथ ला सकें ताकि देख सकें कि यह reasonably-viable net पर कैसा काम करता है ;) 16:43 <spinky> क्या कोई ऐसा stat है जहाँ आप देख सकें कि i2p network एप्लिकेशन डेटा में कितना overhead जोड़ता है? 16:43 <jrandom> "overhead" इतना loaded शब्द है... ;) 16:43 <jrandom> हम इसे anonymity की cost कहते हैं ;) 16:43 <spinky> हेहे 16:45 <jrandom> (यानी, वास्तव में नहीं। perfect net पर 0 congestion और 1+1 hops के साथ application layer payload को endpoints के लिए लगभग 70-80% efficiency मिलती है) 16:45 <jrandom> ((आखिरी बार मैंने मापा था)) 16:45 <jrandom> लेकिन वह वाक़ई लैब परिस्थितियाँ हैं 16:45 <jrandom> live net कहीं अधिक जटिल है 16:47 <spinky> ठीक, मेरा मतलब केवल वह अतिरिक्त डेटा था जो tunnels, keys, padding आदि सेट करने में लगता है 16:47 <spinky> ...स्थानांतरित किए गए एप्लिकेशन डेटा की तुलना में 16:47 <jrandom> यह message framing, congestion, tunnel build success rates आदि पर निर्भर करता है 16:48 <jrandom> 2 hop का tunnel नेटवर्क द्वारा 20KB वहन करके बनाया जा सकता है 16:48 <+Complication> मैंने इसे कई बार परखना चाहा है, मुख्यतः BitTorrent और I2Phex जैसी mass transfer applications की "wastefulness" का अनुमान लगाने के उद्देश्य से 16:48 <+Complication> लेकिन मैं कभी अपनी दो nodes के बीच एक साफ़-सुथरा मापन कर ही नहीं पाया 16:48 <+Complication> कभी न कभी, मैं उस पर वापस आऊँगा, फिर भी 16:49 <jrandom> Complication: chatty apps के साथ यह काफ़ी कठिन है, wget को मापना कहीं सरल है :) 16:49 <+Complication> एकदम सही 16:50 <+Complication> जो कुछ मैं आज़मा सका, उसमें परिशुद्धता का नामोनिशान नहीं था 16:54 <jrandom> ठीक है, अगर 1) पर और कुछ नहीं है, तो 2) I2Phex पर चलते हैं 16:55 <jrandom> Complication: क्या कर रहे हो? :) 16:55 <+Complication> अच्छा, कल का commit मेरे silly first-run detector से कुछ लोगों को हो रही कुछ समस्याओं का सुधार था 16:56 <+Complication> अब first-run detector कम silly है, और bar ने बताया कि यह सामान्य रूप से व्यवहार करने लगा प्रतीत होता है 16:56 <+Complication> हालाँकि, मौजूदा नेटवर्क परिस्थितियों में I2Phex पहले से ही चलने योग्य लगता है, 16:56 <+Complication> मैं rehash बग को भी ढूँढने की कोशिश करूँगा 16:57 <+Complication> अगर मैं कर पाया तो 16:57 <jrandom> अच्छा, मैं जानता हूँ वह वाला महीनों से तुम्हें सताता रहा है 16:57 <+Complication> दिलचस्प यह है कि mainline Phex में भी यह हो सकता है, और उनके अवलोकनों को ढूँढना + पढ़ना भी मैं करने की कोशिश करूँगा 16:58 <jrandom> पर अच्छा लगा सुनकर कि startup फिक्स उसमें आ गया है 16:58 <jrandom> अच्छा, बढ़िया 16:58 <+Complication> =यही कि 16:58 <+Complication> मैं अभी यह पुष्टि नहीं कर सकता कि mainline Phex में यह है या नहीं - मैंने वहाँ व्यक्तिगत रूप से इसे कभी नहीं देखा 16:59 <jrandom> (रुक-रुक कर आने वाले बग्स)-- 16:59 <+Complication> इसे नियंत्रित तरीके से पैदा करना मुश्किल है, और इसलिए इसे ढूँढना भी कठिन है 17:00 <+Complication> और मेरी तरफ़ से, फिलहाल बस इतना ही 17:00 <+Complication> आगे चलकर, मैं सोच रहा था कि एक समय में I2Phex द्वारा दागे जाने वाले parallel peer contacting attempts की संख्या सीमित करना उपयोगी होगा या नहीं 17:01 <jrandom> हाँ, संभवतः 17:01 <+Complication> क्योंकि वे थोड़े समय में बहुत सारे NetDB lookups पैदा करेंगे, और यह I2P router के दृष्टिकोण से शायद अच्छा नहीं होगा 17:02 <jrandom> और नए destination contacts के लिए aes की जगह elG की ज़रूरत होती है 17:02 <+Complication> लेकिन मैंने उस लक्ष्य की ओर कोई वास्तविक कोड अभी न पढ़ा है, न लिखा है 17:04 <jrandom> ठीक है, कोई बात नहीं। शायद काल्पनिक i2phex/phex मर्ज समाधान बाँध दे :) 17:04 <+Complication> और मेरी ओर से, I2Phex फ्रंट से बस इतनी ही खबरें... 17:04 <jrandom> अच्छा, अपडेट और चीज़ों को देखने के प्रयास के लिए धन्यवाद! 17:05 <jrandom> ठीक है, चलिए 3) ??? पर चलते हैं 17:05 <jrandom> क्या बैठक में उठाने के लिए किसी के पास और कुछ है? 17:05 <lsmith> हैलो! मैं बस नवीनतम रिलीज़ में शानदार सुधारों के लिए devs की सराहना करना चाहता हूँ, मेरा कुल bw 0.9/1.4 KBps दिखा रहा है और मैं irc से जुड़ा रहा हूँ... यह... बेहद कमाल है :) 17:05 <+Complication> :D 17:06 <jrandom> रास्ते भर धैर्य रखने के लिए धन्यवाद - low bw यूज़र्स का समर्थन करना बहुत महत्वपूर्ण है 17:06 <@cervantes> lsmith: यह वाक़ई अच्छा है 17:06 <@cervantes> * Connection Reset 17:06 <jrandom> हेह 17:07 <lsmith> :) 17:09 <jrandom> ओह, एक और उल्लेखनीय बात यह है कि zzz वापस आ गया है, और उसके साथ stats.i2p भी आ गया :) 17:09 <jrandom> [wewt] 17:11 <+Complication> तुलनात्मक डेटा के लिए काफ़ी उपयोगी स्रोत :) 17:11 <jrandom> बिल्कुल 17:11 <jrandom> ठीक है, बैठक के लिए किसी और के पास कुछ है? 17:13 <jrandom> अगर नहीं... 17:13 <jdot> मेरे पास post-baf एक-दो प्रश्न हैं 17:13 <jrandom> हेह ठीक है, तो चलिए baffer को चालू करते हैं :) 17:13 * jrandom तैयारी करता है... 17:13 * jrandom *baf*s के साथ बैठक समाप्त करता है