I2P डेवलपर बैठक - 22 फ़रवरी, 2005

13:04 <jrandom> 0) हाय 13:04 <jrandom> 1) 0.5 13:04 <jrandom> 2) अगले कदम 13:04 <jrandom> 3) azneti2p 13:04 <jrandom> 4) ??? 13:04 <jrandom> 0) हाय 13:04 * jrandom हाथ हिलाता है 13:05 <jrandom> साप्ताहिक स्थिति नोट्स यहाँ हैं @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html 13:05 <jrandom> (हाँ, मीटिंग से बस एक-दो मिनट पहले, तो ज़रा अपनी स्पीड रीडिंग परखिए) 13:05 <+detonate> मेरा ख्याल है मैं boondock saints डालने से पहले थोड़ा कम बग होने का इंतज़ार करूँगा, उस हिसाब से 13:06 <jrandom> क्यों... वो तो... वो तो... वो तो कॉपीराइट उल्लंघन है! 13:06 <+detonate> azureus beta में अजीब नए ऐडिशन्स 13:06 <+detonate> श्रेणियाँ 13:06 <+detonate> हाहा 13:06 <+detonate> एक DHT ट्रैकर 13:06 <+detonate> कमाल 13:07 <jrandom> हाँ, यह बहुत कूल लग रहा है, लेकिन 3 से पहले 1 और 2 पर चलते हैं, ठीक? ;) 13:07 <+detonate> हाय 13:07 <+detonate> बिलकुल 13:07 <jrandom> चलते हैं 1) 0.5 पर 13:07 <jrandom> मतलब, ये जारी हो चुका है, वगैरह 13:08 <cervantes> वाह! 13:08 <jrandom> आज शाम बाद में एक नया rev आएगा जिसमें कई अपडेट होंगे (वर्तमान CVS head 0.5-5 है, और -6 कुछ routers पर टेस्टिंग में है) 13:09 <jrandom> सब काफ़ी अच्छा चला है, मगर रास्ते में कुछ अजीब बग्स मिले। लेकिन c'est la vie 13:09 <frosk> मैं बता सकता हूँ कि 0.5-5, -4 से _काफी_ ज्यादा फ्रेंडली है (जो अक्सर मुझे भाग लेने वाले tunnels की गिनती हज़ारों में देता था) 13:09 <bla> jrandom: क्या 0.5.0.1 संस्करण उस समस्या को ठीक करेगा जिसमें destinations नहीं मिल पाते? 13:09 <jrandom> अच्छा, खैर, वो तो दूसरों पर भी निर्भर है, -0 build सच में सैकड़ों tunnels बनाता है 13:09 <bla> s/nor/not 13:10 <jrandom> bla: हाँ, वो netDb में एक बग है 13:10 <bla> jrandom: बढ़िया! 13:10 <jrandom> (खासतौर पर leaseSet publishing में) 13:11 <jrandom> और हाँ, 0.5.0.1 rev उस कभी‑कभार गायब हो जाने वाले proxy बग को हटा देगा 13:12 <jrandom> अभी भी एक अजीब memory leak है जिसे मैं पकड़ नहीं पाया, जो कुछ यूज़र्स को प्रभावित कर रहा है 13:12 <bla> तो कुल मिलाकर, इन बग्स के अलावा 0.5 नेटवर्क अच्छा काम कर रहा है। वाह! 13:12 <jrandom> जहाँ तक मुझे पता है, ये असल में केवल दो‑तीन I2PTunnel इंस्टेंस को ही प्रभावित कर रहा है 13:12 <Meomia> क्या 0.5 के बाद 0 से 130 भाग लेने वाले tunnels तक पहुँचना प्रगति की निशानी है? 13:13 <jrandom> वूट 13:13 <jrandom> Meomia: अरे, मेरे पास 5000 से ज़्यादा tunnels रहे हैं ;) 13:13 <jrandom> लेकिन dm ने वाकई exploratory pool code में एक बग ढूँढने में मदद की है, तो हम 'random' peers पर ज़्यादा बार tunnels बनाएँगे 13:14 <jrandom> (वाह) 13:14 <Meomia> ठीक है 13:14 <bla> jrandom: क्या इसका मतलब यह भी है कि अब, 0.4 के विपरीत, हर peer किसी समय आपका inbound gateway बन सकता है? 13:14 <jrandom> हाँ, exploratory tunnels के लिए 13:15 <jrandom> client tunnels केवल 'fast' tier के peers का ही उपयोग करेंगे 13:15 <bla> bla: ठीक है। यह अच्छा है कि client tunnels केवल fast peers का उपयोग करते हैं: नहीं तो, हमें वह गुमनामी वाली समस्या मिलती जो हमने पहले चर्चा की थी 13:16 <jrandom> और अन्यथा performance भी खराब हो जाएगी ;) 13:17 <jrandom> असल में, यह हमें 2) अगले कदम पर ले आता है 13:18 <jrandom> 0.5 श्रृंखला के लिए बड़ा काम यह रह गया है कि tunnels में उपयोग होने वाले peers को क्रमबद्ध करने और/या फ़िल्टर करने की कुछ रणनीतियाँ जोड़ी जाएँ 13:18 <godmode0> jrandom क्या i2p के साथ nntp उपयोग कर सकते हैं ? 13:18 <jrandom> godmode0: हाँ, i2p पर दो NNTP servers हैं। फ़ोरम देखें 13:19 <godmode0> jrandom ठीक है, मैं टेस्ट कर रहा हूँ 13:19 <godmode0> क्या मैं अपना server भी चला सकता/सकती हूँ ? 13:20 <jrandom> godmode0: हम अभी मीटिंग में हैं, लेकिन हाँ, आप एक server चला सकते हैं 13:20 <godmode0> jrandom ठीक है, माफ़ कीजिए 13:20 <jrandom> कोई बात नहीं 13:20 <jrandom> जो रणनीतियाँ पोस्ट की गई हैं वे मूलतः anonymity को बेहतर करने पर केंद्रित हैं, पर वहाँ कुछ और लक्ष्य भी हैं जिनका संतुलन किया जा सकता है 13:21 <jrandom> शायद हम चयन में कुछ AS paths को शामिल करने का तरीका निकाल सकें, जैसा bla ने सुझाव दिया था 13:22 <jrandom> इससे (jurisdictional) anonymity बेहतर हो सकती है, और अगर हम किसी एक AS (या दो) के भीतर रहने की कोशिश करें, तो performance भी बेहतर हो सकती है 13:22 <bla> jrandom: यह मूलतः Tor के निर्माताओं के एक पेपर से संबंधित है: http://theland.i2p/files/routing-zones.pdf 13:22 <jrandom> हाँ 13:23 <jrandom> कई तरह की रणनीतियाँ हैं जिन्हें लोग उपयोग कर सकते हैं, और नई रणनीतियाँ आज़माना भी काफी आसान होना चाहिए 13:24 <jrandom> हम हर आइडिया को लागू करने में महीनों नहीं लगाएंगे, बल्कि अधिकतर लोगों की ज़रूरत के बेसिक्स ही देंगे। जो भी नए जोड़ना चाहता है, उसे उन्हें प्लग-इन करने में मदद करने के लिए प्रोत्साहित किया जाता है 13:25 <jrandom> खैर, एक बार बेसिक्स तैयार हो जाएँ, तो हम 0.6 के लिए UDP transport पर ध्यान केंद्रित करेंगे 13:26 <jrandom> 2) अगले कदम के लिए मेरे पास इतना ही है, किसी के पास कोई टिप्पणी/प्रश्न/चिंता? 13:26 <bla> जो लोग I2P में देखना शुरू कर रहे थे, वे कौन थे, फिर से? 13:26 <bla> लगता है हाल में उनसे ज़्यादा सुनने को नहीं मिला। 13:27 <bla> s/into I2P/into UDP/ 13:27 <bla> माफ़ कीजिए 13:27 <jrandom> अच्छा, mule बीमार रहा है, हालांकि मुझे लगता है detonate प्रगति कर रहा है 13:28 <jrandom> detonate: कोई खबर? 13:29 <jrandom> या शायद नहीं ;) 13:30 <jrandom> ठीक है, 3) azneti2p पर चलते हैं 13:30 <+detonate> सॉरी 13:30 <+detonate> मैं प्रगति कर रहा/रही हूँ 13:30 <+detonate> मुझे अभी re-assembly वाले हिस्से को पूरा करना है 13:31 <+detonate> जहाँ तक data को packets में बाँटकर व्यवस्थित तरीके से भेजने की बात है, वह काम करता है 13:31 <+detonate> 3) पर आगे 13:31 <jrandom> जबर्दस्त 13:31 <godmode0> सॉरी, चरण 2) i2p में हमलों (attacks) से कोई समस्या है ? 13:31 <bla> detonate: कूल! क्या आप हम सबको फ़ोरम पर अपडेट देते रहेंगे? 13:32 <+detonate> bla: ज़रूर 13:32 <tracker> azneti2p के बारे में, यहाँ देखें: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 लगता है डाउनलोडिंग काम कर रही है, seeding नहीं। 13:32 <jrandom> godmode0: अलग-अलग ordering रणनीतियाँ यूज़र को predecessor attacks के प्रभाव का चयन करने देंगी 13:33 <microsoft> जो भी i2p.net चलाता है उसे पेज पर और Enterprise Class Solutions जैसे बज़वर्ड्स जोड़ने चाहिए। 13:33 <+detonate> किसी को यह भी सुनिश्चित करना होगा कि नया DHT ट्रैकर azureus प्लगइन के संदर्भ में गलत व्यवहार नहीं कर रहा 13:33 <tracker> मेरे लोकल टेस्ट यह साबित करते लगते हैं, मैं azureus से डाउनलोड कर सकता हूँ लेकिन seed नहीं कर पाता। 13:34 <jrandom> हम्म, ठीक है कूल, धन्यवाद tracker - मुझे पता है उन्होंने कुछ चीज़ें अपडेट कीं और कल रात b34 जारी किया, पर लगता है अभी और काम बाकी है 13:34 <jrandom> detonate: अच्छी बात 13:35 <tracker> अच्छी बात detonate, मेरे यहाँ DHT डिसेबल है क्योंकि azureus एक्टिव होने पर कुछ घंटों बाद 100% CPU उपयोग के साथ क्रैश हो जाता है। 13:35 * jrandom यह दोहराना चाहेगा कि azneti2p प्लगइन अभी काफ़ी शुरुआती बीटा में है, और azureus की anonymity संबंधी बातों का पूर्ण ऑडिट नहीं हुआ है 13:36 <jrandom> जहाँ मुझे यक़ीन है कि वे लोगों को इसे टेस्ट करते देखना पसंद करेंगे, वहीं जिन्हें anonymity की ज़रूरत है वे सावधानी बरतना चाहेंगे 13:36 <tracker> दूसरी तरफ, i2p-bt बहुत अच्छा काम करता है। सिवाय इसके कि यह tunnels बंद नहीं करता, लेकिन मेरी राय में (IMHO) यह बहुत बुरा नहीं है। 13:37 <jrandom> ओह, क्या यह अभी भी आपके यहाँ हो रहा है tracker? मैं उसे reproduce नहीं कर पाया हूँ 13:37 <jrandom> आप 0.1.7 rev पर हैं, सही? 13:37 <tracker> हाँ, हूँ। 13:38 <jrandom> ठीक है, बढ़िया। अगर यह आपके यहाँ हमेशा होता है तो मीटिंग के बाद कारण ढूँढने में मदद के लिए आपसे विस्तार से बात करना चाहूँगा 13:39 <tracker> शायद यह linux या unix की जगह XP पर चलाने से संबंधित है। tunnel बंद करना azureus के साथ काम करता है, तो मेरा अनुमान है यह I2P-BT से संबंधित है। 13:39 <jrandom> हम्म, सही, i2p-bt SAM का उपयोग करता है, जबकि azureus सीधे i2p SDK का उपयोग करता है 13:40 <tracker> वैसे, मैंने आपको फ़ोरम पर एक bug-report भेजा है। I2P के नवीनतम CVS builds पर timestamper मर जाता है। 13:40 <jrandom> आह, बढ़िया, धन्यवाद, मैंने आज वहाँ अपने PMs नहीं देखे हैं 13:41 <jrandom> -5 पर या -4? या इससे पहले? 13:42 <jrandom> आह, -4। ठीक है, बढ़िया 13:42 <jrandom> धन्यवाद, मैं इसे 0.5.0.1 के लिए ठीक कर दूँगा 13:42 <jrandom> ठीक है, 3) azneti2p के लिए किसी के पास और कुछ है? 13:43 <tracker> यह -5 पर भी हो रहा है 13:43 <jrandom> आपने sntp server स्पष्ट रूप से निर्धारित किया है, ठीक? 13:44 <tracker> हाँ। हमारे देश के वे 2 वाले। 13:44 <jrandom> मैंने अभी source देखा और exception तब आती है जब concurrent servers की संख्या (#) (default = 3) निर्दिष्ट servers की संख्या (#) से अधिक हो जाती है (नए default में 3 है) 13:44 <jrandom> ठीक है, बढ़िया, यह % # servers का साधारण फिक्स है 13:45 <jrandom> ठीक है, यदि azneti2p के लिए और कुछ नहीं, तो चलते हैं पुराने अच्छे 4) ??? पर 13:46 <jrandom> किसी और के पास मीटिंग में उठाने के लिए कुछ है? 13:46 <tracker> अच्छा। मैंने अभी फ़ोरम पर i2p-bt बंद करते समय router से आए log errors आपको भेजे हैं। 13:47 <jrandom> 'k कूल, धन्यवाद 13:47 <cervantes> यह कहने के अलावा कुछ नहीं: 0.5 रोलआउट पर बढ़िया काम, बग्स ठीक होते ही यह जबर्दस्त चलेगा लगता है 13:48 <tracker> हाँ, नवीनतम CVS builds यहाँ वाकई अच्छा प्रदर्शन कर रहे हैं। 13:48 <jrandom> धन्यवाद, आपकी और बाकी 0.5-pre testers की मदद से हम कई मुद्दे साफ़ कर पाए 13:49 <jrandom> प्रदर्शन मेरी उम्मीद से बेहतर रहा है, हालांकि throughput पहले जितना ऊँचा नहीं है। अभी बहुत कुछ optimize करना बाकी है 13:49 <cervantes> अजीब है कि pre वर्ज़न मेरे लिए ज़्यादा स्थिर थे...पर तब, मैं उन्हें एक अलग मशीन पर चला रहा था ;-) 13:49 <jrandom> (और ये कम्बख्त बग्स, ताकि reliability वहीं पहुँचे जहाँ होनी चाहिए) 13:50 <jrandom> हेह, हाँ, लेकिन -pre नेटवर्क 5-7 routers का था, सभी बेहद भरोसेमंद, बहुत ही तेज़ connections पर 13:50 <cervantes> :) 13:51 <cervantes> मुझे 0.6 pre टेस्ट के लिए साइन अप कर दीजिए :) 13:51 <jrandom> हेह 13:51 <tracker> शायद मुझे अगले pre नेटवर्क में हिस्सा लेना चाहिए। एक बहुत अविश्वसनीय और धीला connection प्रदान करते हुए ;). 13:51 <jrandom> उम्मीद है 0.6 migration और आसान होगा, क्योंकि हम बस नए router addresses को routerInfo में जोड़ पाएँगे (UDP addresses) 13:51 <jrandom> हेह, सही बात 13:51 <cervantes> मैं अपना 1TB फ़ाइल शेयर ऑनलाइन डाल सकता/सकती हूँ... 13:52 <jrandom> 0.6 टेस्टिंग में हमें निश्चित रूप से बहुत मदद चाहिए होगी, विभिन्न तरह के नेटवर्क सेटअप्स के साथ 13:52 <hobbs> ssh '~C' command कमाल का है 13:52 <laberhorst> क्या यह एक और अनुकूलता‑विहीन कदम होगा? 13:53 <Myo9> क्या किसी को पता है कि कौन से nntp servers चालू हैं? 13:53 <jrandom> laberhorst: नहीं, 0.6 backwards compatible होगा 13:53 <jrandom> Myo9: पता नहीं, वे चालू हों और बस 0.5-0 बग्स से प्रभावित हों 13:54 <jrandom> 0.5.0.1 rev कई मुद्दे ठीक कर देगा, और एक बार यह आ जाए, अपग्रेड करना अत्यधिक अनुशंसित होगा 13:54 <laberhorst> तो बस एक टेस्ट 0.6 बनाइए और टेस्टर्स को दीजिए 13:54 <cervantes> हम BT ट्रैफ़िक को केवल outdated routers पर चलवा सकते हैं...उससे लोग अपग्रेड करने के लिए प्रेरित होंगे ;-) 13:54 <laberhorst> तो कल बड़ी अपग्रेड पार्टी 13:54 <jrandom> जब यह तैयार होगा, तो फ़ोरम और लिस्ट पर घोषणा होगी 13:54 <jrandom> सही laberhorst 13:54 <jrandom> हेह cervantes ;) 13:55 <laberhorst> *आपके लिए टेस्टिंग करने को उत्सुक हूँ* 13:55 <jrandom> 0.5 पर BT performance काफ़ी अच्छी रही है, मैंने trackers पर बहुत से सफल बड़े फ़ाइल ट्रांसफ़र्स देखे हैं 13:55 <laberhorst> pload rate: 8.85 kB/s 13:55 <jrandom> (और irc पहले की तरह प्रभावित नहीं हुआ है, duck के tunnel की समस्याओं से इतर) 13:55 <tracker> यह इस पर निर्भर करता है कि आप 'बड़ा' किसे कहते हैं ;) 13:56 <jrandom> tracker: मैं एक विशेष 874MB फ़ाइल के बारे में सोच रहा हूँ जिसके कई सफल डाउनलोड हुए हैं ;) 13:56 <jrandom> लेकिन यह सच है, कुछ लोगों के लिए वह छोटा है 13:56 <laberhorst> बस पुरानी अच्छी पोर्न 13:56 <laberhorst> मेरा अनुमान ;-) 13:57 <laberhorst> आशा है कि कल से मेरा router >3000 tunnels में भाग नहीं लेगा 13:57 <tracker> ठीक है, वह बड़ा है। 13:57 <laberhorst> या, यदि ऐसा है, तो नेटवर्क वाकई बड़ा है 13:57 <jrandom> हेह laberhorst 13:58 <jrandom> ठीक है, मीटिंग के लिए किसी के पास और कुछ है? 13:58 <laberhorst> वैसे, क्या >3000 में भाग लेना i2p में तेज़ connection वाले अच्छे, भरोसेमंद router का पर्याय है? 13:58 <+detonate> मैं आज रात House देखने के बाद boondock saints अपलोड करूँगा :) 13:59 <+detonate> वह अच्छा खासा 4.1GB होगा :) 13:59 * laberhorst तेज़ी से बग्स मारने के लिए डेवलपर्स को धन्यवाद देना चाहता/चाहती है 13:59 <+detonate> लगता है बहुत मांग है 13:59 <laberhorst> ओह, यहाँ कुछ DVD images भी हैं, 13:59 <hobbs> detonate: ओह, सही। House. :) 13:59 <tracker> cervantes, क्या आपने पहले ही phpBB 2.0.12 पर अपग्रेड कर लिया? 13:59 <laberhorst> लेकिन 0.5.0.1 आने तक इंतज़ार करें 13:59 <+detonate> 0.5.0.1 को अच्छा‑सा शेकडाउन भी मिल जाएगा 14:00 <+detonate> हाँ 14:00 <+detonate> मेरा इरादा है 14:00 <jrandom> बेशक, केवल वे लोग जिन्हें उन फ़ाइलों की कानूनी प्रतियाँ पहले से प्राप्त हैं, उन्हें डाउनलोड करें। यह सिर्फ़ टेस्टिंग के लिए है 14:00 <jrandom> *खाँसी* 14:00 <tracker> rofl 14:01 * jrandom mpaa.i2p नोट करता है 14:01 <+detonate> हेह 14:01 <laberhorst> ओह, मैं debian, fedora, suse, मेरी खींची तस्वीरों से iso images बना सकता/सकती हूँ,... 14:01 <laberhorst> तो काफ़ी सारा वैध मैटेरियल 14:01 <laberhorst> अगर आप सिर्फ़ टेस्ट करना चाहते हैं, तो /dev/random बहुत बड़ा है 14:01 <Ragnarok> हमेशा नहीं 14:02 <laberhorst> वैसे, अकेले वीकेंड्स के लिए: cat /dev/random | grep linux :-) 14:02 <jrandom> हेह 14:02 <frosk> /dev/random अक्सर खाली हो जाता है, मुझे /dev/urandom पसंद है :) 14:02 <frosk> या नया, बेहतर /dev/jrandom 14:02 <jrandom> नहीं, वह हर समय core dump कर देता है 14:03 <jrandom> और उसे रात की आराम भी चाहिए 14:03 <Ragnarok> /dev/random के लिए entropy बनाने का सबसे अच्छा तरीका क्या है? 14:03 <laberhorst> हमें सच में "get jrandom a few beers" फंड बनाना चाहिए 14:03 <frosk> उसे आराम कहें या entropy इकट्ठा करना :) 14:03 <hobbs> Ragnarok: यह इस पर निर्भर करता है कि आपका मतलब क्या है। एक हार्डवेयर RNG लेना कमोबेश "सबसे अच्छा" तरीका होगा :) 14:03 <jrandom> Ragnarok: आपके OS पर निर्भर करता है (और क्या आपके पास हार्डवेयर है ;) 14:04 <tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Allways nice ;) 14:04 <jrandom> हम वास्तव में आने वाले किसी build में fortuna implementation जोड़ेंगे, और अलग‑अलग entropy sources ढूँढनी पड़ेंगी 14:04 <Ragnarok> हार्डवेयर के बिना :P 14:04 <susi23> . o O ( मैंने सोचा था i2p उपयोग करने वाला कोई जानता होगा कि उसे /dev/urandom क्यों नहीं इस्तेमाल करना चाहिए ) 14:05 <cervantes> tracker: 2.0.12 में कवर किए गए security exploits मेरे mod_rocinante से अनजाने में ही फिक्स हो जाते हैं, इसलिए मैंने अभी अपग्रेड करने की ज़हमत नहीं उठाई 14:05 <hobbs> susi23: जब यह सिर्फ़ शरारत के लिए हो, तो मुझे लगता है ठीक है ;) 14:05 <ant> <Nolar> यहाँ python BT port कौन करता है? 14:05 <jrandom> Nolar: वह duck है 14:06 * duck सीटी बजाता/बजाती है 14:06 <ant> <Nolar> duck: आपने लोगों ने request block size 128k क्यों कर दिया? 14:06 <susi23> . o O ( अगला सुझाव देता है: while true; do echo $RANDOM>> largefile; done ) 14:06 <ant> <Nolar> इसलिए az आपको seed नहीं कर सकता 14:06 <tracker> cervantes: ठीक है 14:06 <ant> <Nolar> हम requests> 64k ब्लॉक करते हैं 14:06 <laberhorst> कमाल है, मुझे और mp3 चाहिए 14:06 <frosk> susi23: एक खाली शाम में linux grep करने के लिए /dev/urandom बिलकुल ठीक है :) 14:07 <jrandom> अच्छा, क्या आप हमेशा से ऐसा करते थे? iirc i2p-bt कुछ समय से 128k इस्तेमाल कर रहा है 14:08 <ant> <Nolar> हाँ, शुरुआत से ही ऐसा है :) 14:08 <ant> <Nolar> क्या 128 उपयोग करने का कोई कारण है? 14:08 <ant> * duck cvs log देखता/देखती है 14:08 <jrandom> pipeline भरी रहती है, i2p में कुछ lag होता है ;) 14:08 <jrandom> 32KB के साथ, यह मूलतः 1 का fixed window size हो जाता है 14:09 <jrandom> तो हर message ACK का इंतज़ार करता हुआ ब्लॉक हो जाता है, जबकि 128KB rtt में 4 messages को उड़ने देता है 14:09 <@duck> सही, BT specs के अनुसार अधिकतम allowed slice size 14:09 <ant> <Nolar> खैर, इससे निपटने के दो तरीके हैं: 1) हम अपनी तरफ से लिमिट 128k तक बढ़ा दें, या 2) आप बस और ज़्यादा requests को pipeline करें 14:09 <cervantes> i2pbt पहले से थोड़ा तेज़ है... शायद आप इसे घटा सकते हैं... 14:10 <@duck> schni, schna, schnappi 14:10 <ant> <Nolar> तो, एक 128k request की बजाय, उदाहरण के लिए दो 64k requests भेजें 14:10 <hobbs> duck: haha... वह चीज़ दुनिया भर में फैल गई है। 14:10 <@duck> आप 128k क्यों ब्लॉक करते हैं? 14:11 <cervantes> *सिहरन* यूरोपॉप 14:11 <laberhorst> duck: कृपया चुप रहें नहीं तो मैं आपको गिरा दूँगा! 14:11 <tracker> कभी‑कभी मुझे अफसोस होता है कि मैंने कुछ साल पहले जर्मन सीखी थी... 14:11 <laberhorst> नहीं यूरोपॉप, सच में पॉप नहीं 14:11 * cervantes UK को आदेश देता/देती है कि ऐसा गाना चार्ट्स में आने से पहले घुसपैठ रोक दे 14:11 <laberhorst> tracker: मतलब नहीं, ठीक है 14:12 <ant> <duck> अब यह (2^17)-13 है 14:12 <ant> <Nolar> duck: खैर, लिमिट काफी समय से है, पर एक अच्छा कारण यह है कि 128K ब्लॉक्स अपलोड करने में समय लगता है.....16KB (हमारा डिफॉल्ट) ज़्यादा सूक्ष्म request नियंत्रण देता है 14:12 <ant> <duck> 13 bytes bittorrent command की लंबाई है 14:12 <ant> <duck> (2^16)-13 पर मुझे कोई समस्या नहीं 14:12 <laberhorst> कुछ म्यूज़िक वाकई हास्यास्पद है, लेकिन असली इंडस्ट्रियल म्यूज़िक, उफ्फ, नहीं 14:13 <ant> <duck> या default पर वापस जाएँ? 14:13 <jrandom> इसे 64KB करना सबसे आसान लगता है (क्या वह atm एक CLI पैराम है?) 14:13 <ant> <duck> --download_slice_size 14:14 <ant> <Nolar> खैर, मेरा सवाल है, क्या आपके पास 128K ब्लॉक्स पर टिके रहने का कोई ठोस कारण है, जो मुझे थोड़ा बड़ा लगता है, खासकर i2p के लिए 14:14 <ant> <Nolar> सिर्फ़ कई छोटे requests को pipeline करने के बजाय? 14:14 <ant> <duck> मेरे पास कोई कारण नहीं। 14:14 <tracker> laberhorst: कभी‑कभी मैं सैटेलाइट से कुछ जर्मन चैनल पकड़ लेता हूँ। ख़ासकर viva और वह "Theater Kanal" वाकई खौफनाक हैं... 14:15 <ant> <Nolar> बड़े blocks की एक समस्या यह है कि एक बार मैं आपको choke कर दूँ, तो भी मुझे वह 128k chunk भेजना पूरा करना पड़ता है 14:15 <jrandom> मुझे याद नहीं कि vanilla bt pipeline करना जानता है या नहीं, पर यह पर्याप्त सरल होना चाहिए (खासकर क्योंकि मैं यह नहीं कर रहा ;) 14:15 <ant> <Nolar> जिसमें समय लग सकता है 14:15 <laberhorst> tracker: viva सिर्फ़ "hard rock" समय में दिलचस्प है, बाकी समय "please ignore", और theater, मुझे नहीं पता 14:15 <jrandom> i2p में, 128KB वास्तव में इतना बड़ा नहीं है, क्योंकि यहाँ सेकंड्स के ऑर्डर का एक अंतर्निहित lag होता है 14:15 <ant> <Nolar> जो chunk/unchoke के साथ गड़बड़ कर सकता है 14:16 <@duck> jrandom: क्या अभी भी bittorrent के 13 byte overhead को घटाना समझ में आता है ताकि यह SAM message में फिट हो जाए? 14:16 <jrandom> duck: नहीं, क्योंकि streaming lib पहले से ही इसे 16KB messages में और घटा देती है, तो इसे 64KB ही रहने दें 14:17 <@duck> ठीक है, 2**16 ही सही 14:17 <jrandom> (और फिर tunnels उन 16KB messages को 996 byte fragments में तोड़ देते हैं..) 14:17 <ant> <Nolar> 128k की समस्या है कि अगर मैं, मान लीजिए, 12 k/s पर अपलोड कर रहा हूँ, तो वह ब्लॉक पूरा करने में 10+ सेकंड लगेंगे 14:18 <cervantes> वाह, यह तो लगभग उतना ही लंबा है जितना irc पर lag... 14:18 <jrandom> जो 1-10 RTTs है (जबकि सामान्य नेट पर, 10-500) 14:18 <+detonate> मैं 512K blocks उपयोग करने के लिए पूरी तरह तैयार था/थी 14:18 <ant> <Nolar> आप 16KB blocks की pipelining के साथ भी प्रयोग कर सकते हैं 14:18 <jrandom> हेह 14:18 <+detonate> तो 64 preferred है? 14:19 <ant> <Nolar> सभी bt clients afaik 16KB blocks उपयोग करते हैं 14:19 <ant> <duck> CVS में फिक्स कर दिया; 14:19 <jrandom> जबर्दस्त, धन्यवाद duck! (और Nolar!) 14:19 <ant> <duck> उम्मीद करें यह 0.1.8 रिलीज़ में कुछ sam i2cp ट्यूनिंग के साथ दिखेगा 14:19 <tracker> laberhorst: इसका पूरा नाम "ZDF Theater" या ऐसा ही कुछ है। और खैर वे कहते हैं कि वे उच्च स्तरीय सांस्कृतिक कार्यक्रम भेजते हैं। मुझे सच में उम्मीद है कि जो वे भेजते हैं वह जर्मन संस्कृति का सर्वश्रेष्ठ नहीं है ;) 14:19 <jrandom> ठीक है, हेह, अभी याद आया कि हम अभी भी मीटिंग में हैं 14:19 <jrandom> मीटिंग के लिए किसी और के पास कुछ है? 14:20 <ant> <Nolar> तो अगर हमें 128k chunk चाहिए, तो हम बस 8 simultaneous requests बना देते हैं 14:20 <susi23> . o O ( और बची 448 bytes फेंक दें? ) 14:20 <jrandom> हाँ, हाँ 14:20 <laberhorst> tracker: ओह, वह छोटा साइड चैनल है... arte या 3sat वाकई ज़्यादा दिलचस्प हैं 14:20 <laberhorst> और arte जर्मन/फ़्रेंच है :-) 14:20 <ant> <Nolar> यदि uploader ऐसी request भर सकता है, तो पूरा 128k i2p pipe stream में धकेल दिया जाना चाहिए 14:20 <jrandom> कूल 14:21 <cervantes> . o O ( सोच रहा है कि उसे susi की सारी सोच सुनाई क्यों दे रही है ) 14:21 <ant> <Nolar> तो 16KB बनाम 32KB बनाम 64KB block sizes के साथ प्रयोग करना फायदेमंद हो सकता है 14:21 <jrandom> हाँ 14:21 <jrandom> जब तक यह pipelined है, i2p को फर्क नहीं पड़ता 14:21 <ant> <Nolar> बहुत बढ़िया 14:22 <jrandom> हालाँकि 16KB पर बिना pipelines के स्पीड काफ़ी खराब होती है, या कम से कम पहले तो थी 14:22 <tracker> laberhorst: ठीक है, मैं अगले दिनों में arte पकड़ने की कोशिश करूँगा... 14:22 <ant> <duck> मैं सुझाव दूँगा कि यह ट्यूनिंग 0.2 के लिए छोड़ दें 14:22 <ant> <duck> क्योंकि इसमें bittorrent 3.9.1 सुधार शामिल होंगे 14:22 <jrandom> हाँ, DTSTTCPW 14:22 <susi23> . o O ( ओह यह आसान है... लोग बहुत अनुमानित होते हैं... ) 14:23 <ant> <duck> जो network code को पूरी तरह से पुनर्संरचित कर सकता है 14:23 <cervantes> http://www.gavelstore.com 14:24 <jrandom> ठीक है, फिलहाल इतना ही, लोगों को कुछ घंटों में लिस्ट और साइट देखनी चाहिए क्योंकि 0.5.0.1 rev जल्द ही आ रहा है 14:24 <ant> <Nolar> हाँ, मैं समझ सकता हूँ कि अकेली 16KB requests धीमी होंगी 14:24 * jrandom एक gavel डाउनलोड करता है 14:24 * jrandom *baf* कर के मीटिंग ख़त्म करता है