I2P डेवलपर बैठक - 06 दिसंबर, 2005

15:26 <jrandom> 0) हाय 15:26 <jrandom> 1) 0.6.1.7 और नेटवर्क स्थिति 15:26 <jrandom> 2) प्रायोगिक tunnel विफलताएँ 15:26 <jrandom> 3) SSU और NATs 15:26 <jrandom> 4) Syndie 15:26 <jrandom> 5) ??? 15:26 <jrandom> 0) हाय 15:26 * jrandom हाथ हिलाता है 15:26 <jrandom> साप्ताहिक स्थिति नोट्स http://dev.i2p.net/pipermail/i2p/2005-December/001237.html पर पोस्ट किए गए हैं 15:26 * ailouros ने नोट्स पढ़ लिए 15:27 * jrandom देर हो गई है, तो मैं आप सबको पढ़ने के लिए एक पल दे देता हूँ :) 15:29 <jrandom> ठीक है, चलिए 1) 0.6.1.7 और नेटवर्क स्थिति से शुरू करते हैं 15:29 <@cervantes> *खाँसी* 15:29 <jrandom> इस विषय पर मेल में जो है, उससे अधिक जोड़ने के लिए मेरे पास बहुत कुछ नहीं है। क्या किसी के पास और टिप्पणियाँ/प्रश्न/विचार हैं? 15:30 <Pseudonym> लगता है कि tunnel creation के एल्गो को बदलने से पहले प्रदर्शन अनुकूलन करना उल्टा क्रम हो सकता है 15:30 <gott> मुझे बहुत सारे "No HTTP method found in the request. 15:30 <gott> Software caused connection abort: socket write error 15:30 <gott> " मिल रहे हैं 15:30 <@modulus> tunnel lag काफी कम है, पता नहीं आपने कुछ बदलाव किए हैं या मेरा ISP अचानक बेहतर हो गया है। 15:30 <gott> I2PTunnel Webmanager से 15:31 <jrandom> gott: इससे खराब HTTP अनुरोधों का संकेत मिलता है, या ऐसी चीजें जिन्हें eepproxy समझ नहीं सका 15:31 <jrandom> modulus: कूल, हम चीज़ों में सुधार के लिए बहुत कुछ कर रहे हैं 15:31 <jrandom> Pseudonym: अभी तक tunnel creation हमारी बाधा नहीं रही है - बाधा उच्च-स्तरीय चीज़ों में थी 15:32 <jrandom> दूसरी ओर, पिछली कुछ संशोधनों की सुधारों ने नीचे कुछ मुद्दे उजागर किए हैं 15:32 <Pseudonym> ओह, तो अनुकूलन कोड के अन्य हिस्सों से संबंधित रहा है? 15:32 <Pseudonym> कूल 15:33 <jrandom> हाँ, SSU स्तर पर, और tunnel operation स्तर पर भी। tunnel creation एक प्रदर्शन-संवेदनशील ऑपरेशन नहीं है [सिवाय जब यह होता है ;] 15:34 <jrandom> फिर भी मैं लाइव नेटवर्क लोड टेस्टिंग कर रहा हूँ, विभिन्न peers के गैर-अनाम लोड आँकड़े जुटा रहा हूँ ताकि चीज़ों को और संकुचित किया जा सके 15:34 <ailouros> मुझे आश्चर्य है कि कभी-कभी मैं किसी destination के लिए कॉन्फ़िगर किए गए से अधिक tunnels क्यों देखता हूँ (जैसे eeProxy, inbound 7 tunnels 4 outbound) 15:34 <jrandom> तो, अगले कुछ दिनों में जब आप router 7xgV को बहुत सारा डेटा ट्रांसफर करते देखें, तो ध्यान न दें ;) 15:35 <jrandom> ailouros: जब tunnel creation में समय लगता है, तो यह एहतियातन कुछ अतिरिक्त भी बनाता है। 15:35 <jrandom> zzz ने उस मोर्चे पर कुछ अजीब मुद्दों का भी ज़िक्र किया है, और चीज़ों में थोड़ा सुधार लाने के लिए एक patch पर काम चल रहा है 15:35 <ailouros> समझ गया.. लेकिन फिर वे सभी एक ही समय पर समाप्त क्यों हो जाते हैं? 15:35 <@cervantes> jrandom: जिज्ञासा बस, आपने वे टेस्ट कब शुरू किए? 15:35 <jrandom> cervantes: कुछ दिन पहले 15:36 <@cervantes> आह बढ़िया, तो वह _नहीं_ है ;-) 15:36 <jrandom> पता नहीं, ailouros, यह कुछ शर्तों पर निर्भर करता है। लेकिन tunnel creation कोड में कुछ... *खाँसी* अजीब चीजें हैं, जिनसे छेड़छाड़ मैं टाल रहा हूँ क्योंकि यह 0.6.2 के लिए फिर से लिखा जा रहा है 15:38 <ailouros> समझ गया। मैंने सोचा था यह नीति का मामला है... मैं चाहूँगा कि tunnels अलग-अलग समय पर समाप्त हों, जब तक कि ऐसा न करने का कोई अच्छा कारण न हो 15:38 <ailouros> यानी tunnel creations स्क्यूड हों 15:39 <jrandom> हाँ, 0.6.2 में बेहतर randomization होगा, और zzz का patch वर्तमान rev के लिए भी कुछ randomization जोड़ता है 15:40 <+Complication> सोच रहा हूँ कि अन्यथा सामान्य i2phex का एक instance... हर दूसरे बार स्टार्ट करने पर फाइलों को फिर से हैश करने का निर्णय क्यों करेगा? 15:40 <jrandom> जरा भी अंदाज़ा नहीं 15:40 <+Complication> अब तक संभावित कारण खराब configuration लगता है, लेकिन मैंने अपना config अभी नहीं हटाया है। 15:40 <jrandom> शायद timestamps स्क्यूड हैं? 15:42 <+Complication> नहीं, वे भी सही लगते हैं 15:42 * jrandom को पता नहीं। phex के उस हिस्से के कोड को कभी नहीं देखा 15:42 <jrandom> अरे, code 15:42 <+Complication> देखता हूँ कि पुराने config फाइलें हटाने से कोई फ़ायदा होता है या नहीं 15:42 <jrandom> कूल 15:43 <jrandom> ठीक है, 1) नेटवर्क स्थिति / 0.6.1.7 पर और कुछ? 15:43 <jrandom> अगर नहीं, तो 2) प्रायोगिक tunnel विफलताओं पर चलते हैं 15:44 <jrandom> हम इस पर थोड़ा बात कर चुके हैं, और नोट्स तथा zzz.i2p पर और जानकारी है 15:44 <jrandom> zzz: क्या आप कुछ जोड़ना/उठाना चाहते हैं? 15:46 <jrandom> यदि नहीं, तो 3) SSU और NATs पर चलते हैं 15:46 <jrandom> bar: कुछ जोड़ना चाहेंगे? 15:46 <+bar> नहीं, मेल में जो है उसके अलावा जोड़ने के लिए कुछ नहीं 15:47 <jrandom> कूल, हाँ मुझे अभी कुछ विवरणों पर जवाब देना है - मुझे लगता है हमारी retransmission पहले से ही आपके उठाए कुछ मुद्दों को संभाल लेगी 15:48 <jrandom> चाल यह जानने की होगी कि कौन-सी स्थिति लागू है, ताकि हम सही प्रक्रिया को स्वचालित कर सकें (या उपयोगकर्ता को बता दें कि वे फँस गए हैं) 15:48 <+bar> सब समय पर, कोई जल्दी नहीं 15:49 <+bar> हाँ, मैंने फिलहाल उस समस्या से बचने के लिए एक manual user setting का सुझाव दिया, शायद यह संभव न हो, पर हम बाद में चर्चा कर सकते हैं 15:50 <jrandom> हाँ, manual overrides मदद करेंगे, लेकिन शुरुआती i2p revs के साथ मेरा अनुभव यह था कि हर कोई (*हर कोई*) उसे बिगाड़ बैठा ;) इसलिए ऑटोमेशन बेहतर है 15:50 <jrandom> (हर कोई यानी मैं भी शामिल ;) 15:52 <+bar> सहमत 15:52 <ailouros> lol अगर मैंने भी ऐसा किया, तो docs में कुछ गड़बड़ी थी, क्योंकि मैंने उन्हें एक-एक कदम करके फॉलो किया था :D 15:53 <+bar> इसी बीच, मैं peer testing का अध्ययन करने में समय दूँगा 15:53 <jrandom> कूल, धन्यवाद bar! 15:54 <+bar> (शायद मैं उसके बारे में कुछ बेकार spam भी पैदा कर दूँ :) 15:54 <jrandom> :) 15:55 <jrandom> ठीक है, अगर 3) पर और कुछ नहीं, तो 4) Syndie पर चलते हैं 15:56 <jrandom> हाल में इस मोर्चे पर काफी प्रगति हुई है, 0.6.1.7 के आने के बाद से UI में काफी बड़े बदलाव हुए हैं 15:57 <jrandom> एक नया standalone install/build भी है, हालांकि हम सभी के पास i2p इंस्टॉल है, इसलिए हमें अलग से इसकी ज़रूरत नहीं 15:57 <ailouros> मुझे 6.1.7 का लेआउट 6.1.6 की तुलना में इस्तेमाल करने में कठिन लगता है 15:58 <jrandom> ह्म्म, क्या आप syndie को single user mode में चला रहे हैं? और/या आप latest CVS build इस्तेमाल कर रहे हैं या official 0.6.1.7 build? 15:58 <ailouros> official 0.6.1.7, single user 15:58 <jrandom> क्या आप blog-जैसे interface के समर्थकों में से हैं, threaded nav के बजाय? 15:58 <ailouros> नहीं, हालांकि मुझे सच में नहीं पता कि ब्लॉग-जैसा कौन सा है 15:58 <ailouros> निजी तौर पर, मुझे threaded nav पसंद आएगा 15:59 <ailouros> (और thread view में नए संदेशों का कुछ color-coding भी) 15:59 <+Complication> काफी लेट CVS, single user 15:59 <+Complication> मुझे एक छोटा-सा अजीबपन मिला है (जो शायद अनिच्छित हो) 15:59 <jrandom> आह, उस मोर्चे पर CVS में काफी प्रगति हुई है, ailouros 15:59 <ailouros> बहुत बढ़िया :) 16:00 <jrandom> हमारे पास नया threaded display भी है, जिसमें cervantes के सुझाए अनुसार सभी branches की जगह केवल एक branch का full traversal है 16:00 <@cervantes> क्या वे बदलाव syndiemedia.i2p.net पर पुश किए गए हैं? 16:00 <+bla> क्या http://localhost:7657/syndie/syndicate.jsp में location के लिए कुछ default उदाहरण दिखाना अच्छा विचार होगा? 16:00 <jrandom> syndiemedia.i2p.net CVS head है, हाँ 16:00 <+Complication> जब आपने कोई thread खोल रखा हो, और उसके posts पढ़ रहे हों... और फिर आप ऐसा filter लागू करें जिससे कोई पोस्ट मेल न खाए (जैसे thread "Syndie threading" खोलें, filter "i2p.i2phex" लागू करें)... 16:00 <jrandom> हाँ, संभवतः bla। नई इंस्टाल्स में वहाँ तीन defaults होंगे, लेकिन उदाहरण अच्छे रहेंगे 16:01 <@cervantes> (असल thread का tree भी पूरी तरह खुलना चाहिए) 16:01 <+Complication> ...ऐसा लगता है कि वर्तमान posts दिखते रहते हैं, मानो वे मेल खा रहे हों या कुछ... 16:01 <+Complication> भले ही मैंने निश्चित रूप से "Go" बटन क्लिक किया था। 16:01 <@cervantes> Complication: हाँ, मुझे भी वह उलझाने वाला लगा 16:02 <jrandom> ह्म्म Complication, सामान्य विचार यह था कि आप किसी पोस्ट को देखते हुए आस-पास ब्राउज़ कर सकें, पर शायद दिख रहे posts को हटा देना बेहतर होगा 16:02 <jrandom> cervantes: आह, हाँ उसे leaf तक expand करना अच्छा होगा, और वह करना भी आसान होना चाहिए 16:02 <+Complication> अभी ध्यान में आया, और क्योंकि वह उभरकर दिखा, सोचा बता दूँ 16:02 <@cervantes> (या यह और स्पष्ट कर दें कि कोई matches नहीं हैं) 16:03 <jrandom> अच्छा, thread nav में लिखा आता है *no matches* :) 16:03 <ailouros> शायद वह लाइटर ढूँढ रहा है 16:03 <jrandom> !thwap 16:03 <@cervantes> (या इसे और भी अधिक स्पष्ट कर दें कि कोई matches नहीं हैं) 16:03 <jrandom> <blink>No matches</blink> 16:03 <+Complication> ऊप्स :) 16:04 <tethra> लगता है आपका !thwap spaetz__ पर लगा, jr! 16:04 <+Complication> सही, कभी-कभी thread navigator वाकई काफी दूर-सा लगता है :) 16:04 <jrandom> हाँ, हम कुछ css के साथ प्रयोग कर रहे हैं ताकि उसे साइड में फ्लोट करने का विकल्प दिया जा सके 16:05 <@cervantes> skinning सपोर्ट के साथ आप thread को ऊपर, नीचे, बाएँ, दाएँ आदि कहीं भी रख सकते हैं 16:05 <@cervantes> आह जैसा jr ने कहा 16:05 <+Complication> "Threads" लिंक वहाँ काफ़ी जल्दी ले जाता है, हालांकि 16:05 <+Complication> ...यदि वह अभी viewport के भीतर हो। 16:06 <+Complication> और जो लोग कीबोर्ड-नेविगेशन के अभ्यस्त हैं वे स्वाभाविक रूप से "End" दबा सकते हैं 16:06 <jrandom> बेशक, यह सब बदलना बहुत सरल है (जैसा कि आप CVS में तेज़ बदलावों से देख सकते हैं :), तो यदि किसी के पास कोई सुझाव (या mockups - html / png / आदि) हों, कृपया कभी भी पोस्ट करें 16:07 <jrandom> मुझे उम्मीद है कि CVS में अगले कुछ दिनों में एक मुख्य blog overview पेज होगा 16:08 <jrandom> ठीक है, Syndie में और भी बहुत कुछ चल रहा है, तो अधिक जानकारी के लिए http://localhost:7657/syndie/ पर आइए :) 16:08 <jrandom> क्या किसी के पास उस पर और कुछ है, या हम 5) ??? पर बढ़ें? 16:09 <zzz> हाय, अभी-अभी आया हूँ। 2) पर, मैं अपने patch के लिए testers ढूँढ रहा हूँ। 16:10 <zzz> मेरे नतीजे job lag और विश्वसनीयता में सुधार, और router hangs में कमी दिखाते हैं। तो उम्मीद है कि दूसरे लोग इसे आज़माएँगे। 16:10 <ailouros> यह काफ़ी अच्छा लगता है। मुझे क्या करना होगा? 16:11 <jrandom> हेया zzz, ठीक है कूल, मैं भी यहाँ इसे थोड़ा-बहुत आज़माऊँगा। इसमें कई अलग-अलग components हैं, तो इसे हिस्सों में बाँटना उपयोगी हो सकता है, पर यह अच्छा दिख रहा है और 0.6.1.8 के लिए ट्रैक पर है 16:11 <ailouros> (यहाँ औसत uptime लगभग 10h है :( 16:11 <zzz> यदि आपके पास source code और ant है तो बस patch लागू करें - या यदि आप चाहें तो मैं i2pupdate.zip लगा सकता हूँ 16:12 <zzz> jrandom मैं इसे बाँटने पर काम करूँगा 16:12 <ailouros> मैं update लूँगा, धन्यवाद 16:13 <zzz> ailouros: इसे एक घंटे के भीतर zzz.i2p पर डाल दूँगा - धन्यवाद 16:13 <jrandom> zzz: जब तक आपके पास खाली समय न हो, इसकी चिंता मत करें... मैं diff पढ़ सकता हूँ :) 16:13 <ailouros> धन्यवाद 16:14 <zzz> jrandom ठीक है। कुछ विविध चीज़ें हैं जिन्हें आप या मैं आसानी से निकाल सकते हैं। 16:16 <ailouros> मेरा ख़याल है हम अब 5) ??? पर हैं? 16:16 <zzz> jrandom एक और विषय था: i2phex के साथ Router OOMs और संभव SAM मुद्दे 16:16 <jrandom> हाँ ailouros 16:16 <jrandom> आह हाँ zzz, SAM के साथ क्या हो रहा है इसे ट्रैक करना बढ़िया होगा 16:17 <ailouros> j346, क्या आपको मेरा ऐप देखने का मौका मिला? 16:17 <jrandom> सबसे अच्छा होगा अगर कोई SAM bridge का मेंटेनेंस संभाल ले, क्योंकि मैंने इस पर काफी समय से कोई बड़ा काम नहीं किया है, और human भी काफ़ी समय से आसपास नहीं है। 16:19 <jrandom> अभी नहीं, ailouros, दुर्भाग्य से। इसके काम करने के तरीके को लेकर थोड़ी अनिश्चितता थी, तो पहले मुझे source पढ़ना होगा 16:20 <ailouros> निःसंकोच पूछें 16:20 <ailouros> (और source की यात्रा के लिए शुभकामनाएँ, यह "mess" शब्द की अच्छी परिभाषा है) 16:20 <jrandom> हेहे 16:21 <zzz> सुधार: मेरा अनुभव OOMs i2p-bt उपयोग करते समय रहा है, i2phex में नहीं। एक i2p-bt चलाने पर लगभग 24 घंटे बाद होता है और दो i2p-bt चलाने पर कुछ घंटों में 16:22 <+Complication> मेरे साथ यह कुछ देर-रात के stress-testing के बाद हुआ। 16:22 <+Complication> (जिस दौरान, नोट कर लें, मैंने 5-मिनट औसत 50 KB/s देखे) 16:22 <bar_> कृपया याद दिलाएँ कि आपका ऐप क्या है/क्या करता है, ailouros? मेरी याददाश्त अच्छी है पर छोटी... 16:22 <+Complication> इनकमिंग, यानी। 16:22 <+Complication> आउटगोइंग 35 KB/s तक सीमित था 16:22 <@cervantes> Complication: मैंने इसे पहले कभी late-night stress testing नहीं कहा सुना... 16:22 <jrandom> अच्छा है Complication 16:23 <+Complication> cervantes: ठीक है, तब इसे semi-daily megaleeching कह सकते हैं :P 16:23 <ailouros> bar_: यह एक distributed filesharing ऐप के लिए working proof-of-concept है, जो विभिन्न फाइलों के बीच common blocks साझा करता है (जैसा polecat ने सुझाया) 16:23 <bar_> आह, ठीक है, धन्यवाद ailouros 16:24 <tethra> cervantes: हेहेहेह ;) 16:24 <ailouros> स्वागत है (यदि कोई source लेना चाहता है, यह C/C++ में है) 16:25 <+polecat> सावधान रहें, दो बाइनरी ब्लॉक्स का एक जैसा होना काफ़ी दुर्लभ है, मैं अधिकतर शुद्ध सिद्धांत की बात कर रहा हूँ जिसका व्यवहार में उपयोगी होना मुश्किल है। 16:25 <ailouros> मैं सहमत हूँ। मेरा अनुमान है कि यह तब उपयोगी होगा जब आपको एक ही फाइल के अलग-अलग संस्करण मिलते हैं 16:25 <ailouros> जैसे, कोई मूवी जिसमें एक corrupted block हो 16:25 <+polecat> आप zeroes के ब्लॉक्स बिजली-सी गति से ट्रांसफर कर सकते हैं! ("अगला ब्लॉक ज़ीरो है" "ओह वह तो मेरे पास पहले से है" "अगला ब्लॉक ज़ीरो है" "ओह वह तो मेरे पास पहले से है") 16:26 <ailouros> या अन्य zip फाइलों का कोई आर्काइव 16:26 <jrandom> या जैसे modified ID3 टैग्स, आदि 16:26 <ailouros> बिल्कुल 16:26 <+polecat> सही। लेकिन corrupted block वाली मूवी को "ठीक" करने का आसान तरीका है bittorrent से उसे ऊपर से डाउनलोड करना। अधिकांश क्लाइंट उन ब्लॉक्स को सुरक्षित रखते हैं जिनके हैश समान हैं, और जो अलग हैं उन्हें ओवरराइट कर देते हैं। 16:26 <jrandom> फाइलों के आर्काइव शायद काम न करें, क्योंकि उन्हें फाइल boundaries पर टूटना पड़ेगा 16:27 <ailouros> j636, इसी वजह से मैं LBFS का विचार लागू करना चाहता हूँ जिसमें fixed block sizes की जगह data marks पर splitting होती है 16:27 <@cervantes> DC समुदाय ने यह तरीका अपनाया, फ़ाइल वितरणों को rarsets में साझा करके 16:27 <+polecat> जो उपयोगी हो सकता है वह है एक सामान्य binary error correction एल्गोरिद्म बनाना, फिर उसे बड़े पैमाने पर लागू करना। सभी ब्लॉक्स एक-दूसरे में "corrected" किए जा सकते हैं, और आपको केवल correction डेटा प्रेषित करना होगा, जो संभवतः पूरे ब्लॉक से छोटा होगा। 16:29 <@cervantes> और फिर खोजें उन rar भागों के tiger hashes पर आधारित होती हैं 16:29 <+Complication> अच्छा विचार... हालांकि कठिन लगता है :) 16:29 <+polecat> लेकिन सिर्फ hash-for-hash समकक्ष... आपको कभी दो समान ब्लॉक नहीं मिलेंगे! 16:29 <ailouros> cervantes, "rarset" क्या है? :D ("RAR file" के अलावा, मेरा मतलब) 16:29 <+polecat> जब तक कि दोनों पक्षों के पास पहले से फाइल न हो, जिनमें से एक भ्रष्ट हो। 16:29 <ailouros> polecat, उह? 16:29 <@cervantes> ailouros: एक split rar archive, ज़रूरत पड़े तो parity files के साथ 16:30 <ailouros> cervantes: मुझे ऐसा करने का लाभ समझ नहीं आता 16:31 <@cervantes> इसका मुख्य लाभ DC में pseudo-multi-source downloading जोड़ना था 16:32 <ailouros> खैर, वह फाइलों के बीच block sharing मेकैनिज़्म का हिस्सा है, है न? 16:34 <ailouros> bittorrent द्वारा damaged files पर ओवरराइट करने के बारे में, जो यह नहीं देता वह तब है जब आप एक साथ कई संस्करण लेने की कोशिश करते हैं 16:35 <@cervantes> आपका क्लाइंट केवल वैध हिस्सों का मिलान/डाउनलोड करता है, parity files हों तो आप damaged parts को भी रिकवर कर सकते हैं 16:35 <ailouros> मेरे सिस्टम में कोई damaged parts नहीं होते (फाइलें तभी assembled होती हैं जब composing blocks डाउनलोड और पुन:जाँचे जाते हैं) 16:36 <@cervantes> वह सब जो bittorrent डिफ़ॉल्ट रूप से करता है, बस आप व्यक्तिगत पार्ट्स को विशेष रूप से खोज नहीं सकते 16:36 <+polecat> कई संस्करणों में एक भी बिट समान होने की संभावना नहीं होती... यही कारण है कि वे इतने बेवकूफ़ी भरे होते हैं। कुछ शख्स मूवी को पोस्टेज स्टैम्प फॉर्मेट में फिर से एन्कोड करने का निर्णय लेता है, और उसे वही नाम दे देता है। 16:29 <+polecat> या कोई दूसरा शख्स रैंडम डेटा लेता है और उसे उस फाइल के नाम से नाम दे देता है जिसे आप डाउनलोड करना चाहते हैं। 16:37 <ailouros> lol बिलकुल सही 16:37 <@cervantes> बिल्कुल, और rarset रिलीज़ उससे सुरक्षित होती हैं... 16:37 <ailouros> पर ध्यान रखें कि अन्य नेटवर्क (emule, kazaa, आदि) से आने वाली फाइलें अक्सर corrupted होती हैं 16:38 <+polecat> rarset रिलीज़ सुरक्षित नहीं होतीं... 16:38 <+polecat> आपको फिर भी यह पता लगाना पड़ता है कि कौन-सी rarset सही है। 16:38 <ailouros> cervantes, कोई रैंडम जंक पब्लिश करने वाले मूर्ख से rarsets कैसे सुरक्षित हैं? 16:38 <@cervantes> (यदि आपके पास भरोसेमंद स्रोत हो) 16:39 <@cervantes> क्योंकि एक रिलीज़ समूह hashes/वितरण जानकारी प्रकाशित करता है 16:39 <ailouros> हाहाहा यह आसान है :D 16:39 <@cervantes> और अगर गुणवत्ता खराब हो तो चीज़ों को nuked के रूप में चिह्नित किया जाता है, लोग उसे shares से हटा देते हैं 16:40 <ailouros> cervantes, इतना तो मेरा टॉय पहले से करता है 16:40 <@cervantes> कूल 16:40 <ailouros> आप trusted source से file descriptor लेते हैं, आप फाइल को multiget करते हैं, तुरंत 16:41 <@cervantes> अच्छा लगता है ;-) 16:41 <ailouros> आप फाइलों को search नहीं कर पाते, लेकिन प्रत्येक यूज़र की shared dir ब्राउज़ कर सकते हैं, इसलिए आप वेब क्रॉलर का उपयोग कर सकते हैं और परिणाम cache कर सकते हैं 16:42 <ailouros> हालाँकि यदि आवश्यक समझा गया तो मैं भविष्य में कभी search फ़ंक्शन जोड़ सकता हूँ 16:44 <ailouros> मेरा मानना है कि मेरा टॉय, यदि ठीक से ऐप में विकसित किया जाए, तो वही caching और resilience दे सकता है जो freenet लोग देने की कोशिश करते हैं 16:44 <ailouros> जैसे कि स्थिर सामग्री वितरण और caching 16:45 <ailouros> आप मेरा ब्लॉग पढ़ते हैं, आप उसे cache करते हैं और जब लोग चाहें तो उन्हें उपलब्ध कराते हैं। आप बस सामग्री वहाँ छोड़ देते हैं, इससे अधिक कुछ नहीं करते 16:45 <ailouros> सामग्री पसंद नहीं? उसे delete कर दें और सब ठीक 16:45 <jrandom> ह्म्म, तो क्या आप इसे Syndie के लिए इस्तेमाल होने वाले एक backing store के रूप में देखते हैं? 16:46 <ailouros> इसे backing store के रूप में इस्तेमाल किया जा सकता है 16:46 <ailouros> जैसा यह अभी है, आप इसे i2p की डिफ़ॉल्ट इंस्टॉलेशनों में jetty की जगह भी इस्तेमाल कर सकते हैं 16:46 <jrandom> e.g. attachments / links to [clunk hash="$foo"]my file[/clunk] 16:46 <ailouros> (खैर, कुछ छोटे-मोटे बदलावों के साथ :D ) 16:46 <jrandom> हेह 16:47 <jrandom> ठीक है, हाँ, मुझे सच में समझ नहीं आता कि clunk कैसे काम करता है... क्या आप इसके बारे में Syndie में पोस्ट करना चाहेंगे, या कोई eepsite बना दें? :) 16:47 <ailouros> फाइल अनुरोध पर file hashes डाउनलोड किए जाते हैं, और ये hashes स्वतः पूरी फाइल में डाउनलोड हो जाते हैं 16:48 <jrandom> ठीक, पर "डाउन"लोडेड में सवाल है कि कहाँ से कहाँ, आदि। एक समग्र नेटवर्क आर्किटेक्चर का विवरण मददगार होगा 16:48 <ailouros> मैं पहले एक बढ़िया doc लिखूँगा, फिर उसे कहीं प्रकाशित करूँगा 16:48 <jrandom> r0x0r, धन्यवाद 16:48 <ailouros> जहाँ से आपको hash मिला, वहीं से डाउनलोड किया जाता है 16:48 <ailouros> साथ ही वे सभी और लोग जो ये ब्लॉक्स साझा कर रहे हैं 16:49 <ailouros> सोचिए go!zilla और download accelerator :) 16:49 <jrandom> मुझे लगता है आप यह नहीं समझ रहे कि मैं कितना भ्रमित हूँ 16:49 <ailouros> पर यह पारदर्शी और i2p के भीतर है 16:49 <ailouros> lol लगता है ऐसा ही है :D 16:50 <jrandom> बहुत, बहुत बुनियादी व्याख्या जैसे "आप clunk client चलाते हैं, clunk server से डाउनलोड करते हैं, clunk peers के बारे में जानकारी लेते हैं", आदि 16:50 <jrandom> क्या मैं clunk client को क्वेरी करने के लिए वेब ब्राउज़र का उपयोग करता हूँ? या server? या peer? 16:51 <jrandom> (मैं इतना खोया हुआ हूँ) 16:51 <ailouros> 0 से फिर शुरू करते हैं :) 16:51 <ailouros> आप अपना वेब ब्राउज़र इस्तेमाल करते हैं 16:51 <ailouros> आप अपने client से कनेक्ट करते हैं 16:51 <ailouros> आप अपने ब्राउज़र से दूसरों की dir ब्राउज़ करते हैं 16:51 <ailouros> आप अपने ब्राउज़र से कौन-सी फाइलें डाउनलोड करनी हैं यह चुनते हैं 16:51 <ailouros> आपका client सारा भारी काम करता है 16:52 <ailouros> आपको डाउनलोड की गई फाइल मिल जाती है 16:52 <ailouros> क्या यह बेहतर है? :) 16:52 <jrandom> ठीक है बढ़िया, धन्यवाद - तो "दूसरे की dir ब्राउज़ करें" आपका client उनके client को क्वेरी करके करता है और उसका HTML प्रतिनिधित्व वापस देता है 16:52 <ailouros> बिल्कुल 16:53 <jrandom> (या किसी server/superpeer/आदि से खींचा जाता है) 16:53 <jrandom> कूल' 16:53 <ailouros> सारा भारी काम (डुप्लिकेट ढूँढना, मल्टीडाउनलोड्स, आदि) आपका (स्थानीय) client पारदर्शी तरीक़े से करता है 16:54 <ailouros> जो आप देखते हैं, मूलतः, एक डायरेक्टरी ट्री और कुछ फाइलें जिन्हें आप डाउनलोड कर सकते हैं 16:54 <jrandom> कूल 16:55 <ailouros> अपना डेटा publish करने के लिए आप अपना public (p2p) address देते हैं 16:55 <ailouros> और फाइलें share करने के लिए आप उन्हें pub/ डायरेक्टरी (या किसी subdir) में कॉपी (या symlink) करते हैं। यह इतना आसान है 16:57 * jrandom source को और खंगालेगा, और अधिक जानकारी की प्रतीक्षा करेगा :) 16:57 <jrandom> ठीक है, बैठक के लिए किसी और के पास कुछ है? 16:57 <bar_> उम्म.. अगर मैं पूछूँ तो publishing और sharing में क्या अंतर है? क्या publishing डेटा को किसी datastore पर पुश करती है? 16:58 <ailouros> bar_: sharing का मतलब है डाउनलोड करने के लिए ब्लॉक्स देना। publishing का मतलब है दुनिया को बताना कि आप क्या share करते हैं 16:58 <ailouros> publishing, sharing का एक subset है 16:58 <bar_> आहा, समझ गया, धन्यवाद 16:58 <ailouros> उदाहरण के लिए, यदि आपके पास किसी फाइल का आधा हिस्सा है, तो आप उसे share करते हैं पर publish नहीं करते 16:59 <jrandom> लोगों को कैसे पता चलेगा कि वे वे ब्लॉक्स आपसे ले सकते हैं? 16:59 <ailouros> और आपके पास किन फाइलों को आप publish करते हैं उस पर पूरा नियंत्रण होता है (emule के विपरीत जहाँ हर डाउनलोड की गई फाइल publish होती है) 16:59 <ailouros> क्योंकि प्रत्येक client समय-समय पर नेटवर्क को यह जानकारी भेजता है कि उसके पास कौन-से ब्लॉक्स ऑफ़र करने के लिए हैं 17:00 <jrandom> कूल' 17:00 <ailouros> नेटवर्क को भेजता है, जैसे सर्वर (जैसा अभी है) या DHT (भविष्य) 17:00 <jrandom> तो यह mnet-जैसा है, एक block tracker के साथ 17:00 <ailouros> उह, mnet-जैसा? 17:01 <jrandom> वैसा ही जैसे mnet (mnetproject.org) काम करता है 17:01 * ailouros mnetproject.org पढ़ रहा है 17:02 <ailouros> खैर, आपके पास सिर्फ़ आपकी व्यक्तिगत स्पेस हैं, कोई shared स्पेसेज़ नहीं 17:02 <ailouros> और आप ब्लॉक्स को PUSH नहीं करते 17:02 <jrandom> हाँ, यह mnet जैसा बिल्कुल नहीं है, पर संरचनात्मक रूप से मिलता-जुलता है 17:03 <jrandom> यह mnet जैसा है जहाँ हर कोई इतना कंगाल है कि उनके डेटा को कोई host नहीं कर सकता ;) 17:03 <ailouros> हाँ 17:03 <ailouros> :D 17:03 <jrandom> ठीक है, किसी और के पास और कुछ उठाने के लिए है? 17:04 <jrandom> अगर नहीं... 17:04 * jrandom समापन करता है 17:04 * jrandom *baf* करके बैठक को बंद करता है