I2P डेवलपर बैठक - 28 फरवरी, 2006

15:11 <jrandom> 0) हाय 15:11 <jrandom> 1) नेट स्थिति और 0.6.1.12 15:11 <jrandom> 2) 0.6.2 तक का रास्ता 15:12 <jrandom> 3) मिनीप्रोजेक्ट्स 15:12 <jrandom> 4) ??? 15:12 <jrandom> 0) हाय 15:12 * Complication तेजी से नोट्स पढ़ता है 15:12 * jrandom हाथ हिलाता है 15:12 <jrandom> साप्ताहिक स्थिति नोट्स यहाँ पोस्ट किए गए हैं: http://dev.i2p.net/pipermail/i2p/2006-February/001266.html 15:12 <jrandom> (और यहाँ मैं मीटिंग से 15 मिनट पहले ही नोट्स पोस्ट कर रहा था! ;) 15:13 <jrandom> ठीक है, जब तक आप सब वे बड़े ही रोमांचक हिस्से पढ़ते हैं, चलिए 1) नेट स्थिति और 0.6.1.12 पर चलते हैं 15:14 <jrandom> जैसा बताया, 0.6.1.10–0.6.1.12 रिलीज़ के प्राथमिक लक्ष्य पूरे होते दिख रहे हैं, जिसमें tunnel निर्माण क्रिप्टो में बदलाव को संबोधित किया गया है और निर्माण की विश्वसनीयता में काफ़ी सुधार हुआ है 15:16 <jrandom> 0.6.1.10 पर जो उतार-चढ़ाव दिखे थे, वे चले गए हैं, और IRC स्थिरता फिर काफ़ी अच्छी लग रही है 15:16 <jrandom> क्या 1) नेट स्थिति और 0.6.1.12 पर किसी के पास कुछ और है, या हम 2) 0.6.2 तक का रास्ता पर आगे बढ़ें? 15:17 <+Complication> यहाँ नेट स्थिति: अब 20 KB/s से नीचे नहीं जा रहा :) 15:18 <jrandom> बहुत बढ़िया, हाँ 0.6.1.12 ने 0.6.1.11 में एक बड़ा बग ठीक किया जहाँ उपलब्ध बैंडविड्थ का लाभ नहीं उठाया जा रहा था। अब उपलब्ध संसाधनों का बेहतर उपयोग होना चाहिए 15:20 <jrandom> ठीक है, चलिए 2) पर चलते हैं 15:20 <jrandom> जैसा कहा, 0.6.2 के लिए आख़िरी फंक्शनल बदलाव लगाने से पहले कुछ बातें सुलझानी हैं, पर उस दिशा में प्रगति हो रही है 15:20 <nymisis> नेट स्थिति ठीक है :) 15:22 <jrandom> ठीक है। नई peer ordering रणनीतियों के विवरण पर और जानकारी उनके आने से पहले उपलब्ध होगी, लेकिन नोट्स में संक्षिप्त उल्लेख से उनका सार स्पष्ट होना चाहिए 15:23 <jrandom> 2) 0.6.2 तक का रास्ता के संबंध में किसी के कोई प्रश्न/टिप्पणियाँ/चिंताएँ? 15:23 <postman> jrandom: इस बार कोई टेस्टनेट्स? 15:24 <postman> (क्या टेस्ट के लिए किसी routers, प्रतिभागियों की ज़रूरत है) 15:24 <postman> ? 15:24 <+Complication> मामले का सार काफ़ी सीधा लगा — किसी प्रतिद्वंदी के लिए विविध सांख्यिकीय डेटा इकट्ठा करने के मौक़ों को सीमित करना 15:25 <+Complication> काफ़ी वांछनीय फीचर लगता है 15:25 <jrandom> postman: नई चीज़ें live नेट पर केवल स्थानीय जानकारी से पारदर्शी रूप से काम करना चाहिए, इसलिए टेस्ट के लिए अलग नेट की ज़रूरत नहीं होनी चाहिए 15:25 <jrandom> हाँ, बिल्कुल Complication 15:26 <postman> ठीक है 15:26 <postman> jrandom: क्या आप 0.6.2 के लिए कोई ETA (अनुमानित समय) बताने के लिए काफ़ी साहसी हैं? :) 15:27 <blubb> 1 अप्रैल 15:27 <jrandom> खैर, आज फ़रवरी का आख़िरी दिन है, तो मेरा अनुमान मार्च या अप्रैल होगा 15:27 <postman> हेहे 15:27 <jrandom> blubb: तब के लिए हमने पहले से एक mi6 बैकडोर शेड्यूल कर रखा है ;) 15:29 <@cervantes> ज़्यादा सही होगा कहना, mi6 का एक कैटफ्लैप 15:29 <@cervantes> (बजट कटौती) 15:29 <postman> एक हाथियों के घर में 15:30 <nymisis> वह SIS है, MI6 नहीं, अगर आप सटीक होना चाहते हैं :) 15:30 <jrandom> खैर, उन्हें बस 'वे लोग' कह देते हैं ;) 15:31 <jrandom> ठीक है, 2) के लिए और कुछ? 15:31 <jrandom> अगर नहीं, तो चलिए 3) मिनीप्रोजेक्ट्स पर बढ़ते हैं 15:31 <@cervantes> माफ़ कीजिए "the firm" 15:34 <jrandom> ठीक है, मैं बस कुछ बढ़िया बातें बताना चाहता था जो 1) करने में सरल हों और 2) सच में उपयोगी 15:34 <+Complication> मिनीप्रोजेक्ट्स की तरफ़, यक़ीन नहीं कि मेरा Syndie उत्तर पहुँचा या नहीं, पर सोच रहा/रही हूँ कि क्या मैं एक उठा सकूँ। 15:34 <+Complication> अभी तय नहीं कौन-सा। फिलहाल थोड़ा और Java का अभ्यास कर रहा/रही हूँ (एक माइक्रो-प्रोजेक्ट कर रहा/रही हूँ :D) ताकि कोशिश करने पर एक संभाल सकूँ, इस पर भरोसा बढ़े 15:35 <DeltaQ> हम्म, अगर मैं कंसोल पर बैंडविड्थ बढ़ाऊँ तो बदलाव तुरंत लागू होंगे या रीबूट चाहिए? 15:35 <+Complication> जब मैं 'माइक्रो-प्रोजेक्ट' के साथ तैयार हो जाऊँ (मानते हुए कि तब तक सूची खाली नहीं हुई होगी), तब एक चुनने की कोशिश करूँगा/करूँगी 15:35 <jrandom> w3wt, बहुत बढ़िया Complication 15:36 <jrandom> DeltaQ: तुरंत 15:36 <@cervantes> क्या 1) syndie scheduler, 4) Download Manager / eepget scheduler से जुड़ा नहीं है? 15:36 <+Complication> DeltaQ: लगभग तुरंत प्रभावी होता है (उन अवधियों के भीतर जिनमें बैंडविड्थ का औसत निकाला जाता है) 15:37 <@cervantes> मुझे लगता है कि एक अधिक सामान्यतः कार्यक्षम अप- और डाउनलोड मैनेजर दोनों ज़रूरतें पूरी कर देगा 15:37 <jrandom> cervantes: हम्म, ज़रूरी नहीं। 1) काफ़ी फोकस्ड है, और उसमें pushes भी शामिल हैं, जबकि 4) काफ़ी जेनेरिक है 15:37 <+Complication> cervantes: हो सकता है 15:37 <jrandom> पर हाँ, दोनों के पीछे का इंजन EepGet है 15:37 <jrandom> (eepget Syndie के HTTP ट्रांसफ़र्स प्रोग्रामेटिकली करता है) 15:38 <DeltaQ> avg 13kb/s से ऊपर जाता नहीं दिख रहा 15:38 <DeltaQ> मैंने 64kb/s सेट किया है, 192 burst डाउन के साथ 15:38 <DeltaQ> 32/64 अप 15:38 <@cervantes> तो एक जेनेरिक pushing और pulling eepget, जिसमें scheduling और management की API हो... 15:39 <@cervantes> फिर भी, उस बिंदु पर शायद यह मिनी-प्रोजेक्ट नहीं रह जाएगा 15:39 <+Complication> DeltaQ: औसत इस पर भी निर्भर करता है कि आपके client tunnels (और अन्य पीयर्स के participating tunnels) कितना लोड पैदा करते हैं 15:39 <+Complication> माफ़ कीजिए, s/average/actual bandwidth 15:39 <jrandom> cervantes: हाँ, Syndie वाले हिस्से में काफ़ी लॉजिक शामिल है 15:40 <DeltaQ> हेह, यह आख़िरकार ऊपर गया 15:40 <DeltaQ> 1s: 30.82/29.33KBps 15:40 <DeltaQ> लगता है मुझे अपलोड बैंडविड्थ और बढ़ानी थी 15:40 <jrandom> DeltaQ: औसत पर यह भी असर पड़ेगा कि दूसरे लोग आपको कैसे देखते हैं, जो आपकी क्रियाओं पर निर्भर करता है, किसी एडवर्टाइज़्ड दर पर नहीं, इसलिए थोड़ा समय लगेगा 15:40 <+Complication> DeltaQ: pass-through ट्रैफ़िक (participating tunnels) के लिए, जो अंदर आता है वह बाहर भी जाना चाहिए 15:41 <+Complication> DeltaQ: तो बहुत अलग अपलोड/डाउनलोड दरें participating ट्रैफ़िक को दोनों में से कम वाली दर तक सीमित कर देंगी 15:42 <+Complication> DeltaQ: साथ ही, participating ट्रैफ़िक इस पर निर्भर करता है कि अन्य नोड्स आपकी नोड की रूटिंग क्षमता को कैसे 'समझते' हैं 15:42 <DeltaQ> ओकी 15:43 <+Complication> अगर वे सोचते हैं कि यह अच्छा route कर सकता है, तो वे ज़्यादा बार अनुरोध करेंगे 15:43 <jrandom> ठीक है, अगर 3) मिनीप्रोजेक्ट्स पर और कुछ नहीं, तो 4) ??? पर चलते हैं 15:43 <jrandom> क्या मीटिंग के लिए किसी के पास और कुछ है? 15:43 <DeltaQ> अच्छा, मैं एक router के पीछे हूँ, लेकिन मैंने पोर्ट 8887 इस पीसी को मैप कर दिया है 15:43 <+Complication> अगर यह नया है, या हाल ही में क्षमता बढ़ी है, तो वे थोड़ा संकोची होते हैं 15:44 <DeltaQ> ओह माफ़ कीजिए, मेरा मीटिंग में हस्तक्षेप करने का इरादा नहीं था ^^ 15:44 <+Complication> किसी ने पिछली बार clock skew (घड़ी का अंतर) पर आधारित संभावित हमलों के बारे में पूछा था। मेरा ख़याल है कि मैंने आपके tunneling हिस्से वाले उत्तर को देखा था (creation संदेश में सिर्फ़ tunnel की वैधता अवधि होती है, उसके निर्माता के दृष्टिकोण से समय नहीं)... 15:44 <@cervantes> (स्टेटस नोट्स में उल्लेख के लिए धन्यवाद) ;-)_ 15:46 <+Complication> तो मैंने सोचा, दरअसल, पूछूँ... I2P मैसेजिंग में किन बिंदुओं पर, अगर कहीं, प्रेषक के दृष्टिकोण से समय शामिल हो सकता है? 15:47 <+Complication> मैं इस पर अभी तक अप-टू-डेट नहीं हो पाया/पाई हूँ, इसलिए इस बारे में थोड़ा अनजान हूँ 15:47 <jrandom> Complication: कुछ भी स्पष्ट रूप से यह नहीं कहता कि "मुझे लगता है अभी $time है", पर पर्याप्त ट्रैफ़िक और टाइमिंग विश्लेषण के साथ, कोई इसे काफ़ी हद तक सीमित कर सकता है 15:48 <jrandom> हम समयों को बड़े पीरियड पर क्वांटाइज़ करते हैं, हालाँकि हमारे अधिकतम clock skew जितना बड़ा नहीं, तो वहाँ कुछ गुंजाइश है 15:49 <+Complication> क्या आपको लगता है कि अधिक "streamlined" NTP क्लाइंट से अंततः कोई लाभ मिलेगा? 15:49 <+Complication> जो skew को छोटा रखना आसान बनाए/रख सके? 15:50 <jrandom> खैर, जब से i2p में sntp क्लाइंट जोड़ा गया है, यह बेहतर होता जा रहा है, ताकि अब वह विविधता नहीं दिखती जो पहले दिखती थी 15:51 <jrandom> शायद हम minimum-skew सीमा 10s से घटाकर 2 या 3s कर सकें, या शायद उससे भी कम 15:51 <jrandom> वैकल्पिक रूप से, हम इसे ssu clock skews भी देखने दें ताकि अनावश्यक skews से बचा जा सके 15:52 <+Complication> या फिर, क्या किसी अन्य पीयर के संभावित clock मान का अनुमान लगाने के मौक़ों को और सीमित करना संभव है? 15:53 * Complication नहीं जानता/जानती कि कौन-सा रास्ता ज़्यादा व्यवहारिक होगा, बस कुछ संभावनाएँ सुना रहा/रही हूँ :D 15:53 <jrandom> नहीं, हमें सीधे जुड़े पीयर्स का clock skew पता होता है 15:55 <Magii> क्या यह पता करने का कोई तरीका है कि अपडेट सफलतापूर्वक हुआ? 15:55 <+Complication> आहा, तो सेशन प्रोटोकॉल वास्तव में उसी जानकारी पर निर्भर करता है.. 15:55 <tethra> अपना वर्ज़न नंबर देखिए 15:55 <+Complication> Magii: यह लॉग्स में "update verified, restarting to install" जैसा एक CRIT डालना चाहिए 15:55 <tethra> :/ 15:55 <+Complication> फिर, इसे एक ग्रेसफ़ुल रीस्टार्ट तक मिनटों की काउंटडाउन करनी चाहिए 15:56 <+Complication> और अंततः रीस्टार्ट करना चाहिए 15:57 <+Complication> ओह, साइडनोट: क्या अंदरूनी NTP क्लाइंट "clock drift rate" जैसा कोई कॉन्सेप्ट जानता है? 15:58 <jrandom> हाँ, http://localhost:7657/index.jsp के ऊपर-बाएँ कोने पर वर्ज़न नंबर खुद बता देगा :) 15:58 <jrandom> Complication: नहीं, यह sequential clock ticks की गारंटी नहीं देता 15:59 <jrandom> s/sequential/ordered/ 15:59 <+Complication> या ऐसा ज्ञान विकसित करना कि "हमारी सिस्टम घड़ी आवश्यक से 0.00345 गुना तेज़ है"? 16:00 <jrandom> आह, नहीं, हालांकि इसे net.i2p.util.Clock में जोड़ना बहुत कठिन नहीं होगा (मिनीप्रोजेक्ट करना चाहोगे? :) 16:00 <+Complication> मैं कुछ इसी तरह के बारे में सोच रहा/रही था/थी 16:01 <+Complication> लगता है अब मैं इसके बारे में थोड़ा और सोच रहा/रही हूँ :) 16:01 <+Complication> पर पहले दूसरे मिनीप्रोजेक्ट्स :) 16:02 <jrandom> ठीक है, मीटिंग के लिए किसी के पास और कुछ है? 16:03 <nymisis> मफिन्स? 16:04 <jrandom> नहीं, पैनकेक 16:04 <jrandom> (म्मम्म पैनकेक) 16:04 <jrandom> इसी बात से याद आया 16:04 * jrandom समेटता है 16:04 <nymisis> ओह, सही बात है। 16:04 * jrandom *baf* करते हुए बैठक समाप्त करता है