I2P डेवलपर बैठक - 28 दिसंबर 2004

13:06 <@jrandom> 0) हाय 13:06 <@jrandom> 1) 0.4.2.5 13:06 <@jrandom> 2) 0.5 13:06 <@jrandom> 3) ??? 13:06 <@jrandom> 0) हाय 13:06 * jrandom हाथ हिलाता है 13:06 <+postman> *वेव* 13:06 <ant> <jnymo> हेलो 13:06 <@jrandom> संक्षिप्त स्थिति नोट्स यहाँ पोस्ट किए हैं @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html 13:07 <@jrandom> 1) 0.4.2.5 पर चलते हैं 13:07 <@jrandom> जैसा बताया, लगभग सब कुछ काम कर रहा है 13:08 <+postman> हाँ, काफ़ी प्रभावशाली 13:08 <+postman> अब मेरे सिस्टम्स पर lease timeouts बिल्कुल नहीं 13:08 <@jrandom> बहुत से लोगों ने वही देखा है जो तुमने देखा jnymo, 0 participating tunnels के साथ, काफी हद तक बढ़ी हुई दक्षता और peer selection के कारण (जहाँ अब हमें पता है कि postman की मशीन से लिच करना है ;) 13:08 <ant> <jnymo> मैं भी 13:08 <@jrandom> बढ़िया 13:08 <ant> <jnymo> और eepsites तेज़ हैं 13:09 <+postman> :) 13:09 <ant> <jnymo> धन्यवाद postman :) 13:09 <+postman> कुल bw 29kb / 30.1kb/s है 13:09 <frosk> सबको कम प्यार मिला लग रहा है, पर असल में प्यार अधिक कुशलता से काम में लगाया जा रहा है 13:10 <ant> <jnymo> वाह 13:10 <@jrandom> कमाल postman 13:10 <mule2> मुझे नहीं लगता कि यह आदर्श है। बेहतर होगा कि सभी nodes से कुछ ट्रैफिक गुजरे 13:10 <ant> <jnymo> अगर लोग मुझे प्यार करें तो मैं उसे संभाल लूँगा :( 13:10 <+postman> हाँ 13:10 <mule2> एक तरह के cover ट्रैफिक की तरह 13:10 <@jrandom> mule2: मुद्दा यह है कि हमारा लोड हमारे नेटवर्क की क्षमता से काफी कम है 13:11 <@jrandom> मुझे नहीं लगता कि हम क्षमता को लोड से ज्यादा लंबे समय तक रख पाएंगे 13:11 <ant> <jnymo> mule2, postman एक mixer की तरह भी काम करता है.. तो पैकेट्स अंदर जाने के बाद वे कहाँ जा रहे हैं बताना मुश्किल है 13:11 <@jrandom> तो धीमे peers के माध्यम से डेटा न भेजने की मुझे ज्यादा चिंता नहीं है 13:12 <mule2> शायद कम परफेक्ट optimization गुमनामी के लिए बेहतर होगी 13:12 <@jrandom> दूसरी ओर, यह लोगों को i2pcontent (इस्तेमाल/इम्प्लीमेंट) करने के लिए प्रेरित भी करता है, ताकि वे mirror कर सकें और cover ट्रैफिक भी पा सकें ;) 13:12 <jdot__> क्या यह security issue है कि एक router लगभग सभी tunnels संभालता है? 13:13 <@jrandom> mule2: पहले इसे जितना अच्छा कर सकते हैं कर लें, फिर जानबूझकर इसे थोड़ा खराब करने पर चर्चा कर सकते हैं 13:13 <@jrandom> jdot__: हमारा कोई एक router सारा ट्रैफिक नहीं संभाल रहा, पर हम देख रहे हैं कि बहुत तेज़ connections (colo, आदि) वाले routers, dialup/DSL/केबल उपयोगकर्ताओं की तुलना में अधिक संभाल रहे हैं 13:14 <@jrandom> और tunnel failures घटने का मतलब है कि हम कम शिफ्ट कर रहे हैं और कम explore 13:14 <mule2> शायद कुछ ट्रैफिक वितरण संभव हो, जब तक कि हम routers की सीमा से बहुत दूर हैं 13:14 <@jrandom> सही, probabilistic tunnel rejection router में है और router की bandwidth limits के आधार पर सक्षम किया जा सकता है 13:15 <ant> <jnymo> हाँ, पर postman के node पर इतना उच्च throughput उसके node का विश्लेषण करना कठिन बना देता है.. तो उसके माध्यम से भेजना शायद सुरक्षित हो, बजाय इसके कि सभी nodes 1 KB/s पर करें.. 13:15 <@jrandom> (पर यदि postman कोई limits सेट नहीं करता, तो हम उसका % मान कर reject नहीं कर सकते ;) 13:15 <ant> <jnymo> तेज़ nodes के समूह कुछ mix cascade संरचना जैसा बनाते हैं, है ना? 13:15 <@jrandom> हाँ, इसे देखने का एक तरीका यही है 13:15 <lektriK> क्या मैं Start I2P window बंद कर सकता हूँ? 13:15 * postman अपनी bandwidth सीमित NOT करने के लिए बहुत माफ़ी चाहता है 13:16 <@jrandom> lektriK: दुर्भाग्य से, सच में नहीं, जब तक कि आप i2p को एक service के रूप में शुरू न करें (See http://localhost:7657/configservice.jsp) 13:16 <@jrandom> हेह postman चिंता मत करो, हम तुम्हारे router से पीछे हट जाएंगे यदि/जब हम तुम्हारे router की capacity तक पहुँचेंगे 13:17 <lektriK> ठीक है, यह 'service started' दिखा रहा है 13:17 <lektriK> अब मैं इसे बंद कर सकता हूँ? 13:17 <@jrandom> lektriK: नहीं/हाँ - आप अपना router बंद कर सकते हैं फिर इसे start->run->"net start i2p" के जरिए फिर से शुरू करें 13:18 <mule2> जैसा अभी है, कुछ बहुत बड़े routers सभी tunnels संभाल सकते हैं, जिससे बाकी सभी routers से cover ट्रैफिक हट जाएगा। पर मीटिंग के बाद इस पर जारी रखते हैं। 13:18 <mule2> नेटवर्क के बहुत अच्छा व्यवहार करने की शिकायत तो नहीं करना चाहता :) 13:18 <@jrandom> hehe 13:20 <@jrandom> 0.5 के साथ कुछ और exploration होगा, हालांकि बहुत ज्यादा फैलने पर anonymity संबंधित मुद्दे हैं। 0.5 के लिए उस पर और विवरण तय करने होंगे (और डॉक में, जो अगले सप्ताह पहले ड्राफ्ट के रूप में तैयार हो सकती है) 13:21 <@jrandom> वैसे, 0.4.2.5 के लिए किसी और के पास कुछ है? 13:21 <@jrandom> या हम संक्षेप में 2) 0.5 पर बढ़ें? 13:21 <+postman> आगे बढ़ें 13:21 <ant> <jnymo> बहुत स्थिर... आगे बढ़ें 13:21 <@jrandom> समझो बढ़ गए 13:22 <@jrandom> 2) 0.5 13:22 <@jrandom> हाँ। अभी काम जारी है। तैयार होने पर और जानकारी। 13:22 <ant> <Quadn-werk> Sir Arthur C. Clarke ज़िंदा हैं :P 13:22 <ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1 13:22 <ant> <jnymo> .5 रोमांचक है 13:22 <@jrandom> ठीक है, इस पर मेरी बात यहीं तक - किसी के कोई सवाल / इस पर चर्चा? 13:23 <@jrandom> हाँ, पिछले 16 महीनों में जो सीखा उस पर आधारित कुछ महत्वपूर्ण बदलाव चल रहे हैं 13:23 <@jrandom> (या धत, 18) 13:23 <+postman> jrandom: तो 0.5 में ज्यादातर नया tunnel management system होगा? 13:23 <ant> <Quadn-werk> उफ़, उम्मीद है मैंने मीटिंग नहीं तोड़ी :/ 13:23 <+postman> वाह 13:23 <ant> <Quadn-werk> सॉरी heh 13:23 <ant> <jnymo> heh. मेरे पास एक सुझाव था 13:24 <@jrandom> हाँ postman, नया management, pooling और building 13:24 <+postman> quadn: देखो तुमने क्या किया - तुम्हारे paste से netsplit हो गया :) 13:24 <@jrandom> कमबख्त! 13:24 <ant> <Quadn-werk> ! 13:24 <@jrandom> क्या हाल, jnymo? 13:24 <+postman> jrandom: क्या हर tunnel अब भी एक अलग local destination होगा? 13:25 <@jrandom> क्या? 13:25 <@jrandom> 0.5 में i2ptunnel में कोई बदलाव नहीं होगा 13:25 <+postman> jrandom: ठीक 13:25 <@jrandom> (कम से कम, मैंने कोई योजना नहीं बनाई) 13:26 <mule> postman कोई intersection attack माउंट कर रहा है? 13:26 <ant> <jnymo> जिन्हें /बिलकुल भी/ bandwidth उपयोग नहीं मिल रहा.. 13:26 <ant> <jnymo> क्या कहते हो routers को ऐसे tunnels बनाने दें जिनमें वे हों.. जैसे ABCABCA 13:26 <+postman> mule: नहीं, यह quadn की गलती थी :) 13:26 <ant> <jnymo> और वह एक dummy tunnel होगा 13:27 <@jrandom> jnymo: किसी router का यह विज्ञापन करना कि "hey मेरे पास अतिरिक्त bandwidth है, मुझे इस्तेमाल करो" खतरनाक खेल है 13:27 <+postman> jrandom: फिर redesign किन मुद्दों को संबोधित करेगा (संक्षेप में) 13:27 <ant> <jnymo> मेरा वह मतलब नहीं था, jrandom 13:27 <@jrandom> पर अभी लगता यह है कि हमारे पास दो सेट के tunnels होंगे - सामान्य वाले, और फिर exploratory वाले, जहाँ बाद वाले randomly चुने गए non-failing peers से बनाए जाएँगे 13:28 <ant> <jnymo> jrandom: मेरा मतलब dummy tunnel बनाना था, और कुछ ट्रैफिक simulate करने के लिए खुद को उस tunnel के बीच में रखना 13:29 <@jrandom> postman: tunnel में peers को correlate करना काफी कठिन बनाना, clients को अपने outbound tunnel length प्रभावी रूप से चुनने देना, और predecessor attack को address करने के लिए आवश्यक विकल्प देना (विभिन्न tradeoffs के साथ) 13:29 <@jrandom> (ओह, और बहुत सारी modPow calls हटाकर परफॉर्मेंस सुधारना) 13:29 <+postman> ठीक धन्यवाद 13:29 <ant> <jnymo> postman: और per hop tunnel IDs एक बड़ा बदलाव है 13:30 <+postman> modPow? 13:30 <@jrandom> आह jnymo। हाँ, विभिन्न chaff ट्रैफिक (नकली भराव ट्रैफिक) जनरेशन की काफी संभावनाएँ हैं 13:30 <ant> <jnymo> उस तरह, दो गैर-आसपास के nodes यह नहीं जान पाएँगे कि वे उसी tunnel पर हैं, postman 13:30 <@jrandom> postman: modular exponentiation, भारी CPU उपयोग और memory की बर्बादी 13:31 <ant> <jnymo> jrandom: ठीक कूल 13:31 <+postman> k 13:31 <scintilla> jrandom, 'clients को tunnel length चुनने' के संबंध में: क्या कुछ ऐसा होगा जिससे लोग इसे 99 (या जो भी) तक न बढ़ा पाएं? 13:31 <ant> <jnymo> CPU पावर 13:32 <@jrandom> ज़रूरत पड़ने पर हम hashcash जोड़ सकते हैं, पर अत्यधिक लम्बे tunnels वैसे भी फेल हो जाएँगे 13:32 <scintilla> आह सही बात 13:32 <@jrandom> हम कुछ चालाकी भी जोड़ सकते हैं - यह आवश्यक करना कि किसी tunnel के 'valid' होने के लिए निर्माण के 60s के भीतर उससे एक valid tunnel message गुजरे 13:33 <@jrandom> (तो यदि tunnel 20 hops लंबी हो, तो सभी hops बनाना उनके लिए बहुत समय लेगा) 13:33 <scintilla> यह बढ़िया विचार है - इससे ऐसी बेतुकापन अधिक देर तक टिकेगा नहीं 13:33 <@jrandom> पर यह सब hackers के खिलाफ है। सामान्य उपयोगकर्ता तो बस exposed interface इस्तेमाल करेंगे 13:34 <ant> <jnymo> सही, जिसे आप कहीं न कहीं कैप करेंगे, सही? 13:34 <ant> <jnymo> हमें मौजूदा अधिकतम 2 से ज़्यादा मिलेगा, सही? 13:34 <@jrandom> सही, जैसे /configclients.jsp या /i2ptunnel/edit.jsp पर # hops ड्रॉपडाउन 13:35 <@jrandom> ओह मुझे लगा max अभी 3 है? ठीक, पर हाँ, 2 से अधिक उपलब्ध होगा 13:35 <ant> <jnymo> 3 tunnels, 2 hops 13:35 <@jrandom> आह 'k 13:35 <@jrandom> हाँ, 0.5 कुछ महत्वपूर्ण नए tweaks जोड़ेगा, जैसे इन lengths को randomize करना है या नहीं, कितना randomize करना है, आदि 13:36 <frosk> max सचमुच 3 है 13:36 <ant> <jnymo> हम्म 13:37 <@jrandom> आह, /configclients पर 3 है, i2ptunnel पर 2 13:37 <frosk> क्या 0.5 जनवरी के लिए अब भी ट्रैक पर है? 13:37 <ant> <jnymo> आह 13:37 <@jrandom> हाँ frosk 13:37 <frosk> बढ़िया 13:37 <@jrandom> मैं streaming lib पर अब ज़्यादा देर नहीं लगाऊँगा, वादा ;) 13:37 <frosk> यह बहुत काम जैसा लगता है :) 13:38 <@jrandom> असल में इतना बुरा नहीं, कठिन हिस्सा algorithms को सही बनाना है 13:38 <@jrandom> (details schmetails ;) 13:39 <+postman> frosk: और यह सब पहले से कागज़ पर है 13:39 <+postman> :) 13:39 <ant> <jnymo> heh 13:39 <frosk> सही :) 13:39 <@jrandom> ज़्यादातर हाँ ;) 13:39 <@jrandom> ठीक, 2) 0.5 के लिए किसी के पास और कुछ? 13:39 <ant> <jnymo> कुछ नहीं 13:39 <frosk> कुछ भी नहीं 13:40 <@jrandom> 'k, अब 3) ??? पर चलते हैं 13:40 <@jrandom> हाय 13:40 <@jrandom> किसी के पास और कुछ लाने के लिए? 13:41 <ant> <jnymo> postman: i2pmail.org पर smtp/pop3 inproxies नहीं हैं, है ना? 13:41 <cat-a-puss> मैं अब भी client end पर अजीब देरी देख रहा हूँ... 13:41 <+postman> ह्म्म, नहीं 13:41 <frosk> यहीं मैं बेहतरीन विकास के साल के लिए बधाई की वाइन की बोतल सौंपता ;) 13:41 <+postman> jnymo: POP3 केवल i2p users के लिए उपलब्ध है 13:41 <@jrandom> cat-a-puss: आह जब आप पहले थे, मैं वे संदेश मिस कर गया 13:41 <+postman> jnymo: डोमेन i2pmail.org के लिए MX के रूप में एक SMTP inproxy है 13:42 <@jrandom> frosk: चीयर्स 13:42 <ant> <jnymo> सही सही.. वह कूल है.. 13:42 <cat-a-puss> जैसे मेरे पास दो local Destinations हो सकते हैं और जब एक दूसरे से कनेक्ट करने की कोशिश करता है तो देरी होती है और यह CPU-bound नहीं है 13:42 <mule> cat-a-puss: क्या आप बोनस चेक भी देंगे? 13:42 * postman एक अच्छी व्हिस्की दान करता है 13:42 <@jrandom> cat-a-puss: ठीक, आपने .5-1.0s की देरी देखी थी, सही? 13:42 <cat-a-puss> mule: क्या? 13:42 <cat-a-puss> jrandom: हाँ 13:43 <@jrandom> cat-a-puss: पूरी तरह सामान्य, deferred SYN का हिस्सा 13:43 <mule> माफ़ कीजिए, टिप्पणी frosk से थी 13:43 <ant> * jnymo उस घटिया बॉक्स वाइन को निकालता है 13:43 <mule> frosk: क्या आप बोनस चेक भी देंगे? 13:43 <@jrandom> (यह SYN और संबंधित ACK भेजने से पहले थोड़ा इंतज़ार करता है, ताकि अधिक डेटा बाँधने के लिए हो) 13:43 <scintilla> ओह FYI, मुझे जल्द ही वह किताब मिल जानी चाहिए जिसमें Fortuna algorithm की spec है... इस बीच मैं Java में मशीन को नुकसान पहुँचाए बिना entropy इकट्ठा करने के प्रयोग कर रहा हूँ 13:44 <@jrandom> आह बढ़िया 13:44 <ant> <jnymo> हम्म, कोई i2p पर कुछ हमले माउंट करना चाहता था 13:44 <ant> <jnymo> वह कौन था? 13:44 <@jrandom> connelly 13:44 <cat-a-puss> क्या इसे रोकने का कोई तरीका है, या मुझे जहाँ संभव हो short-lived connections से बचने की कोशिश करनी होगी? 13:45 <ant> <jnymo> उस पर कुछ खबर, jr? 13:45 <@jrandom> cat-a-puss: हाँ, I2PSocketManager बनाते समय कुछ options पास कर सकते हैं, मैं उन्हें निकालता हूँ 13:46 <@jrandom> jnymo: यह एक long-term intersection attack है, तो कुछ समय बाद उसके पास ऐसा डेटा होगा जिससे पता चलेगा कि कौन-सी eepsites किन routers पर हैं। यकीन है, मिलते ही वह हमारे लिए कुछ सार-संग्रह लिखेगा 13:46 <ant> <jnymo> scintalla: Fortuna algorithm क्या है? 13:46 <ant> <jnymo> jrandom: ठीक है 13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100 13:48 <scintilla> यह एक cryptographically secure pseudo-random number generator है... जो विश्वसनीय encryption के लिए बिल्कुल आवश्यक होता है 13:48 <jdot__> क्या उस attack के लिए किसी ने स्वेच्छा से हिस्सा लिया? 13:48 <@jrandom> cat-a-puss: फिर I2PSocket पर write() करने के बाद flush() अवश्य करें 13:48 <@jrandom> jdot__: हाँ, उसके पास 7 volunteered sites हैं 13:48 <cat-a-puss> jrandom: ठीक 13:49 <ant> <jnymo> महान naming debate के संबंध में.. 13:49 <ant> * jnymo दबी हँसी हँसता है 13:49 <@jrandom> ओह और i2p.streaming.initialAckDelay=1000 13:49 <@jrandom> या यहाँ तक कि =100 13:49 * jrandom jnymo पर कीचड़ उछालता है 13:50 <ant> <jnymo> मैं वास्तव में X.500 के साथ काम करता हूँ और मेरी नौकरी मुझे फ्री WinServers देती है 13:50 <ant> <jnymo> तो, शायद मैं एक-दो महीने में testing के लिए एक central DNS सेटअप कर दूँ 13:51 <@jrandom> हेह, .mil पर hosted एक centralized naming server होना बेहद मज़ेदार होगा 13:51 <ant> <jnymo> हालाँकि WinServer में i2p addresses डालना trivial नहीं हो सकता.. पता नहीं 13:51 <ant> <jnymo> हेह.. dnsalias ही टिकट है 13:52 <@jrandom> nano ने कुछ बहुत बढ़िया काम किया है, dnsjava को i2p के साथ एकीकृत करके 13:52 <ant> <jnymo> ओह्ह 13:53 <@jrandom> अधिक विवरण के लिए nano.i2p देखें 13:53 <ant> <jnymo> और मुझे कोई बताने वाला नहीं था.. आह, धन्यवाद 13:53 <@jrandom> पर, जैसा पिछली बार बताया, लोगों को naming पर अपने विचार और आइडिया wiki पर पोस्ट करने चाहिए 13:54 <@jrandom> ठीक, मीटिंग में उठाने के लिए किसी के पास और कुछ? 13:55 <ant> <jnymo> नहीं 13:57 <@jrandom> ठीक है, तो ऐसे में 13:57 * jrandom समेटता है 13:57 * jrandom मीटिंग को *baf* करके बंद करता है