I2P डेवलपर बैठक - 09 अगस्त, 2005

13:11 <jrandom2p> 0) हाय 13:11 <jrandom2p> 1) 0.6.0.2 13:11 <jrandom2p> 2) रोडमैप अपडेट 13:11 <jrandom2p> 3) ??? 13:11 <jrandom2p> 0) हाय 13:11 * jrandom2p हाथ हिलाता है 13:11 <+detonate> हाय 13:11 <jrandom2p> साप्ताहिक स्थिति नोट्स यहाँ हैं @ http://dev.i2p.net/pipermail/i2p/2005-August/000839.html 13:12 <jrandom2p> ठीक है, freeforall से पहले थोड़ी देर के लिए [1-2] पर कूद रहा हूँ.. 13:12 <jrandom2p> 1) 0.6.0.2 13:12 <jrandom2p> यह जारी हो गया है. और वगैरह 13:12 <jrandom2p> क्या किसी के पास 0.6.0.2 को लेकर कोई सवाल/टिप्पणियाँ/चिंताएँ हैं? 13:13 <jrandom2p> अगर नहीं, तो 2) रोडमैप अपडेट पर चलते हैं 13:13 <jrandom2p> वो, उhm, रोडमैप अपडेट कर दिया गया है. और वगैरह ;) 13:14 <duck> तुम ऑसी हो 13:14 <+bla> jrandom: अभी भी किसी destination से संपर्क करने में रुक-रुक कर समस्याएँ आती हैं, भले ही वह सामान्यतः up हो 13:14 * postman भी इसका समर्थन करता है 13:14 * detonate भी सहमत है 13:14 <+bla> jrandom: जैसे, forum.i2p ठीक चलता है, फिर कुछ मिनट बाद नहीं चलता, और कई बार रीलोड करना पड़ता है 13:15 * bla ने इसे सबसे पहले कहा ;) 13:15 <jrandom2p> हम्म, हाँ, इसके बारे में रिपोर्ट्स सुनी हैं. 0.6.0.2 के साथ भी, सही? 13:16 <+postman> जी हाँ, सर 13:16 <+bla> हाँ, 0.6.0.2 13:16 <+bla> हो सकता है netDb की दिक्कत हो, या tunnels में डालने के लिए peers (समकक्ष) का चयन खराब हो (या कुछ और) 13:16 <jrandom2p> ठीक 13:17 <jrandom2p> हाल ही में tunnel peer selection काफ़ी खराब रहा है, जैसे netDb store flooding भी 13:17 <jrandom2p> (tunnel request failure counts देखने के लिए अपना /oldstats.jsp देखें) 13:18 <+bla> अब जब हम UDP/SSU इस्तेमाल करते हैं, peer classification पहले से बेहतर लगता है: कई peers जिन्हें मैं _तेज़_ जानता हूँ, आमतौर पर profile pafe के "fast" सेक्शन में दिखते हैं 13:19 <jrandom2p> अच्छा 13:19 <jrandom2p> 0.6.0.2 ने netDb के आधार पर कुछ tunnel rejection code जोड़ा है जो उसे पहले करना चाहिए था (अगर हम next hop नहीं ढूँढ पाते तो जुड़ने से मना करना), तो rejections में बढ़ोतरी अपेक्षित है 13:19 <+bla> हालांकि मुझे वाकई classification algorithms पर फिर से काम शुरू करना चाहिए... ;) 13:20 <jrandom2p> मैं profile/stat analysis कर रहा हूँ, लेकिन अभी ठोस नतीजे नहीं हैं 13:21 <jrandom> वह बढ़िया होगा, bla :) 13:25 <jrandom2p> ठीक है, 2) roadmpa update पर और कुछ? :) 13:26 <jrandom2p> अगर नहीं, तो 3) ??? पर चलते हैं 13:26 <+detonate> क्या आपको लगता है कि mode की तुलना में जिनके failure/duprecv rates बहुत ऊँचे हैं, ऐसे peers को ब्लैकलिस्ट (काली सूची) करना उपयोगी होगा? 13:27 <jrandom> हम्म, मैं उसके बारे में निश्चित नहीं हूँ - अगर failure/dup rates उपयोगी होने के लिए बहुत ज़्यादा हैं, तो हमें बस धीरे और सावधानी से transfer करना चाहिए 13:27 <jrandom> जब तक संदेश पहुँच रहे हैं, तब तक संदेश पहुँच रहे हैं 13:28 <jrandom> एक कारण है कि हमने अपनी प्रोफाइलिंग के हिस्से के रूप में direct peer communication पर stats का इस्तेमाल नहीं किया है - उन पर निर्भर होना हमें कुछ आसान और शक्तिशाली हमलों के प्रति असुरक्षित बना देगा (अलग-अलग peers के साथ अलग तरह से पेश आना और देखना कि कौन तुम्हारा उपयोग करता है, आदि) 13:29 <+detonate> हम्म 13:29 <+detonate> ठीक है 13:29 <jrandom> पर शायद हमें ऐसे peers के लिए sessions ड्रॉप करने की ज़रूरत है जो इतनी भीड़भाड़ वाली cons में हों 13:29 <+detonate> उचित बात 13:34 <jrandom> ठीक है, 3) ??? के लिए किसी और के पास कुछ उठाने को है? 13:34 <luckypunk> ओ, ओह, शायद आपको इंतज़ार करना चाहिए जब तक सब लौट नहीं आते 13:34 <luckypunk> महत्त्वपूर्ण सवाल पूछने से पहले :P 13:35 <jrandom2p> बह, उनके पास mailing list है ;) 13:35 <luckypunk> ठीक है 13:35 <luckypunk> मेरा खयाल है शिकायत करने के लिए यही सही जगह है 13:36 <luckypunk> I2P अभी भी थोड़ा-सा CPU इस्तेमाल करता है 13:36 <luckypunk> लेकिन पहले जितना नहीं 13:36 <luckypunk> सही है, मैंने 5.0 के दिनों से इसे चलाया नहीं है 13:36 <luckypunk> पर हाँ 13:36 <luckypunk> अ.. 13:36 <luckypunk> 0.5.0 13:36 <jrandom2p> बढ़िया, तुम्हारी कौन-सी मशीनें इसके साथ काम करती हैं? 13:36 <luckypunk> अ.. 13:36 <luckypunk> यार 13:36 <luckypunk> मैंने 0.6.0.0 के बाद से इसे इस्तेमाल नहीं किया है 13:36 <luckypunk> यह Pentium 2 पर ठीक काम करता है 13:37 <luckypunk> default nice value का मतलब है कि अगर मैं बहुत देर तक कोई बहुत CPU-इंटेंसिव काम करता हूँ, तो यह क्रैश होने लगता है क्योंकि I2P CPU से वंचित (CPU starved) हो जाता है 13:38 <+detonate> हम्म, मेरा खयाल है router console network config में एक जगह हो सकती है जहाँ user की पसंद हो तो introducers (फायरवॉल्ड peers के लिए परिचय कराने वाले रिले) को hardwire किया जा सके, जब introducers हों 13:39 <jrandom2p> क्या तुम अभी 0.6.0.2 पर हो, luckypunk? 13:39 <@smeghead> detonate: वह trusted route वाली चीज़ है... रोडमैप में आगे :) 13:39 <luckypunk> नहीं 13:39 <luckypunk> मैंने 0.6.0.0 के बाद से इसे चलाया नहीं है 13:39 <@smeghead> *restricted route 13:40 <luckypunk> लेकिन इसका CPU उपयोग काफ़ी कम लगा। 13:40 <+detonate> हेह, जैसे ही introducers होंगे, उसे वहाँ होना चाहिए :) 13:40 <jrandom2p> आ हाँ detonate, introducer selection निश्चित ही configurable हो सकता है, पर वह शायद एक hidden advanced config option होगा ;) 13:41 <jrandom2p> luckypunk: 0.6.0.1 ने बहुत सा crypto निकाल दिया, और 0.6.0.2 और मदद करेगा. कभी आज़माओ, शायद यह बेहतर हैंडल करे 13:41 <luckypunk> ठीक है 13:41 <@smeghead> अगर कोई introducer नहीं चाहता कि आप हर समय उसे चुनें, तो क्या? 13:41 <luckypunk> मुझे लगता है अब I2P एक dedicated mid-range Pentium पर चलेगा। 13:41 <jrandom> smeghead: तब वे कहेंगे "दफ़ा हो जाओ, मैं तुम्हारे लिए introducer बनने वाला नहीं हूँ" 13:42 <jrandom> और peers के पास अनेक introducers होंगे, तो यह संतुलित रहेगा 13:42 <jrandom> (और एक नए peer को wire up करने में केवल 2 packets लगते हैं, सारे packets नहीं) 13:44 <+detonate> अगर introducers अलग तरह से काम करते, तो आप उनके बीच majority vote कर सकते थे यह तय करने के लिए कि कौन-से काम कर रहे हैं, पर अभी की स्थिति में उसका कोई मतलब नहीं 13:45 <ant> <jme___> प्र: इस voting system का विवरण मुझे कहाँ मिल सकता है? 13:45 <jrandom> majority का कोई मतलब नहीं बनता 13:45 * jrandom को मतदान पर उतना ही भरोसा है जितना मैं उसे फेंक सकता हूँ 13:45 <jrandom> (खासकर Sybil के संदर्भ में) 13:45 <jrandom> कोई introducer तभी काम कर रहा है जब कोई नया peer उसके ज़रिए आपसे संपर्क कर सके 13:47 <+detonate> vanguard की स्थिति क्या है, कुछ-कुछ इससे संबंधित है 13:47 <+detonate> जबकि smeghead मौजूद है 13:51 <jrandom> ठीक है, अगर और कुछ नहीं है... 13:51 * jrandom समेटता है 13:51 * jrandom *baf* के साथ बैठक समाप्त करता है