I2P डेवलपर बैठक - 18 मई, 2004

14:07 <jrandom> 0) हाय 14:07 <jrandom> 1) टेस्टनेट स्थिति 14:07 <jrandom> 2) SAM 14:07 <jrandom> 3) रोडमैप अपडेट्स 14:07 <jrandom> 4) MyI2P 14:07 <jrandom> 5) ??? 14:07 <jrandom> 0) हाय 14:07 * jrandom हाथ हिलाता है 14:08 <Nightblade> हाय 14:08 * jteitel वापस हाथ हिलाता है 14:08 <jar> हाय 14:08 <duck> हाय 14:08 <Masterboy> :P 14:08 <jrandom> साप्ताहिक स्थिति नोट्स यहाँ तक पोस्ट किए गए हैं: http://dev.i2p.net/pipermail/i2p/2004-May/000239.html 14:09 <jrandom> माफ़ करें अगर मैं आज थोड़ा सुस्त हूँ, नींद का शेड्यूल सामान्य से भी ज़्यादा बिगड़ा हुआ है 14:09 <jrandom> खैर, 1) टेस्टनेट स्थिति पर आगे बढ़ते हैं 14:10 <duck> बड़ा नेटवर्क होने पर विविधीकरण अपने आप हो जाएगा, है ना? 14:10 <jrandom> हाँ, और/या कम पक्षपाती पीयर चयन थ्रेशोल्ड 14:11 <jrandom> उदाहरण के लिए, अगर स्पीड थ्रेशोल्ड औसत की बजाय माध्य (median) होता, तो हमें भरोसेमंद पीयर्स के मुकाबले तेज़ पीयर्स आधे मिलते 14:11 <jrandom> इसके विपरीत आज की स्थिति में स्पीड काफ़ी असंतुलित है 14:12 <Masterboy> खैर नेटवर्क ठीक हो गया, यह इतना बुरा नहीं है 14:12 <jrandom> हाँ, लेकिन इसमें जितना समय लगना चाहिए था उससे ज़्यादा लगा, और इससे सुधार के तरीक़े भी सामने आए 14:13 <jteitel> क्या नेटवर्क ठीक हो गया? मैं अभी भी i2p IRC से भरोसेमंद तरीक़े से कनेक्ट नहीं कर पा रहा हूँ 14:13 <jrandom> पीयर प्रोफाइल पर्याप्त तेज़ी से कम नहीं हुए, या नए उम्मीदवारों को प्रभावी ढंग से बढ़ावा नहीं दिया 14:14 <jrandom> इससे एक श्रृंखलाबद्ध द्वितीयक घटनाएँ भी ट्रिगर हो गईं - ऐसे routers पर ओवरलोड जो लोड संभालने में सक्षम नहीं थे (अपर्याप्त प्रोफाइलिंग के कारण), जिससे कुछ overloaded routers की मेमोरी खत्म हो गई और वे बंद हो गए 14:15 <human> ayeee ayeee ayeee! 14:15 <jrandom> यह क्रमिक रहा है, jteitel - जो समस्याएँ हम देख रहे हैं, उनमें से कुछ netDb विफलताओं से संबंधित हैं 14:15 <jrandom> हाय human 14:15 <jteitel> ओह, ठीक है 14:16 <_cervantes_> क्या कोई परेशानी में पड़ा router अपने tunnels किसी और पीयर पर ऑफ़लोड नहीं कर सकता? 14:16 <ugha_node> वाह, Lifetime rate: 8.87KBps भेजा 8.35KBps प्राप्त किया। 14:16 <Nightblade> jteitel: मैं अभी कई बार कोशिश के बाद कनेक्ट हुआ हूँ... अभी भी मेरा /join चलने का इंतज़ार कर रहा हूँ 14:16 * BrianR इधर-उधर देखता है। 14:16 <jrandom> नहीं - एक router किसी tunnel को बस ड्रॉप कर सकता है (यदि उसे शुरू में उसे स्वीकार नहीं करना चाहिए था) 14:16 <ugha_node> (और मैंने अपना router आधा घंटा पहले रीस्टार्ट किया था) 14:16 <BrianR> धत्त. मैं देर से आया। 14:17 <BrianR> jrandom: (एजेंडा के अंत की ओर myi2p को रखने के लिए धन्यवाद) 14:17 <jrandom> ugha> हाँ, आप सबको उन तीन तेज़ वालों की कमी पूरी करनी पड़ी 14:17 <jrandom> hehe :) 14:18 <duck> यह एक बढ़िया अटैक था 14:18 <ugha_node> jrandom: स्पष्टतः। 14:18 <_cervantes_> तो क्या थोड़ा सख़्त होकर कम थ्रेशोल्ड पर tunnels को अस्वीकार करना बेहतर नहीं होगा 14:19 <jrandom> हाँ cervantes - अभी routers किसी tunnel को तब तक अस्वीकार नहीं करते जब तक वे अगले hop तक पहुँच नहीं सकते 14:19 <jrandom> हमें वहाँ किसी तरह का throttling शामिल करना होगा, शायद jobQueue के आकार / avg lag आदि के आधार पर 14:20 <jrandom> इसके अलावा, हमें यह सुनिश्चित करना होगा कि हम एक साथ बहुत अधिक tunnels बनाने की कोशिश न करें, जैसा कि तब हुआ जब उनमें से बड़े हिस्से विफल हो गए 14:20 <_cervantes_> या बस उपयोगकर्ता को यह अनुमति दें कि वह अपने हार्डवेयर/बैंडविड्थ की उपलब्धता के आधार पर थ्रेशोल्ड सेट करे 14:20 <jrandom> (fast+reliable पीयर्स के ऑफ़लाइन हो जाने के कारण) 14:20 <_cervantes_> कम से कम इस चरण में 14:20 <jrandom> ओह यह अच्छा सुझाव है - लोगों को सहभागी tunnels की अधिकतम संख्या (max #) स्पष्ट रूप से सेट करने देना। 14:21 <jrandom> हम इसे अगली rev में डाल देंगे। बढ़िया सुझावट। 14:21 <ugha_node> यह तो बिल्कुल fuzzy logic जैसा लगता है। 14:21 <jrandom> हमें ओवरलोड से निपटना होगा, और केवल मेमोरी में संदेशों को क्यू करना निश्चित रूप से काम नहीं करता 14:21 <duck> (हाय fvw) 14:21 <_cervantes_> tunnel प्रदर्शन पर किसी प्रकार के संकलित आँकड़े होना अच्छा होगा... ऐसा लोड जो एक benchmark प्रोसेसर(ों) पर पड़ सकता है 14:22 <_cervantes_> वैसे मैंने अपना सर्वर ऑफ़लाइन कर दिया.... उस पर बहुत सारे tunnels आ रहे थे और मैंने अभी तक jbigi कंपाइल नहीं किया है ;-) 14:22 <jrandom> देखें http://localhost:7655/routerStats.html#Tunnels 14:23 <jrandom> आह! हाँ, jbigi वह चीज़ है जिसका इस्तेमाल हम सभी को करने के लिए प्रोत्साहित करना चाहते हैं 14:23 <BrianR> tunnels के लिए बैंडविड्थ बजटिंग पर कोई विचार? 14:24 <jrandom> वर्तमान में 3.0 के लिए अनुसूचित है (router के लिए समग्र बैंडविड्थ लिमिटिंग @ 0.4.1) 14:24 <jrandom> लेकिन per-tunnel बैंडविड्थ सीमाएँ पहले ला देने में हानि नहीं होगी 14:25 <fvw> क्या अभी इस पर मेहनत करना समझदारी है, जब इसे उन OSes के kernel में करना कहीं आसान और अधिक सटीक है जिन पर ज़्यादातर मौजूदा उपयोगकर्ता/परीक्षक चल रहे हैं? 14:25 <_cervantes_> मैं जो देखना चाहूँगा वह है per-tunnel depth सेटिंग्स (शायद यह पहले से संभव है) 14:25 <_cervantes_> उदाहरण के लिए, मुझे पहले से पता है कि मैं अपने सर्वर पर भरोसा कर सकता हूँ.... तो मैं वहाँ तक पहुँचने के लिए _x_ hops से होकर नहीं जाना चाहता 14:25 <jrandom> fvw> यह अच्छा बिंदु है, खासकर क्योंकि फिलहाल हम बहुत अधिक बैंडविड्थ नहीं खा रहे हैं 14:26 <jrandom> हम्म cervantes - हाँ, हर क्लाइंट अपने tunnels की लंबाई निर्दिष्ट कर सकता है, लेकिन मुझे यक़ीन नहीं कि आप यही चाह रहे हैं 14:26 <_cervantes_> नहीं 14:26 <jrandom> cervantes - मेरा खयाल है आप QoS (सेवा गुणवत्ता) चाहते हैं जहाँ आप किसी विशेष पीयर के लिए कनेक्शन छोटा कर सकें 14:26 <_cervantes_> उदाहरण के लिए... 14:26 <_cervantes_> हाँ 14:27 <jrandom> (जिसे i2p 4.0 के लिए तय किया गया था, पर वह एक साल से भी ज़्यादा दूर है == अनंत) 14:27 <_cervantes_> इस स्थिति में प्रति i2p होस्ट depth भी चुनें 14:27 <BrianR> fvw: हाँ, लेकिन एक i2p को समझदारी भरे tunnel-building फ़ैसले लेने के लिए यह मोटे तौर पर पता होना चाहिए कि संभावित tunnel सदस्यों के पास कितनी बैंडविड्थ उपलब्ध है... 14:27 <_cervantes_> आह ठीक 14:27 <_cervantes_> :) 14:27 <jrandom> पर यह अच्छा विचार है, और तकनीकी रूप से संभव भी, पैच स्वीकार हैं :) 14:28 <_cervantes_> पैच तो पहले ही मेल में है.... उसी के साथ 5000 bars of e-gold का चेक भी 14:28 <_cervantes_> ;-) 14:28 <jrandom> BrianR: शायद यह बीच का रास्ता अपना सकता है - यह ट्रैक रखे कि वह कितने tunnels में भाग ले रहा है, साथ ही वे tunnels कितनी बैंडविड्थ उपयोग कर रही हैं, और उसी को इस निर्णय का हिस्सा बनाए कि किसी tunnel create अनुरोध को स्वीकार करना है या अस्वीकार? 14:28 <jrandom> heh 14:30 <jrandom> ठीक है, टेस्टनेट स्थिति पर किसी के पास और कुछ है? 14:30 <Masterboy> मेरे विरोधाभास का क्या? 14:30 <Masterboy> :) 14:30 <jrandom> मेरी योजना है कि गुरुवार या शुक्रवार तक अपडेट्स के साथ 0.3.1.3 जारी कर दूँ 14:31 <jrandom> Masterboy: मुझे तुम्हारे लॉग्स देखने का समय नहीं मिला, पर हम इसे सुलझा लेंगे 14:31 <_cervantes_> शुक्रवार 2005? 14:31 <_cervantes_> कूल 14:31 <Masterboy> k 14:31 <jrandom> ठीक है, 2) SAM पर आगे बढ़ते हैं 14:31 <Masterboy> अब हमें पता है कि पुराना router कौन चला रहा है.. 14:32 * jrandom हमारा निर्भीक SAM.pm dev को mic सौंपता है 14:33 <jrandom> (वह आप हैं BrianR :) 14:33 <BrianR> एक सेकंड रुकें.. :) 14:33 * duck चीयर करता है 14:33 <jrandom> इस बीच, dm या firerabbit आसपास हैं? 14:33 -!- Irssi: #i2p: कुल 26 nicks [0 ops, 0 halfops, 0 voices, 26 normal] 14:33 * jrandom /names चेक करता है, नहीं। खैर 14:33 <jrandom> (.net/C# SAM lib अपडेट्स नहीं, फिर) 14:34 <duck> क्या .py वाली चीज़ अभी भी अप-टू-डेट है? 14:34 <duck> या SAM सुधारों से deprecated हो गई है 14:34 <jrandom> पक्का नहीं 14:34 <BrianR> ठीक है। मैं लौट आया। 14:34 <Nightblade> मेरी C लाइब्रेरी काम करती दिख रही है... हालांकि इसे इस्तेमाल करने के लिए मैंने अभी कोई एप्लिकेशन नहीं लिखी है 14:34 <jrandom> बहुत बढ़िया nightblade! 14:35 <Nightblade> क्या यहाँ किसी ने Windows पर GTK+/C प्रोग्रामिंग की है? 14:35 <human> duck: versioning समर्थन के लिए client lib में एक छोटा बदलाव चाहिए 14:35 <_cervantes_> "hello world"? 14:35 <human> duck: बाकी बिना समस्या काम करना चाहिए 14:35 * jrandom एक tftp जैसे datagram को आदर्श SAM टेस्ट के रूप में सुझाता है :) 14:35 <Nightblade> खैर, कुछ भी... क्या GTK Windows पर अच्छी तरह काम करता है.....? 14:35 <jrandom> (या datagram या raw के बजाय SAM streaming भी) 14:36 <jrandom> कूल BrianR - .pm और samcat कैसा चल रहा है? 14:36 <BrianR> Net::SAM CVS में है, अधिकांशतः non-working रूप में। 14:36 <BrianR> उम्मीद है सप्ताह के अंत तक सभी बग्स सुलझा दूँगा और datagram तथा raw काम करेंगे। 14:37 <BrianR> streams पर अच्छी OO फिनिश देने के लिए थोड़ा और काम लगेगा। 14:37 <Nightblade> ओह हाँ, मैंने datagram या raw की परवाह नहीं की... बस stream 14:37 <Nightblade> और वैसे भी मैं वही उपयोग करूँगा 14:37 <fvw> human: क्या आपने wxWindows पर विचार किया है? यह उस तरह की चीज़ों के लिए काफ़ी उपयोगी है (नहीं लगता कि Windows GTK target though) 14:37 <jrandom> शानदार BrianR 14:38 <BrianR> पत्नी मुझे डिनर के लिए साथ आने को कह रही है। हो सकता है कि मैं समय पर myi2p चर्चा के लिए वापस आऊँ या नहीं। मैंने थ्रेट मॉडल और कुछ dumb फाइलसर्वर वाली चीज़ें नोड 208 पर पोस्ट कर दी हैं 14:38 <human> fvw: GTK का Windows पोर्ट मौजूद है (The GIMP भी Windows पर चलता है) 14:38 <jrandom> कूल nightblade, पहले जो ज़रूरी है उसे लागू करना ही बेहतर है 14:38 <human> fvw: s/client/port/ 14:38 <jrandom> heh 'k BrianR, धन्यवाद 14:38 <fvw> human: मेरा मतलब wxWindows के लिए GTK Windows target से है (जिसे उपयोग करने का मैं सुझाव दे रहा था) 14:38 * fvw BrianR को हाथ हिलाता है। भोजन का आनंद लें। 14:38 <human> fvw: आह... खैर, मुझे vxWidgets के बारे में नहीं पता (vxWindows का नया नाम :-) 14:39 <human> fvw: लेकिन GTK+ की बात Nightblade कर रहा था, मैं नहीं :-) 14:40 <fvw> ओह, मेरी नज़र फिसल गई, मुझे नज़रअंदाज़ करें। 14:40 <Nightblade> मैं C जितना C++ से परिचित नहीं हूँ 14:40 <Nightblade> मेरी जानकारी में (afaik) GTK ही एकमात्र क्रॉस-प्लैटफ़ॉर्म C GUI लाइब्रेरी है 14:40 <Nightblade> ऐसा नहीं कि मैं GTK को ख़ास पसंद करता हूँ 14:40 <fvw> यह मायने नहीं रखता, wxWindows को C से आसानी से अपनाया जा सकता है। 14:40 <Nightblade> हम्म 14:40 <Nightblade> ठीक है, शायद मैं भी इस पर नज़र डालूँगा 14:40 <Nightblade> मैं C++ जानता हूँ, पर इसमें कोई बड़ा प्रोग्राम नहीं लिखा है 14:41 * fvw भी C++ कोडर नहीं है, पर मैंने कुछ समय पहले इसमें एक परिवहन कंपनी के लिए काफ़ी बड़ा ट्रांज़ैक्शन व्यूअर बिना कठिनाई के बना दिया था। 14:42 <Nightblade> मुझे यक़ीन है कि wxWindows का Windows पोर्ट अधिक परिपक्व है 14:42 <Nightblade> GTK से 14:42 <fvw> काफ़ी संभवतः हाँ। 14:43 <Nightblade> (ठीक है, मीटिंग जारी रखें) heh 14:43 <jrandom> :) 14:43 <jrandom> ठीक है, 3) रोडमैप अपडेट्स पर चलते हैं 14:44 * jrandom पिछले महीने http://www.i2p.net/roadmap को अपडेट करने में लापरवाह रहा है 14:44 <jrandom> लेकिन अब यह फिर से वर्तमान स्थिति तक अपडेट है 14:44 <jrandom> दुर्भाग्यवश, साफ़ है कि हमें अगले हफ्ते 0.4 नहीं मिल रहा 14:44 <duck> (क्या 1.1, 2.0, 3.0 भी up2date हैं?) 14:45 <jrandom> जी सर 14:45 * Masterboy ने पढ़ा और पसंद किया - कोई जल्दी नहीं, हम पर आग नहीं लगी है.. 14:46 <duck> किसी को wikipedia/infoanarchy भी अपडेट करना चाहिए :) 14:46 <jrandom> ओह, मुझे शायद 0.4 से "SAM bridge and client libraries implemented and tested" हटाना चाहिए 14:46 <jrandom> heh हाँ, इसी लिए मैंने कुछ समय पहले iA को !thwapped किया जब उन्होंने बस विकी पेज कॉपी कर दिया था 14:46 <jrandom> (उन्हें /roadmap की ओर इशारा करना चाहिए, सामग्री डुप्लिकेट नहीं करनी चाहिए) 14:47 <Masterboy> SAM पूरा हो गया? 14:47 <jrandom> यह functional है हाँ, हालांकि अतिरिक्त client libraries पर काम जारी है 14:47 <jrandom> s/are/is/ 14:48 <jrandom> ठीक है, जब तक और रोडमैप प्रश्न/चिंताएँ नहीं हैं, 4) MyI2P पर आगे बढ़ते हैं 14:50 <jrandom> भले ही मैंने स्वयं myi2p पर काम करना रोक दिया है, हमने इस प्रयास के लिए एक बाउंटी खोल दी है - http://www.i2p.net/node/view/216 14:50 <jrandom> इसका एक हिस्सा यह है कि हमें आवश्यकताओं को सही तरह परिभाषित करना होगा, और इस पर कुछ बहस हुई है कि वे क्या होनी चाहिए 14:51 <Masterboy> मेरे दोस्त को इसमें लाने की कोशिश की, उसने कहा काम बहुत ज़्यादा, पैसे बहुत कम;P खैर वह एक पूँजीवादी है;) 14:51 <Masterboy> खैर मैंने इसे कोड करने की पेशकश की.. 14:52 <jrandom> इस पर कोडिंग हमेशा स्वागतयोग्य है :) 14:53 <jrandom> हालाँकि मौजूदा महत्वपूर्ण वास्तु प्रश्न यह है कि उन लोगों से कैसे निपटा जाए जो अपना i2p router / myi2p node हर समय नहीं चला सकते 14:53 <Nightblade> बस किसी trusted i2p ISP की ज़रूरत होगी 14:53 <jrandom> दो प्रस्ताव हैं: या तो hosted service providers का उपयोग करें, या सिस्टम को विभाजित करके एक distributed backing store का उपयोग करें 14:54 <_cervantes_> दूसरा दीर्घकालीन आदर्श समाधान है 14:54 <_cervantes_> *latter 14:54 <duck> (और वह एक अलग बाउंटी होगी) 14:55 <_cervantes_> या एक webcache प्रॉक्सी सेवा... 14:55 <jrandom> सही - यदि हम hosted service provider (या लोकली चलने वाले node) का रास्ता चुनते हैं, तो जब DHT (डिस्ट्रिब्यूटेड हैश टेबल)/आदि उपलब्ध हो जाए, हम और अधिक सामग्री DHT में धकेल सकते हैं 14:55 <jrandom> _cervantes_: वही मूलतः distributed backing store है - untrusted डेटा caches 14:57 <deer> * Masterboy सोचता है bogobot कहाँ है 14:57 <jrandom> कठिन हिस्सा है आवश्यक access control कार्यक्षमता पाना - untrusted डेटा caches / distributed backing store के साथ, ACLs (Access Control Lists) मूलतः एन्क्रिप्शन ही हैं 14:57 <jrandom> लेकिन इस चर्चा का एक "side channel" आता है एक अनाम व्यक्ति द्वारा उठाए गए तीन बिंदुओं से @ http://www.i2p.net/node/view/215#comment-105 14:57 <_cervantes_> और signed कंटेंट 14:58 <jrandom> सही, दोनों तरह में signed कंटेंट होना ज़रूरी होगा 15:00 <_cervantes_> यहीं hypercubus का मॉडल मायने रखता है... लेकिन यह किसी भी तरह से "त्वरित" समाधान नहीं है 15:00 <jrandom> कल रात IRC पर हुई चर्चाओं से, हमने "LiveJournal threat मॉडल" पर ध्यान केंद्रित किया - कौन से अटैक LJ उपयोगकर्ताओं के लिए मायने रखते हैं, और कौन से नहीं 15:01 <wilde> पहले बुनियादी MyI2P को चलाना प्राथमिकता है 15:02 <jrandom> सही, और बुनियादी myi2p लागू करने के लिए हमें डिप्लॉयमेंट आर्किटेक्चर जानना होगा 15:03 <jrandom> जो उपयोगकर्ता अपने नोड्स नहीं चला सकते उनके लिए LJ थ्रेट मॉडल के साथ, मुझे नहीं लगता कि हमें untrusted data cache वाला रास्ता अपनाने की ज़रूरत है 15:03 <jrandom> और कोई myi2p क्यों उपयोग करेगा अगर उसे केवल LJ का थ्रेट मॉडल चाहिए? क्योंकि यह अनाम है 15:04 <jrandom> हम किसी आदर्शीकृत सिस्टम के पीछे भाग सकते हैं, पर घटती प्रतिफल (diminishing returns) का नियम है 15:04 -!- Irssi: #i2p: कुल 24 nicks [0 ops, 0 halfops, 0 voices, 24 normal] 15:05 <jrandom> इसी कारण मैं बाउंटी को मौजूदा दिशा में ही रखने की ओर झुक रहा हूँ - बुनियादी सिस्टम आने के बाद हम विकल्प बाद में जोड़ सकते हैं 15:05 -!- duck_ अब duck के नाम से जाना जाता है 15:06 <jrandom> खैर, 4) MyI2P के लिए मेरे पास बस इतना ही है, जब तक किसी और के पास कुछ और न हो जिसे उठाना चाहें 15:06 <jrandom> यदि नहीं, तो 5) ??? पर चलते हैं 15:07 <_cervantes_> हम्म आपको एक बड़ा गेवेल चाहिए :) 15:07 <jrandom> मैं मीटिंग नोट्स में morph.i2p के नए eepsite का उल्लेख करना भूल गया, और nickster.i2p पर अब एक सार्वजनिक fproxy उपलब्ध है! 15:08 <jrandom> (और sungo.i2p ने अपना वेबकैम चालू कर दिया है :) 15:08 <_cervantes_> heh... 15:08 <_cervantes_> i2pr0n 15:08 <jrandom> किसी और के पास कुछ है जो उठाना चाहते हों? 15:10 <jrandom> यदि नहीं, तो इससे हम 70 मिनट के निशान पर पहुँचते हैं 15:10 <deer> <Masterboy> नहीं 15:10 * jrandom समेटता है 15:10 * jrandom मीटिंग को बंद करने के लिए *baf* करता है