I2P डेवलपर बैठक - 22 मार्च, 2005

13:01 <@jrandom> 0) हाय 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) बैचिंग 13:01 <@jrandom> 3) अपडेटिंग 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) हाय 13:01 * jrandom हाथ हिलाता है 13:01 <@jrandom> अभी-अभी पोस्ट किए गए साप्ताहिक स्टेटस नोट्स यहाँ हैं @ http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> हाय 13:02 <+cervantes> हैलो 13:02 <@jrandom> चलो सीधे 1) 0.5.0.3 पर आते हैं 13:02 <@jrandom> रिलीज़ कुछ दिन पहले आई थी, और रिपोर्ट्स सकारात्मक रही हैं 13:02 <+cervantes> jrandom: जब नीले नाचते बौने तुम्हारे मॉनिटर पर चढ़ आएँ, तो हमें बता देना, हम मीटिंग जल्दी खत्म कर देंगे 13:03 <@jrandom> हेह cervantes 13:03 <@jrandom> (संपादनीय मीटिंग लॉग्स के लिए Bob का धन्यवाद ;) 13:04 <@jrandom> उस संदेश में जो है, उसके अलावा 0.5.0.3 के बारे में मेरे पास जोड़ने के लिए ज़्यादा कुछ नहीं है 13:04 <@jrandom> क्या किसी के पास इस पर कोई टिप्पणी/प्रश्न/चिंता है? 13:04 <bla> jrandom: fast-peers-selection कोड पर कोई नए माप/मेट्रिक्स? 13:05 <@jrandom> आह, मुझे पता था 0.5.0.3 में एक और चीज़ है जिसे मैं नज़रअंदाज़ कर गया ;) 13:06 <@jrandom> मेरे पास अभी ठोस मेट्रिक्स नहीं हैं, पर अनुभवजन्य रूप से fast peer selection ने वही peers चुने जिन्हें मैं स्पष्ट तौर पर 'तेज़' जानता हूँ (जैसे कि उसी बॉक्स पर चल रहे routers, आदि) 13:07 <bla> jrandom: कभी-कभी, eepsites को उपयोग के लिए एक अच्छा tunnel पाने में अब भी कई बार रिट्राई करने पड़ते हैं 13:07 <@jrandom> कभी-कभी काफ़ी ठीक-ठाक throughput दरों की रिपोर्ट भी आई है (10–20KBps रेंज में), पर वह अभी आम नहीं है (हमने अभी पैरामीटर्स कम रखे हुए हैं) 13:08 <+ant> <Connelly> ऊप्स, यहाँ मीटिंग है 13:09 <@jrandom> हम्म, हाँ, मैंने पाया है कि विश्वसनीयता अभी भी जहाँ होनी चाहिए वहाँ नहीं है। एक से अधिक बार रिट्राई करना वास्तव में समाधान नहीं है — अगर कोई साइट 1 रिट्राई के बाद भी लोड नहीं होती, तो दोबारा प्रयास करने से पहले 5–10 मिनट दें 13:09 <@jrandom> नेट पर मैंने transport layer में देरी के स्पाइक्स काफ़ी बार देखे हैं 13:10 <@jrandom> जैसे, किसी socket से 1–2KB का संदेश फ्लश करने में ही 5–20+ सेकंड लग जाना 13:10 <@jrandom> इसे 5-hop पाथ (2-hop tunnels) के साथ जोड़ दें, और दिक्कतें आ सकती हैं 13:11 <@jrandom> यही चीज़ batching कोड को प्रेरित कर रही है — भेजे जाने वाले संदेशों की संख्या कम करना 13:13 <@jrandom> ठीक है, 0.5.0.3 पर किसी और के प्रश्न/टिप्पणी/चिंताएँ? 13:13 <bla> jrandom: ठीक लग रहा है। मैं अगली "सेक्शन" में इसके बारे में और पूछूँगा 13:14 <@jrandom> w3rd, ठीक है, तो चलें आगे — 2) बैचिंग 13:15 <@jrandom> ईमेल और मेरा ब्लॉग (jrandom.dev.i2p</spam>) नियोजित चीज़ों की बुनियादी जानकारी देते हैं 13:15 <@jrandom> और, खैर, ये काफ़ी बुनियादी चीज़ें ही हैं 13:15 <@jrandom> जो मौजूदा preprocessor हमारे पास है, उसे लागू करना संभवतः सबसे सरल था (क्लास नाम: TrivialPreprocessor) ;) 13:16 <@jrandom> नए वाले में batching frequency के लिए कुछ समायोज्य पैरामीटर हैं, और individual tunnel pools के भीतर कुछ outbound tunnel affinity भी है (जहाँ हम, उदाहरण के लिए, 500ms तक, अगली रिक्वेस्ट्स के लिए उसी outbound tunnel को चुनने की कोशिश करते हैं ताकि batching को बेहतर किया जा सके) 13:17 <@jrandom> इसके बारे में मेरे पास जोड़ने को बस इतना ही है — कोई प्रश्न/टिप्पणी/चिंताएँ? 13:18 <bla> क्या इसके लिए सभी भाग लेने वाले नोड्स को नया preprocessor चलाना ज़रूरी है, या Trivial/NewOne का मिश्रण साथ चल सकता है? 13:18 <+Ragnarok> इससे latency में 0.5s जुड़ जाएगा, सही? 13:19 <@jrandom> bla: नहीं, यह preprocessor सिर्फ tunnel gateway पर उपयोग होता है, और बैच करना है या कैसे करना है, यह उसी gateway पर निर्भर है 13:20 <@jrandom> Ragnarok: आम तौर पर नहीं — संदेश 1 में अधिकतम 0.5s की देरी हो सकती है, लेकिन संदेश 2–15 पहले की तुलना में बहुत तेज़ ट्रांसफ़र हो जाते हैं। यह एक साधारण थ्रेशहोल्ड भी है — जैसे ही full tunnel message जितना डेटा उपलब्ध होता है, उसे फ्लश कर दिया जाता है 13:20 <+Ragnarok> कूल 13:20 <+Ragnarok> यह कितना ओवरहेड बचाता है? 13:21 <@jrandom> काफ़ी ज़्यादा ;) 13:21 <+Ragnarok> ‘काफ़ी ज़्यादा’ अच्छा है, भले ही धुंधला हो :P 13:21 <@jrandom> अपने http://localhost:7657/oldstats.jsp#tunnel.smallFragments पर देखें 13:21 <@jrandom> उसे #tunnel.fullFragments से तुलना करें 13:22 <bla> jrandom: क्या यह केवल endpoint->IB-gateway संचार से संबंधित है? 13:22 <@jrandom> batching के साथ, full और small का अनुपात बढ़ेगा, और small में pad bytes की संख्या घटेगी 13:23 <@jrandom> bla: हम्म, यह सभी tunnel gateways पर लागू होता है, चाहे inbound हों या outbound 13:24 <mihi> full fragments: लाइफ़टाइम औसत मान: 1,00 1.621,00 घटनाओं पर 13:24 <bla> jrandom: ठीक है 13:24 <mihi> क्या fragments की संख्या भिन्नात्मक हो सकती है? 13:24 <@jrandom> full: 1.00 807,077.00 घटनाओं पर small: 746.80 692,682.00 घटनाओं पर 13:25 <@jrandom> हेह mihi 13:25 <@jrandom> (वह small: 746 का मतलब है कि उन 692k संदेशों में, 996 में से 746 bytes व्यर्थ pad bytes थे!) 13:26 <@jrandom> खैर, पूरी तरह व्यर्थ नहीं — उन्होंने अपना काम किया 13:26 <+detonate> फिर भी अनावश्यक ओवरहेड 13:27 <@jrandom> हाँ, इसका बड़ा हिस्सा हम batching preprocessor से घटा सकेंगे 13:28 <@jrandom> दुर्भाग्य से, वह अगली रिलीज़ में बंडल नहीं होगा 13:28 <@jrandom> लेकिन वह 0.5.0.6 rev (या शायद 0.5.1) में बंडल होगा 13:28 <@jrandom> अ.. 0.5.0.5, या 0.5.1 13:28 * jrandom नंबरों से उलझ जाता है 13:29 <bla> jrandom: ऐसा क्यों? 13:29 <+cervantes> हैश और गोलियाँ... धत् 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: 0.5.0.3 (और उससे पहले) में एक बग है, जिसमें fragmented message handler उसी tunnel message के भीतर आने वाले बाद के fragments को फेंक देता है 13:31 <@jrandom> अगर हम batching preprocessor सीधे तैनात कर दें, तो काफ़ी संख्या में संदेश खो जाएँगे 13:31 <@jrandom> चिंता की बात नहीं, हमारे पास और भी बढ़िया चीज़ें हैं, तो आने वाला 0.5.0.4 बिल्कुल उबाऊ नहीं होगा ;) 13:31 <bla> jrandom: आह, तो यही 13:32 <bla> jrandom: आह, तो इसलिए हमें यह 0.5.0.4 के मुख्यधारा में आने के बाद करना होगा.. समझ गया। धन्यवाद। 13:33 <@jrandom> हाँ, अच्छा होता अगर fragment handler इसे संभाल पाता — और आम तौर पर संभालता भी है — बस वह byte buffer बहुत जल्दी रिलीज़ कर देता है, जिससे बाद के fragments शून्य हो जाते हैं (oops) 13:33 <@jrandom> ठीक है, 2) पर और कुछ, या हम 3) अपडेटिंग पर बढ़ें? 13:35 <@jrandom> ठीक है, जैसा कि स्टेटस नोट्स में बताया गया था (और अलग-अलग जगहों पर कुछ समय से चर्चा भी हुई है), हम सरल और सुरक्षित updating के लिए कुछ फ़ंक्शनलिटी जोड़ने जा रहे हैं, ताकि end user को वेबसाइट पर जाने, मेलिंग लिस्ट पढ़ने, या चैनल में टॉपिक पढ़ने की ज़रूरत न पड़े :) 13:36 <+detonate> कूल 13:36 <@jrandom> smeghead ने प्रक्रिया को स्वचालित और सुरक्षित बनाने में मदद के लिए कुछ कोड तैयार किया है, और cervantes के साथ मिलकर इसे fire2pe तथा सामान्य routerconsole से जोड़ रहे हैं 13:37 <@jrandom> ईमेल यह बताता है कि क्या-क्या उपलब्ध होने वाला है का सामान्य विवरण, और यद्यपि इसका अधिकांश हिस्सा फ़ंक्शनल है, कुछ हिस्से अभी पूरी तरह तय नहीं हुए हैं 13:37 <@jrandom> batching के विपरीत, यह अगली rev में उपलब्ध /होगा/, हालांकि लोग इसका ज़्यादा उपयोग 0.5.0.5 तक नहीं कर पाएँगे (जब अपडेट करने का समय आएगा) 13:39 <+Ragnarok> तो... 5.0.4 के लिए कूल चीज़ें क्या हैं? 13:42 <@jrandom> अपडेट कोड के साथ घोषणा डेटा खींचने की क्षमता आती है, जैसे router console के शीर्ष पर कोई समाचार का छोटा-सा स्निपेट दिखाना। इसके अलावा, अपडेट कोड के हिस्से के रूप में हमारे पास एक नया विश्वसनीय डाउनलोड घटक है, जो सीधे या eepproxy के माध्यम से काम करता है, रास्ते में रिट्राई करता है और आगे बढ़ता रहता है। शायद उसके ऊपर कुछ संबंधित फीचर्स बनें, पर कोई वादा नहीं 13:42 <+Ragnarok> बढ़िया 13:43 <@jrandom> ठीक है, 3) अपडेटिंग पर किसी और के प्रश्न/टिप्पणी/चिंताएँ? 13:45 <@jrandom> अगर नहीं, तो 4) ??? पर चलते हैं 13:45 <@jrandom> क्या और कुछ है जो कोई उठाना चाहता है? मुझे यक़ीन है कि मैं कुछ बातें भूल गया हूँ 13:45 <+detonate> OpenBSD 3.7 में sun jvm के साथ I2P के काम करने की पुष्टि है :) 13:45 <@jrandom> बहुत बढ़िया! 13:47 <bla> UDP ट्रांसपोर्ट पर स्थिति क्या है? 13:48 <+detonate> UDP उलझा हुआ रहेगा, मुझे लगता है कि bt से pipelining कोड चुरा कर उसे अनुकूलित करना बेहतर होगा ;) 13:48 <@jrandom> *खाँसी* 13:49 <@jrandom> मुझे ज़्यादा परेशानी की उम्मीद नहीं है, पर काम तो काफ़ी करना होगा 13:49 <@jrandom> queueing policy कैसे काम करेगी, और queue में प्रवेश के लिए bw throttling कैसी होगी — यह रोचक होगा 13:50 <bla> वह प्रारंभिक काम कौन कर रहा था? 13:50 <@jrandom> bla: detonate और mule 13:50 <+detonate> हाँ.. पर पिछले एक महीने या इतने समय से मैं ढीला पड़ा हुआ हूँ 13:50 <bla> detonate: मैं मान लेता हूँ कि तुम BT वाली बात मज़ाक में कह रहे हो? 13:51 <+detonate> मैं आधा-आधा गंभीर हूँ 13:51 <+detonate> ऐसा करने पर कम से कम transport के लिए thread count आधा कर सकते हो 13:51 * jrandom detonate पर कीचड़ की बाल्टी फेंकता है 13:51 <jdot> वूहू। मेरा router अब मेरी POS केबल कनेक्शन की बजाय मेरे dedicated सर्वर पर चल रहा है। 13:51 <@jrandom> बढ़िया jdot 13:52 <@jrandom> हम transport layer में सभी peers के साथ सभी comm के लिए 3–5 threads से काम चला पाएँगे 13:52 <bla> detonate: पर आधा करना काफ़ी नहीं होगा, जब net बड़ा हो जाएगा (> कुछ सौ नोड्स) 13:52 <jdot> इसके पास 1000GB b/w उपलब्ध है 13:53 <jdot> दुर्भाग्य से j.i2p और chat.i2p अगले कुछ घंटों तक डाउन रहेंगे जब तक मैं माइग्रेट करता हूँ 13:53 <duck> detonate: addressbook भी halt पर है? 13:53 <+detonate> हाँ, वह भी halt पर है 13:54 <+detonate> जो एक चीज़ halt पर नहीं है वह monolithic profile storage है, मैं उसे आज बाद में काम में लाने की सोच रहा था 13:54 <@jrandom> w3rd 13:54 <+detonate> तब i2p ड्राइव को भारी तौर पर fragment नहीं करेगा 13:54 <jdot> jrandom: जहाँ तक BW limits की बात है, क्या वे averages हैं? 13:54 <+frosk> आधुनिक फ़ाइलसिस्टम fragment नहीं होते, बेवकूफ़ी मत करो 13:55 <+detonate> NTFS करता है 13:55 <@jrandom> jdot: bandwidth limits सख्त token buckets हैं 13:55 <@jrandom> jdot: अगर आप burst duration सेट करते हैं, तो उतनी ही अवधि पर यह औसत निकालता है 13:56 <@jrandom> (अच्छा, 2x burst == period) 13:56 <@jrandom> ((ish)) 13:56 <jdot> हम्म... खैर मेरे पास 1000GB है और मैं चाहता हूँ कि i2p 800GB/माह तक ले सके.... 13:56 <+ant> <mihi> detonate: NTFS बहुत छोटी फ़ाइलें MFT में स्टोर करता है, जिसका मतलब है लगभग कोई fragmentation नहीं 13:57 <jdot> और मुझे परवाह नहीं कि यह कितना burst करता है 13:57 <+detonate> जब आप डिफ्रैगमेंटर चलाते हैं, तो वह सभी 6000 प्रोफाइल्स को इधर-उधर करने में 10 मिनट लगाता है.. तो वे ज़रूर fragment होते हैं 13:58 <@jrandom> jdot: हम्म, खैर, 800GB शायद वैसे भी इससे ज़्यादा है जितना यह पुश करना चाहेगा, तो आप शायद limits के बिना भी चला सकते हैं ;) 13:58 <@jrandom> दूसरी ओर, अगर आप कोई policy बता सकें जिसे आप लागू देखना चाहते हैं, तो हम उसे संभाल सकते हैं 13:58 <jdot> jrandom: मैं फिलहाल ऐसा ही करूँगा और देखूँगा यह कैसा चलता है 13:58 <bla> detonate: NTFS, IIRC, एक जर्नलिंग FS है। तो अगर आप उसमें छोटे-छोटे हिस्से लिखते हैं तो एक monolithic फ़ाइल भी fragment हो जाएगी 13:58 <+detonate> सब कुछ एक साथ लिखा जाता है 13:59 <+detonate> और एक साथ पढ़ा जाता है 13:59 <bla> detonate: ठीक है। समझ गया। 13:59 <jdot> jrandom: अच्छा, चलो पहले देखते हैं कि यह वाकई समस्या बनता भी है या नहीं। 13:59 <bla> detonate: उस स्थिति में बढ़िया काम! 13:59 <+detonate> अगर आप इसे अनकैप्ड छोड़ दें, तो वास्तव में कितना उपयोग होता है यह जानने में मेरी दिलचस्पी है 14:00 <+detonate> एक अच्छे कनेक्शन पर 14:00 <jdot> मुझे भी दिलचस्पी है! 14:00 <@jrandom> मेरे colo routers अनकैप्ड चलते हैं, हालाँकि CPU सीमित है 14:00 <+Ragnarok> क्या आप महीने भर का औसत निकालने के लिए bitbucket का उपयोग कर सकते हैं? 14:00 <jdot> jrandom: CPU constrained? किस तरह का CPU? 14:01 <@jrandom> 4d transfer 3.04GB/2.73GB 14:01 <+detonate> हम्म, मुझे कम की उम्मीद थी 14:01 <@jrandom> jdot: CPU constrained इसलिए है क्योंकि मैं उस पर 3 routers चलाता हूँ, साथ में कुछ और JVMs, कभी-कभी प्रोफाइलिंग भी 14:01 <+detonate> शायद वे bt वाले लोग होंगे 14:01 <+detonate> जब batching वाली चीज़ें ऑनलाइन होंगी, तो यह देखना दिलचस्प होगा कि इससे क्या बदलाव आता है 14:02 <@jrandom> detonate: उस ट्रांसफ़र का कुछ हिस्सा यह भी है कि मैं अपने बीच ही 50MB फ़ाइलें धकेल रहा था ;) 14:02 <+detonate> हेह 14:02 <jdot> आह। ठीक। चलो देखें यह सिस्टम कैसा करता है। यह AMD XP 2400 है, 512MB के साथ और 10Mbit कनेक्शन 14:02 <@jrandom> Ragnarok: token buckets वास्तव में उस तरह काम नहीं करते 14:02 <@jrandom> jdot: सही, हाँ, यह एक P4 1.6 है IIRC 14:03 <@jrandom> Ragnarok: token bucket में, हर (उदाहरण के लिए) सेकंड, दर के अनुसार कुछ tokens जोड़े जाते हैं। अगर bucket भर चुका है (आकार = burst period), तो अतिरिक्त tokens फेंक दिए जाते हैं 14:04 <@jrandom> जब भी आप डेटा ट्रांसफ़र करना चाहें, आपको पर्याप्त मात्रा में tokens चाहिए होते हैं 14:04 <@jrandom> (1 token = 1 byte) 14:04 <+Ragnarok> मुझे पता है ये कैसे काम करते हैं... अगर आप bucket को बहुत बड़ा कर दें तो क्या होगा? 14:05 <+detonate> फिर आप कभी डेटा भेजना बंद नहीं करते 14:05 <+detonate> अगर उसका आकार अनंत हो 14:05 <+detonate> उह, और वह tokens से भरा हो 14:05 <@jrandom> अगर यह बहुत बड़ा है, तो कम उपयोग के बाद यह अनलिमिटेड दरों तक burst कर सकता है 14:06 <@jrandom> हालाँकि कुछ मामलों में शायद यही वांछित हो 14:07 <@jrandom> बात यह है कि आप token bucket को 800GB पर सेट नहीं कर सकते, क्योंकि उससे कुल ट्रांसफ़र की मात्रा सीमित नहीं होगी 14:08 <+detonate> आपको वहाँ एक फ़ील्ड चाहिए जहाँ आप tokens per second सेट कर सकें, फिर आप मासिक bandwidth उपयोग को सेकंडों की संख्या से बाँट सकते हैं 14:08 <+detonate> :) 14:10 <@jrandom> वह तो महीने भर का औसत दर सेट करने जैसा ही है, जो असंतुलित होगा। खैर, बहुत से परिदृश्य संभव हैं — अगर किसी के पास ऐसा कोई है जो उनकी ज़रूरतें पूरी करता हो पर मौजूदा साधनों से पूरा न होता हो, तो कृपया संपर्क करें 14:10 <+Ragnarok> पर अगर आप दर को उतने औसत पर सेट करें जितना आप चाहते हैं... मेरा खयाल से यहाँ 308 kB/s, और फिर bitbucket को बहुत बड़ा सेट कर दें... तो वह क्यों नहीं काम करता? 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> आप इसे ऐसे सेट कर सकते हैं कि यह 60 सेकंड के burst period में 800GB/44000 से ज़्यादा कभी न भेजे 14:12 <+detonate> 44000, महीने में मिनटों की लगभग संख्या है 14:13 <@jrandom> bucket size / burst duration यह बताता है कि हम बिना रोक-टोक कितना भेजेंगे, और ज़्यादातर लोग वाक़ई सीमाएँ /चाहते हैं/, ताकि router bucket खाली करते समय 5 मिनट तक 10mbps न निगल जाए (या जो भी) 14:14 <@jrandom> बकेट से निकलते tokens पर एक अतिरिक्त throttle भी संभव है (और क्या उस throttle का अपना token bucket होना चाहिए, और उस बकेट का अपना throttle, आदि) 14:16 <+Ragnarok> मुझे लगा था कि बकेट में केवल तब टोकन डाले जाते हैं जब bandwidth उपयोग नहीं हो रही होती 14:16 <@jrandom> टोकन एक नियत दर से बकेट में जोड़े जाते हैं (जैसे 64k tokens प्रति सेकंड) 14:17 <@jrandom> जिसे भी bandwidth चाहिए, वह हमेशा बकेट से पूछता है 14:18 <+Ragnarok> आह.. ठीक 14:19 <@jrandom> ठीक है, बढ़िया, क्या किसी और के पास मीटिंग के लिए कुछ लाने को है? 14:21 <@jrandom> ठीक है, अगर नहीं 14:21 * jrandom समेटता है 14:21 * jrandom *baf* करके मीटिंग बंद करता है