I2P डेवलपर बैठक - 18 अप्रैल, 2005

16:09 <jrandom> 0) नमस्ते 16:09 <jrandom> 1) नेट की स्थिति और 0.6.1.16 16:09 <jrandom> 2) Tunnel निर्माण और भीड़भाड़ 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) नमस्ते 16:10 * jrandom हाथ हिलाता है 16:10 <jrandom> साप्ताहिक स्थिति नोट्स यहाँ पोस्ट किए गए हैं http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk भी 16:10 <jrandom> (बैठक से लगभग दो घंटे *पहले* भी :) 16:11 <jrandom> ठीक है, चूँकि मुझे यकीन है कि आप सबने नोट्स ध्यान से पढ़ लिए हैं, चलिए 1) नेट की स्थिति पर चलते हैं 16:12 <+Complication> नमस्ते :) 16:12 * Complication तुरंत नोट्स उठा लेता है 16:12 <jrandom> 0.6.1.16 रिलीज़ ने हमारे prng में एक बहुत पुराने बग को ठीक किया, जो मनमाने tunnel rejections की काफ़ी बड़ी संख्या का कारण बन रहा था 16:13 <jrandom> (मूल कारण पिछले अक्टूबर में डाला गया था, पर अब ठीक हो गया है) 16:13 <+Complication> यहाँ स्थिति: 1 + 0..1 hop tunnels के साथ ठीक-ठाक चलता है, 2 + 0..1 या 2 +/- 0..1 के साथ नहीं चलता 16:14 <jrandom> हाँ, यह समझ में आता है, खासकर धीमे लिंक पर 16:14 <jrandom> (दुर्भाग्य से, "slower" का मतलब भी यहाँ बहुत ज़्यादा धीमा नहीं है) 16:15 <jrandom> अभी बहुत काम बाकी है, और 0.6.1.16 वह नहीं है जहाँ हमें पहुँचना चाहिए, लेकिन यह प्रगति है 16:17 <+Complication> एक बात जिसके बारे में मैं सोच रहा था, जिसे आपने "congestion collapse" कहा 16:18 <+Complication> उसके प्रभाव को सीमित करने का एक तरीका यह हो सकता है कि वास्तव में किसी router को भागीदारी अनुरोधों का एक निश्चित कोटा स्वीकार करने के लिए बाध्य किया जाए 16:19 <+Complication> (क्या यह उपयोगकर्ता द्वारा सीधे या परोक्ष रूप से तय किया जाए?) 16:19 <jrandom> किस उपयोगकर्ता द्वारा तय किया जाएगा? 16:19 <+Complication> (उदा. share percentage का कोई हिस्सा या एक अतिरिक्त पैरामीटर) 16:19 <jrandom> स्थानीय उपयोगकर्ता, या हम दूरस्थ उपयोगकर्ताओं द्वारा? 16:19 <+Complication> हर कोई अपने लिए निर्धारित करे 16:19 <@frosk> क्या हम 2) पर चलें? :) 16:20 <jrandom> हाँ, चलिए हमें 2) पर मान लेते हैं :) 16:20 <+Complication> ताकि मैं, उदाहरण के लिए, अपने router से कह सकूँ "भले ही तुम congested हो, न्यूनतम 4 KB/s पर routing जारी रखो" 16:21 <jrandom> Complication: यह वास्तव में संभव नहीं है - यदि कोई router बहुत congested है, तो अन्य लोग (उम्मीद है ;) उनसे tunnels में भाग लेने के लिए पूछना बंद कर देंगे। 16:21 <+Complication> (इसका अर्थ, निश्चित ही, यह होगा कि कोई स्थानीय destination कुछ देर और ऑफलाइन रह सकता है) 16:21 <jrandom> और यदि उनसे पूछा ही नहीं गया, तो वे /cant/ दूसरे लोगों का डेटा आगे नहीं बढ़ा सकते 16:22 <+Complication> आह, शायद मुझे इसे और स्पष्ट रूप से कहना चाहिए था 16:24 <+Complication> मेरा विचार था कि भागीदारी ट्रैफिक के एक निश्चित कोटे के तहत, वह participating tunnels के बजाय अपने ही tunnel निर्माण संदेशों को थ्रॉटल कर सकता है 16:24 <+Complication> उदा. "मैं अपने participating tunnels को कभी 4 KB/s से कम पर थ्रॉटल नहीं करूँगा। यदि इसकी ज़रूरत पड़ी, तो मैं अपनी ही ट्रैफिक को थ्रॉटल करूँगा।" 16:26 <jrandom> हम्म, इसमें anonymity जोखिम हैं (हालाँकि यह selective DoS की ही श्रेणी में आता है, जिसके विरुद्ध हम वैसे भी सुरक्षा नहीं करते) 16:27 <jrandom> लेकिन congestion होने पर अपने स्थानीय tunnel builds को थ्रॉटल करना मैं अभी परीक्षण में कर रहा हूँ - 4KBps की न्यूनतम सीमा को वैकल्पिक रूप से नज़रअंदाज़ करने का समर्थन जोड़ना पर्याप्त सरल होना चाहिए 16:28 <spinky> वर्तमान में, बहुत सारा डेटा ट्रांसफर करते समय आपको बिल्कुल भी cover traffic नहीं मिलता। 16:29 <spinky> भागीदारी बैंडविड्थ के लिए एक न्यूनतम सीमा होना अच्छा लगता है। 16:30 <jrandom> हाँ, हमारे पास एक न्यूनतम सीमा है (share percentage के रूप में और एक आंतरिक 4KBps जो सारी बैंडविड्थ आवंटित होने के बाद आरक्षित रहती है) 16:30 <+Complication> अरे, डिस्कनेक्ट्स... आशा है मैंने जो कहा था उसका बहुत कुछ नहीं खोया होगा, लेकिन जवाब मुझे लॉग से पढ़ने होंगे :) 16:32 <@frosk> क्या 4KBps के बारे में कुछ विशेष है? 16:33 <jrandom> कुछ बातें - 4KB ~= sizeof(tunnel create message), और अनुभवजन्य रूप से, मैंने इससे कम पर सफलतापूर्वक चलने वाला कोई router नहीं सुना है 16:33 <spinky> शायद वे बग हैं जो share percentage को काम करने से रोकते हैं? 16:34 <jrandom> आपको क्यों लगता है कि share percentage काम नहीं करता? 16:34 <@frosk> समझ गया 16:34 <+Complication> frosk: नहीं, यह अभी के कोड में बस एक संख्या है, और मैंने भी उसे ही संदर्भित किया जब मैं अपना विचार समझाने की कोशिश कर रहा था 16:35 <+Complication> (मतलबपूर्ण कारणों से नहीं, बल्कि इसलिए कि जो मैंने सोचा था वह एक अर्थ में उसका उलटा था) 16:35 <spinky> यह 80% पर सेट है और स्थानीय रूप से डेटा जनरेट करते समय भागीदारी 0 पर चली जाती है। शायद मैं चीज़ों को गलत समझ रहा हूँ। 16:36 <jrandom> आह, हाँ, share percentage वह नहीं करता जो आप सोच रहे हैं 16:36 <+Complication> spinky: यह उस चीज़ की अधिकतम सीमा है जो साझा की जा सकती है, बशर्ते साझा करने के लिए वास्तव में बैंडविड्थ उपलब्ध हो 16:37 <+Complication> यदि स्थानीय ट्रैफिक 70% ले लेता है, तो आपके पास साझा करने के लिए केवल 10% बचता है 16:37 <+Complication> यदि स्थानीय ट्रैफिक भारी है, तो आपके पास 0% बचेगा, और 80% की शीर्ष सीमा कभी छुई ही नहीं जाएगी 16:37 <spinky> ठीक है। मुझे दिख रहा है कि इसमें 'up to' लिखा है... 16:38 <+Complication> और साथ ही, 4 KB/s का रिज़र्व भी है 16:38 <jrandom> अच्छा, यह आपकी उपलब्ध चीज़ का share percentage है 16:38 <spinky> शायद floor participation बैंडविड्थ के लिए एक और सेटिंग, जिसके तहत router अधिक tunnels स्वीकार करेगा? 16:38 <jrandom> यदि आप अपनी बैंडविड्थ का 95% उपयोग कर रहे हैं, तो यह शेष 5% का अधिकतम 80% साझा करेगा 16:39 <+Complication> ओह, तो मैंने भी इसे आंशिक रूप से गलत समझा था 16:40 <fox> <zorglu1> i2p अन्य स्थानीय अनुप्रयोगों द्वारा उपयोग की गई बैंडविड्थ की मात्रा को कैसे मापता है? 16:40 <spinky> (बस कह रहा हूँ, यदि आप cover traffic को अच्छा मानते हैं तो शायद भारी स्थानीय बैंडविड्थ उपयोग के दौरान भी इसे कॉन्फ़िगरेबल बनाना अच्छा होगा) 16:40 <+Complication> मुझे लगा यह sustained limit के विरुद्ध लागू होता है 16:40 <jrandom> zorglu1: यह i2p के बैंडविड्थ उपयोग को मापता है, और i2p की बैंडविड्थ सीमाएँ जानता है 16:41 <jrandom> ओह, हम्म, कोड में वापस देखते हुए, int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> तो आप सही हैं, Complication 16:42 <jrandom> spinky: cover traffic कम विलंबता वाले mixnet पर ही उतना उपयोगी होता है 16:42 <jrandom> यह उच्च बैंडविड्थ वाले routers के लिए कुछ प्रोत्साहन तो देता है, लेकिन जिनके पास अतिरिक्त बैंडविड्थ नहीं है उनके पास बहुत कम विकल्प होते हैं 16:49 <jrandom> खैर, tunnel congestion की समस्या काफ़ी समय से है, लेकिन हाल ही में पागलपन भरी tunnel rejection दरों ने इसे और बढ़ा दिया है 16:49 <jrandom> उम्मीद है अगला rev हमारे लिए इसे साफ़ कर देगा 16:49 <jrandom> ठीक है, 2) tunnel निर्माण और भीड़भाड़ पर किसी के पास और कुछ है? 16:50 <@frosk> लगता है कि tunnel-building स्कीम में कुछ बदलाव करने होंगे 16:50 <+Complication> उम्मीद है इससे चीज़ें बेहतर होंगी :) 16:51 <+Complication> ओह, वैसे... 16:52 <jrandom> खैर, हमारे पास कुछ सस्ते फिक्स हैं, जैसे max concurrency कम करना, congestion होने पर अपने build attempts को थ्रॉटल करना, drop frequency को घटाना (explicit rejection के बजाय), और प्रोफाइलिंग को ऐसा समायोजित करना कि drops के बजाय explicit rejections को बढ़ावा मिले 16:52 <+Complication> ...क्या आपको संयोग से ऐसा कुछ मिला जो raw bandwidth indicators और tunnel payload indicators के बीच बड़े अंतर को समझा सके? 16:52 <+Complication> (उदा. कुल bandwidth 1 GB, tunnel payload का योग 300 MB) 16:52 <jrandom> लेकिन यह सच है, वे केवल परिमाण को प्रभावित करती हैं 16:52 <+Complication> (क्योंकि मैं हाल में IRC पर नहीं था, मुझे नहीं पता कि आपने हाल में इस पर ध्यान दिया है या नहीं) 16:54 <jrandom> इस पर ज़्यादा नहीं खोदा, पर याद रखें, आउटबाउंड tunnels के लिए tunnel निर्माण अनुरोध tunnel messages नहीं होते (और यदि केवल 0.1% सफल हों, तो उनकी संख्या बहुत होती है। और हर एक 4KB...) 16:54 * Complication को यक़ीन नहीं कि यह संकेतकों की वजह से है या वास्तविक प्रभाव है 16:55 <+Complication> ओह... आउटबाउंड build requests... सही 16:55 <jrandom> आने वाला -1 build प्रति-संदेश-प्रकार पैकेट मॉनिटरिंग के लिए ढेरों आँकड़े जोड़ता है 16:55 <+Complication> यही बात हो सकती है 16:55 <jrandom> (उन आउटबाउंड build requests में build participating requests भी शामिल हैं - एक reply को फॉरवर्ड करना) 16:56 <jrandom> ((तो यह सिर्फ़ स्थानीय चीज़ें नहीं हैं)) 17:00 <+Complication>> धन्यवाद, इससे बहुत कुछ स्पष्ट हो गया :) 17:00 <+Complication>> तो यह कोई जादू-टोना नहीं, बल्कि वास्तविक ट्रैफिक है, जिसे मैं बस भूल गया था, क्योंकि जिन जगहों पर मैंने देखा वहाँ इसे विशेष रूप से गिना नहीं गया था 17:00 <+Complication> वह वाकई होना ही था, और वाकई बहुत से बाइट्स खर्च होते 17:00 <+Complication> खासतौर पर कम सफलता दर के साथ 17:01 <jrandom> हाँ, हालांकि इसे उतना महँगा नहीं होना चाहिए जितना है, क्योंकि हमें मौजूदा से अधिक सफलता दर होनी चाहिए :) 17:01 <jrandom> ठीक है, 2) पर और कुछ? 17:02 <jrandom> यदि नहीं, तो 3) Feedspace पर चलते हैं 17:02 <jrandom> frosk: कोई अपडेट देना चाहेंगे? 17:03 <jrandom> (या कहें कि fsck off और eepsite पढ़ो? ;) 17:04 <@frosk> खैर, जिन लोगों ने frosk.i2p या feedspace.i2p पर ध्यान नहीं दिया, उनके लिए, feedspace अब मूल रूप से काम कर रहा है (मेरी अपनी "basically" की परिभाषा के अनुसार) 17:04 <jrandom> (w00t) 17:05 <@frosk> हाल में कुछ अच्छी जोड़ियाँ हुई हैं, जैसे i2p के अलावा अन्य ट्रांसपोर्ट्स के लिए इन्फ्रास्ट्रक्चरल सपोर्ट (tor और non-anonymous tcp/ip दिमाग में आते हैं) 17:06 <@frosk> तो समय के साथ, हम योजना बना रहे हैं कि syndie (एक आने वाले और शायद बहुत अच्छे rewrite में) को feedspace को अपनी syndication विधियों में से एक के रूप में इस्तेमाल करने दें 17:06 <@frosk> अभी, वास्तव में feedspace को किसी चीज़ के लिए *use* करने वाले कोई क्लाइंट ऐप्स नहीं हैं :) मैं एक बेहद कच्चे servlet ऐप के साथ परीक्षण कर रहा था 17:07 <jrandom> (crude + functional)++ 17:07 <@frosk> तो निश्चित रूप से एक client हैकर के लिए जॉब ओपनिंग है ;) 17:08 <@frosk> सार्वजनिक परीक्षण से पहले feedspace को अभी कुछ आवश्यक चीज़ों की ज़रूरत है, लेकिन अब इसमें ज़्यादा समय नहीं लगना चाहिए :) 17:08 <jrandom> nice1 17:08 <jrandom> क्या हम मदद के लिए कुछ कर सकते हैं? 17:08 <@frosk> साथ ही मैं थोड़ी documentation पर काम कर रहा हूँ, जिसकी कमी रही है 17:09 <spinky> क्या आपको लगता है कि feedspace बड़े फ़ाइलों के लिए उपयोगी होगा? 17:10 <@frosk> 1) (अभी तक बिना दस्तावेज़) xmlrpc api का उपयोग करने वाले क्लाइंट ऐप्स, 2) http://feedspace.i2p/wiki/Tasks, 3) जब समय आए तो परीक्षण में भाग लें 17:10 <@frosk> बड़े फ़ाइलों का समर्थन अभी प्राथमिकता नहीं है, शायद बाद में 17:10 <@frosk> "1.0" के लिए फ़ोकस छोटे संदेशों पर है जैसे ब्लॉग और चर्चा प्रविष्टियाँ, और किसी भी तरह के ईवेंट्स 17:11 <jrandom> हालाँकि .torrent फ़ाइलों को किसी rss/feedspace-समर्थित BT क्लाइंट में फ़ीड करना कोई समस्या नहीं होगी 17:11 <@frosk> बड़े फ़ाइलें हो भी सकती हैं या नहीं भी :) 17:11 <@frosk> वह बहुत बढ़िया चीज़ होगी 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> आशा है हम ऐसे हर तरह के "adapter" ऐप्स देखेंगे :) 17:12 <+Complication> खैर, मुझे यक़ीन है लोग बड़े फ़ाइलें भेजने के तरीके bit... उह, side channels से ढूँढ लेंगे :) 17:15 <@frosk> मुझे थोड़ा अपराधबोध होता है कि feedspace कोड अलग-अलग java1.5 फीचर्स का उपयोग करता है। अभी free java पर इसे compile/use करना शायद कठिन होगा, पर मुझे यक़ीन है यह पकड़ लेगा :) 17:15 <jrandom> ओह! 17:16 <jrandom> खैर, यह अफ़वाह है कि gcj, 1.5-विशेषताओं के लिए ecj अपनाने वाला है 17:16 <spinky> Complication: पोनी जिनकी काठी बैग hdds से भरी हों? 17:16 <@frosk> हाँ 17:17 <+Complication> spinky: मेरे पसंदीदा मामले में ड्रोन :P 17:17 * jrandom अभी भी मुश्किल से 1.4 की विशेषताओं तक जा रहा है 17:17 <+Complication> पर मुझे लगता है पोनी भी काम करेंगे :P 17:17 <jrandom> हालांकि 1.6 वाकई अच्छा है ;) 17:17 <@frosk> gcj-समर्थ रहने के लिए? 17:18 <@frosk> खैर, मेरी समझ से 1.6 में वैसे भी अधिकांश चीज़ों के लिए बहुत "isms" नहीं हैं :) 17:18 <+Complication> (या उड़ते हेजहॉग जो मेमोरी कार्ड्स एयरड्रॉप कर रहे हों) 17:18 <jrandom> gcj/classpath/etc, लेकिन प्रदर्शन के लिए भी (मुझे 1.5, 1.4 से थोड़ा भारी लगा) 17:19 <jrandom> सही, 1.6 के सुधार बड़े पैमाने पर VM/bytecode विशिष्ट हैं 17:19 <@frosk> हूँ, ठीक है 17:20 * jrandom आपको 1.5-विशेषताएँ न इस्तेमाल करने के लिए मनाने की कोशिश नहीं कर रहा। मुझे यक़ीन है आपके पास कारण हैं, और उदाहरण के लिए azureus पहले से ही 1.5 की माँग करता है 17:21 <@frosk> अब वापसी नहीं है :) उम्मीद है यह बहुत उबड़-खाबड़ नहीं होगा 17:24 <jrandom> हाँ, मुझे यक़ीन है यह ठीक चलेगा :) 17:25 <jrandom> ठीक है, बढ़िया, 3) feedspace पर किसी के पास और कुछ है? 17:25 * frosk अपने generics और java.util.concurrent को गले लगाता है ;) 17:25 <jrandom> हेहेह 17:27 <jrandom> ठीक है, यदि 3 पर और कुछ नहीं है, तो 4) ??? पर चलें 17:27 <jrandom> बैठक के लिए किसी के पास और कुछ है? 17:27 <+Complication> एक छोटा सवाल जो मुझे 2) के तहत पूछना चाहिए था 17:28 <+Complication> क्या आप जानते हैं, idle participating tunnels आम तौर पर कैसे बनते हैं? 17:28 <+Complication> क्या वे ज़्यादातर failed tunnel builds का संकेत हैं, जहाँ केवल बनाने वाले को ही सच में पता होता है कि यह फेल हुआ? 17:28 <+Complication> या उनके अतिरिक्त कारण भी हैं? 17:28 <+Complication> (बिल्कुल, स्पष्ट कारणों के अलावा - यानी कोई ऐप idle बैठा हो) 17:29 <jrandom> एक idle ऐप के idle tunnels नहीं होंगे (उनका परीक्षण किया जाएगा) 17:29 <jrandom> idle tunnels किसी न किसी कारण से विफल होते हैं 17:29 <jrandom> (या तो पूरी तरह से बनाए जाने में विफल, या संचालन के दौरान विफल) 17:30 <+Complication> सही, तो वैसे भी सभी tunnels का परीक्षण होता है, और tunnel परीक्षण से ट्रैफिक होना चाहिए... बिलकुल 17:30 <+Complication> इससे वास्तव में मेरे सवाल के दूसरे हिस्से पर आता हूँ: यदि पता चल जाए कि कोई tunnel idle है, तो क्या उसे जल्दी ही हटाने से कोई लाभ होगा? 17:31 <+Complication> क्या वहाँ कोई कीमती संसाधन बचेंगे? 17:32 <jrandom> नहीं - जो tunnel डेटा नहीं धक्का दे रहा वह संसाधन खर्च नहीं कर रहा 17:32 <jrandom> (ठीक है, यह कुछ ram ले रहा है, शायद 32 बाइट्स) 17:32 <+Complication> या शायद, क्या यह किसी router को अपने लोड और इसी तरह के पैरामीटर्स की बेहतर तस्वीर रखने में मदद कर सकता है... 17:33 <jrandom> tunnel history के आधार पर बैंडविड्थ उपयोग की भविष्यवाणियाँ निश्चित रूप से एक खुला प्रश्न हैं 17:33 <+Complication> या यह बस बेकार का काम होगा, और बेहतर यही होगा कि इसे स्वाभाविक रूप से expire होने दें? 17:33 <+Complication> (जैसा कि अभी होता है) 17:34 <jrandom> हम पहले कुछ भविष्यवाणियाँ करते थे, पर उससे हमें स्पष्ट लाभ नहीं मिला, इसलिए अब हम एक सरल एल्गोरिथ्म उपयोग कर रहे हैं 17:34 <+Complication> आह, तो कोई लाभ नहीं... 17:34 <+Complication> धन्यवाद, मुझे मूलतः इतना ही पूछना था :) 17:34 <jrandom> कोई बात नहीं, समझ में आने वाली चिंता है 17:34 <jrandom> ठीक है, बैठक के लिए किसी के पास और कुछ है? 17:35 <+Complication> हाँ, यदि कोई भविष्यवाणियाँ करे, तो idling tunnels का प्रतिशत अनुमानों को झुका सकता है 17:35 <+Complication> (यदि वह काफ़ी बदलता हो) 17:36 <jrandom> हाँ, हम idle % को अनुमान का हिस्सा बनाए रखना चाहेंगे 17:36 <jrandom> (हम पहले रखते थे - RouterThrottleImpl.allowTunnel method देखें) 17:37 <+Complication> ओह, यह नहीं पता था :) 17:37 <jrandom> और नया कमेंट देखें: 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication अभी भी फ़ाइल की ओर ब्राउज़ कर रहा है, पर धन्यवाद :) 17:39 <jrandom> w3rd 17:40 <jrandom> ठीक है, यदि बैठक के लिए और कुछ नहीं है... 17:40 * jrandom समेटता है 17:41 * jrandom *baf*s बैठक को बंद करता है