I2P डेवलपर बैठक - अप्रैल 04, 2006

16:21 <jrandom> 0) हाय 16:21 <jrandom> 1) नेट स्थिति और 0.6.1.14 16:21 <jrandom> 2) Syndie plotting 16:21 <jrandom> 3) स्थानीय jbigi अनुकूलन 16:21 <jrandom> 4) ??? 16:21 <jrandom> 0) हाय 16:21 * jrandom हाथ हिलाता है 16:21 <jrandom> साप्ताहिक स्थिति नोट्स http://dev.i2p.net/pipermail/i2p/2006-April/001275.html पर पोस्ट किए गए हैं 16:21 * Complication पढ़ता है 16:22 <jrandom> जब आप सब वह (संक्षेप में तैयार) पोस्ट पढ़ लें, तो चलिए 1) नेट स्थिति पर चलते हैं 16:23 <@cervantes> (फ़ोरम वापस) 16:23 <jrandom> 0.6.1.13 के उपयोग को प्रभावित करने वाली कुछ समस्याएँ हैं, और उनमें से अधिकांश का पता लगाकर हल कर दिया गया है 16:24 <Complication> मेरी तरफ़, "चौथे" CVS बिल्ड के साथ, मैंने अपने ग्राफ़ में बदलाव देखा 16:24 <jrandom> अभी भी कुछ खामियाँ हैं जिनका परीक्षण और पुन:संरचना हो रही है, पर अगले कुछ दिनों में एक रिलीज़ आ जानी चाहिए 16:24 <Complication> कुल मिलाकर, चीज़ें ज़्यादा स्थिरता और कम उतार-चढ़ाव की तरफ़ बढ़ी हैं 16:24 <jrandom> अरे, मैं इसे -4 तक बढ़ाना भूल गया, है ना? 16:24 <jrandom> (ठीक है, -5 आज शाम बाद में आ जाएगा) 16:24 <jrandom> कूल Complication 16:25 <Complication> पर मेरी धारणा jbigi से भी प्रभावित हो सकती है, क्योंकि मैंने उसे अलग रखने के कदम नहीं उठाए 16:25 <Complication> अब, कुछ समय बाद, पुन:प्रेषण भी घटकर 15% तक आ गया है 16:28 <jrandom> हम्म, मैं भी अपना औसत SSU RTO 3s की सीमा के करीब जाते देख रहा हूँ 16:28 <jrandom> (हालाँकि पुन:प्रेषण अभी भी बहुत कम है, 5% से कम) 16:29 * Complication उसे दोबारा देखता है 16:29 <Complication> मान लें कि कच्चा औसत 1500 से थोड़ा ऊपर है 16:29 <Complication> (यहाँ) 16:30 <+fox> <BrianR___> jrandom: I2P पैकेट्स के लिए कोई वास्तविक "MTU" है? 16:30 <jrandom> अच्छा ठीक, शायद जैसे-जैसे वह बढ़ेगा, पुन:प्रेषण दर नीचे जाएगी 16:30 <Complication> मैंने देखा कि मेरे यहाँ शुरुआत में छोटे MTU थे, अब यह बढ़कर 1350 हो गया है 16:30 <jrandom> BrianR___: हाँ, या तो 1350 या 608 (जैसा कि `http://localhost:7657/peers.js` पर दिखाया गया है) 16:31 <jrandom> यदि बड़े MTU पर विफलता दर बहुत अधिक हो, तो यह छोटे MTU पर वापस चला जाता है (और यदि छोटे MTU पर यह बहुत कम हो, तो यह बड़े MTU पर छलाँग लगा देता है) 16:31 <+fox> <BrianR___> jrandom: क्या वह अंदर के payload के लिए है या दिखाई देने वाले IP पैकेट्स के लिए? 16:31 <+fox> <BrianR___> यानी, अगर मैं I2P stream पर डेटा का एक ब्लॉक भेजूँ, तो overhead कम करने के लिए खंडों का आदर्श आकार क्या होगा? 16:31 <jrandom> वह UDP payload के लिए है 16:32 <jrandom> streams दो लेयर ऊपर हैं 16:32 <jrandom> (tunnels के लिए fragmentation होता है, और फिर stream/I2CP स्तर पर fragmentation होता है) 16:32 <+fox> <BrianR___> हाँ... fragmentation को कम करने के लिए कोई आदर्श आकार है? 16:32 <jrandom> streaming lib का उपयोग करने वाले ऐप के लिए आदर्श ब्लॉक आकार "बड़ा" है, ताकि streaming lib उपयुक्त आकार चुन सके। 16:33 <jrandom> (यानी परदे के पीछे वाले को नज़रअंदाज़ करें) 16:33 <+fox> <BrianR___> आह.. शायद मुझे pipelining या कुछ ऐसा सोचना चाहिए तब.. 16:34 <+fox> <BrianR___> मैं ऐसी ऐप प्लान कर रहा हूँ जिसमें बहुत अनुरोध/प्रतिक्रिया ट्रैफ़िक होगा... 16:34 <jrandom> तब मैं बातचीत की अधिकता कम करने के लिए batching की सिफारिश करूँगा 16:34 <Complication> शायद ट्रैफ़िक को केंद्रित रखना कुछ हद तक मदद करेगा 16:37 <jrandom> ठीक है, 1) नेट स्थिति पर और कुछ, या हम 2) Syndie plotting की तरफ़ शिमी करते हुए चलें 16:38 * jrandom शिमी करता है 16:39 <jrandom> यह काफ़ी हद तक एक placeholder और CFP है — Syndie में, संचालन और UI दोनों में, बड़ा revamp होने वाला है, तो अगर आपके पास कुछ प्रमुख फीचर या उपयोग-मामले हैं जिन्हें आप समझते हैं कि संबोधित होना चाहिए, तो संपर्क करें 16:40 <jrandom> (जैसे-जैसे चीज़ें और स्पष्ट होंगी, ज़ाहिर है और जानकारी आती जाएगी) 16:42 <jrandom> फिलहाल इस पर मेरे पास कहने के लिए इतना ही है, तो 3) jbigi optimizations पर चलते हैं 16:42 <@frosk> और मैंने समझा था कि "plotting" Syndie में कुछ jrobin वाली चीज़ों की ओर इशारा करता है :) 16:43 <jrandom> हेहे 16:43 <jrandom> posts/day, posts/author, new authors/day, आदि plot करना दिलचस्प होगा ;) 16:44 <Complication> ओह, Syndie के बारे में एक बात (माफ़ कीजिए, अभी याद आया) 16:44 <Complication> =एक बात 16:44 <@frosk> आपको कौन-सा चाहिए, 0 या 1? :) 16:44 <Complication> क्या आपको लगता है कि पसंदीदा लेखकों और ब्लैकलिस्ट किए गए (स्पैम) लेखकों को दो अलग सूचियों में अलग करना व्यावहारिक होगा, या यह आसान/कठिन होगा? 16:45 <Complication> addresses.jsp पर 16:45 <jrandom> ओह, हाँ, बिना ज़्यादा मुश्किल के 16:46 <jrandom> यह revamp के लिए भी अच्छा विचार है, पर शायद इसे 0.6.1.14 बिल्ड में भी डाल सकते हैं 16:47 <Complication> नाह, यह मुझे "बाइटिंग" नहीं कर रहा, बस मुझे वही बात याद आ गई जो तब नोट की थी 16:47 <Complication> वैसे, Linux/AMD64 पर jbigi स्थानीय रूप से कंपाइल करके और GMP 4.2 का उपयोग करने पर तेज़ हो जाता है 16:48 <jrandom> कूल 16:48 <jrandom> क्या आपने उसकी तुलना GMP 4.1.2 पर -O3 -m64 के साथ की? 16:48 <Complication> और मैं बहुत गलत compile flags के पीछे जाने के लिए सच में बेवकूफ़ निकला :O 16:48 <@cervantes> relevant लिंक था `http://forum.i2p/viewtopic.php?t=1523&start=30` वैसे 16:48 <jrandom> आह धन्यवाद cervantes 16:48 <Complication> jrandom: मैंने अभी तुलना नहीं की है, पर करूँगा 16:49 <Complication> अगले निर्धारित रीबूट के दौरान 16:50 <jrandom> jbigi का build प्रक्रिया मूलतः "build GMP, फिर jbigi.o build करें, और दोनों को साथ link करें" है, तो GMP पर लोग जो भी तरह के optimizations करना चाहें, उन्हें पहले कदम के रूप में किया जा सकता है 16:50 <@cervantes> मेरे किए किसी भी पिछले टेस्ट में -O3 और -O2 के बीच ज़्यादा फ़र्क नहीं देखा है, x86_64 पर वह अलग है या नहीं ... *shrug* 16:50 <jrandom> हाँ, यह compiler rev पर भी निर्भर हो सकता है 16:50 <jrandom> (खासकर इन 3.3/3.4/4.0/4.1 मुद्दों के साथ) 16:51 <@cervantes> बस वही दोहराने के लिए जो मैंने उस थ्रेड में कहा था... हमें जल्द ही Windows64 के लिए optimized jbigi शायद नहीं दिखेगा 16:51 <+fox> <BrianR___> क्या I2P stream lib payload compression करती है? 16:52 <Complication> BrianR: हाँ 16:52 <@cervantes> जब तक किसी के पास M$ VC 2005 w/64-bit SDK न हो और वे GMP को compile कराने के लिए कड़ी मेहनत करने का मन न रखते हों 16:52 <Complication> कम से कम मेरी जानकारी में 16:53 <@cervantes> (हालाँकि कहीं GMP को VC प्रोजेक्ट में पोर्ट करने का एक प्रोजेक्ट था) 16:53 <jrandom> cervantes: खैर, हमारे पास एक ऐसा है जो amd64/win पर /works/ करता है, पर हार्डवेयर का पूरा उपयोग नहीं करता ;) 16:53 <jrandom> (जब मेरा नया बॉक्स आ जाएगा, तो शायद मैं उसे tweak कर सकूँ, क्योंकि वह amd64 है) 16:53 <+fox> <BrianR___> यह समझने की कोशिश कर रहा हूँ कि क्या मुझे bits बचाने के लिए binary protocol का उपयोग करना चाहिए या zlib वगैरह ascii protocol को अच्छी तरह छोटा कर देंगे.. 16:54 <@cervantes> कूलियो - दुर्भाग्य से Mingw64 या cygwin64 निकट भविष्य में दिखाई नहीं देते... 16:54 <jrandom> BrianR___: premature optimization हर बुराई की जड़ होती है, और ऐसी ही बातें... 16:55 <Complication> कम से कम आंशिक रूप से मानव-पठनीय प्रोटोकॉल आम तौर पर डिबग करना आसान होते हैं, पर मेरा ख़याल है यह इस पर निर्भर करता है कि कोई क्या कर रहा है 16:56 <Complication> (क्योंकि encryption जैसी कुछ चीज़ें मानव-पठनीय होना पसंद नहीं करतीं, चाहे कुछ भी हो :) ) 16:57 <Complication> लेकिन अगर I2P ही encryption करता है और compression भी, तो अच्छी संभावना है कि उसके ऊपर होने वाली कई चीज़ें human-readable protos से की जा सकें 16:58 <jrandom> हाँ 16:58 <jrandom> ठीक है, 3) jbigi वाली चीज़ों पर और कुछ? 16:58 <jrandom> अगर नहीं, तो 4) ??? पर चलते हैं 16:59 <jrandom> क्या मीटिंग के लिए किसी के पास और कुछ है? 17:01 <+tethra> मुझे याद है हाल में anonymous collaboration tools के बारे में कुछ सुना था 17:01 <+tethra> बताएँगे कि किस तरह के, और क्या वे Syndie-जैसे होंगे या नहीं? 17:02 <@cervantes> IRC और Syndie एक anonymous collaboration tool है :) 17:02 <jrandom> हम्म, पता नहीं आप किसकी बात कर रहे हैं — या शायद आप Syndie के नियोजित revamps का मतलब ले रहे हैं? :) 17:02 <+tethra> सही. 17:02 * tethra भी पक्का नहीं है, इसी वजह से उसने पूछा 17:02 <+tethra> फ़ोरम पर इस बारे में बात हुई थी — anonymity के कारण और ऐसी चीज़ें 17:03 <+tethra> मैं थ्रेड ढूँढूँगा ताकि उद्धरण ला सकूँ 17:03 <jrandom> आह सही 17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 17:03 <jrandom> use case थ्रेड 17:03 <+tethra> - anonymously hosted और सार्वजनिक रूप से पहुँचा जा सकने वाले forums/boards/wikis 17:03 <+tethra> हाँ 17:04 <+tethra> क्या Syndie जैसी किसी चीज़ पर आधारित i2wiki प्रकार का कोई प्रोजेक्ट होगा या यह उपयोगकर्ताओं पर निर्भर है? 17:04 <jrandom> वहाँ कुछ अच्छे विचार और अच्छा फीडबैक आया है 17:05 <jrandom> Syndie पोस्ट संपादित करने की क्षमता अक्सर माँगी जाने वाली फीचर है, और उसके साथ, आप एक rich editor के w/ साथ wiki बना सकते हैं 17:05 <jrandom> पर, बेशक, कुछ भी निर्वात में नहीं होगा — अगर कोई मानता है कि यह ज़रूरी है, तो किसी को कहना चाहिए "अरे, एक wiki आवश्यक है, और ये रहा कारण" 17:06 <jrandom> ऐसी अनगिनत apps हैं जिन्हें /बनाया जा सकता है/, पर हम strong anonymity और strong security का लक्ष्य रख रहे हैं, इसलिए क्या बनाया जा रहा है उस पर सावधानी बरतनी होगी 17:07 <+tethra> ठीक 17:07 <+tethra> यह कहने के बाद, जो चीज़ें गुमनाम और सुरक्षित रखना अधिक कठिन हैं, उन्हें शायद ऐसे व्यक्ति द्वारा करना बेहतर होगा जो चीज़ों को गुमनाम और सुरक्षित रखने में माहिर हो, सही? 17:08 <jrandom> संभवतः हाँ, हालाँकि कोई गुप्त मंडली नहीं है — कोई भी सीख सकता है 17:08 <+tethra> (मुख्य चीज़ें, मूलतः। मैं कोई नाम नहीं ले रहा, पर खैर.) 17:08 <+tethra> सही 17:09 <+tethra> पर अपने और दूसरों की anonymity की कीमत पर सीखना सर्वोत्तम तरीका नहीं है 17:10 <jrandom> हर किसी को कहीं से शुरू करना होता है, बेशक 17:10 <+tethra> (शायद अगर कोई sandbox टाइप चीज़ बनाए जो लोगों को $software चलाने दे और लोग उस पर हमला वगैरह करें, तो यह नए/अनुभवहीन लोगों के लिए अच्छा होगा?) 17:10 <+tethra> हाँ 17:14 <jrandom> ठीक है, क्या मीटिंग के लिए किसी के पास और कुछ है? 17:15 <jrandom> अगर नहीं 17:15 * jrandom समेटता है 17:15 <@cervantes> *ahem* 17:15 * jrandom रुकता है 17:16 <jrandom> क्या चल रहा है, cerv? 17:16 <Complication> बढ़िया, मुझे एक baf मिला ;P 17:17 <jrandom> baf-ब्लॉक किया ;) 17:17 <@cervantes> हप्स सॉरी, baffing जारी रखें 17:17 * jrandom समेटना फिर शुरू करता है 17:18 * jrandom *baf*s मीटिंग को बंद करता है