हाय दोस्तों, साप्ताहिक अपडेट का समय है

अनुक्रमणिका:

  1. 0.4.1.1 status
  2. Pretty pictures
  3. 0.4.1.2 and 0.4.2
  4. Bundled eepserver
  5. ???

1) 0.4.1.1 स्थिति

काफी समस्याग्रस्त 0.4.1 रिलीज़ (और उसके बाद तेजी से किया गया 0.4.1.1 अपडेट) के बाद, नेटवर्क फिर सामान्य दिख रहा है - इस समय 50-कुछ पीयर्स सक्रिय हैं, और irc तथा eepsites(I2P Sites) दोनों तक पहुँचा जा सकता है। अधिकांश परेशानी का कारण लैब स्थितियों के बाहर नए ट्रांसपोर्ट का अपर्याप्त परीक्षण था (उदा. सॉकेट्स का अजीब समय पर फेल होना, अत्यधिक विलंब, आदि)। अगली बार जब हमें उस लेयर में बदलाव करने होंगे, तो रिलीज़ से पहले हम इसका अधिक व्यापक रूप से परीक्षण करना सुनिश्चित करेंगे।

2) सुंदर तस्वीरें

पिछले कुछ दिनों में CVS में बड़ी संख्या में अपडेट हुए हैं, और जो नई चीजें जोड़ी गई हैं उनमें से एक नया सांख्यिकी लॉगिंग घटक है, जो हमें /stats.jsp पर संकलित किए गए साधारण औसतों से निपटने के बजाय, जैसे ही वे उत्पन्न होते हैं, कच्चे आँकड़े सीधे निकाल लेने देता है। इसके साथ, मैं कुछ routers पर कुछ प्रमुख आँकड़ों की निगरानी कर रहा हूँ, और हम शेष स्थिरता संबंधी मुद्दों का पता लगाने के और करीब पहुँच रहे हैं। कच्चे आँकड़े काफ़ी भारी-भरकम होते हैं (duck की मशीन पर 20 घंटे चलाने पर लगभग 60MB डेटा उत्पन्न हुआ), लेकिन यही वजह है कि हमारे पास सुंदर ग्राफ हैं - http://dev.i2p.net/~jrandom/stats/

उनमें से अधिकांश पर Y-अक्ष मिलीसेकंड में है, जबकि X-अक्ष सेकंड में है। ध्यान देने योग्य कुछ रोचक बातें हैं। सबसे पहले, client.sendAckTime.webp एक round trip (आवागमन) विलंब का काफ़ी अच्छा अनुमान देता है, क्योंकि ack (स्वीकृति) संदेश payload (वास्तविक डेटा) के साथ भेजा जाता है और फिर tunnel के पूरे पथ से होकर लौटता है—इस प्रकार, भेजे गए लगभग 33,000 सफल संदेशों में से भारी बहुमत का राउंड-ट्रिप समय 10 सेकंड से कम था। यदि हम फिर client.sendsPerFailure.webp को client.sendAttemptAverage.webp के साथ देखें, तो दिखता है कि 563 असफल भेजे गए प्रयासों में से लगभग सभी ने वे अधिकतम पुनः प्रयास किए जिन्हें हम अनुमति देते हैं (5; प्रति प्रयास 10s soft timeout (लचीली समय-सीमा) और 60s hard timeout (कठोर समय-सीमा)), जबकि अधिकांश अन्य प्रयास पहले या दूसरे प्रयास में ही सफल हो गए।

एक और दिलचस्प छवि client.timeout.webp है, जो मेरी एक परिकल्पना पर काफी संदेह पैदा करती है—कि संदेश भेजने में विफलताएँ किसी प्रकार की स्थानीय भीड़भाड़ से संबंधित थीं। प्लॉट किए गए डेटा से पता चलता है कि विफलताओं के दौरान inbound बैंडविड्थ का उपयोग व्यापक रूप से बदलता रहा, स्थानीय भेजने के प्रसंस्करण समय में कोई लगातार स्पाइक नहीं थे, और प्रतीत होता है कि tunnel परीक्षण विलंबता के साथ बिल्कुल भी कोई पैटर्न नहीं था।

फ़ाइलें dbResponseTime.webp और dbResponseTime2.webp, client.sendAckTime.webp के समान हैं, सिवाय इसके कि वे एंड-टू-एंड क्लाइंट संदेशों के बजाय netDb संदेशों के अनुरूप हैं।

transport.sendMessageFailedLifetime.webp यह दिखाता है कि किसी संदेश को किसी कारणवश असफल घोषित करने से पहले हम उसे स्थानीय रूप से कितनी देर तक रोके रखते हैं (उदाहरण के लिए, उसके समाप्ति समय तक पहुँच जाने पर या जिस पीयर (peer) को वह लक्षित कर रहा है उसके अप्राप्य होने पर)। कुछ असफलताएँ टालना संभव नहीं हैं, पर यह छवि दिखाती है कि स्थानीय भेजने के टाइमआउट (10s) के तुरंत बाद काफी संख्या में असफलताएँ हो रही हैं। इसे सुधारने के लिए हम कुछ काम कर सकते हैं: - पहला, हम शिटलिस्ट को अधिक अनुकूलनीय बना सकते हैं—हर बार स्थिर 4 मिनट की जगह शिटलिस्ट किए जाने की अवधि को घातीय रूप से बढ़ाते हुए। (यह पहले ही CVS में कमिट किया जा चुका है) - दूसरा, हम संदेशों को तब ही पहले से असफल कर सकते हैं जब स्पष्ट हो कि वे वैसे भी असफल होंगे। ऐसा करने के लिए, हर कनेक्शन अपनी भेजने की दर का हिसाब रखे, और जब भी उसकी क्यू में कोई नया संदेश जोड़ा जाए, यदि पहले से क्यू में पड़े बाइट्स की मात्रा को भेजने की दर से भाग देने पर प्राप्त समय, समाप्ति तक बचे समय से अधिक हो, तो संदेश को तुरंत असफल कर दें। हम इस मीट्रिक का उपयोग यह तय करते समय भी कर सकते हैं कि किसी पीयर के माध्यम से और अधिक tunnel अनुरोध स्वीकार किए जाएँ या नहीं।

खैर, अब अगली सुंदर तस्वीर पर चलते हैं - transport.sendProcessingTime.webp. इसमें आप देखते हैं कि यह विशेष मशीन बहुत अधिक विलंब के लिए शायद ही ज़िम्मेदार होती है - आमतौर पर 10-100ms, हालांकि कभी-कभी 1s या उससे अधिक तक उछाल आते हैं।

tunnel.participatingMessagesProcessed.webp में प्लॉट किया गया प्रत्येक बिंदु यह दर्शाता है कि जिन tunnel में वह router सहभागी था, उनमें कितने संदेश अग्रेषित किए गए। इसे संदेश के औसत आकार के साथ मिलाने पर हमें वह अनुमानित नेटवर्क लोड मिलता है जिसे peer (समकक्ष नोड) दूसरों के लिए वहन करता है।

अंतिम चित्र tunnel.testSuccessTime.webp है, जो यह दिखाता है कि किसी tunnel से बाहर एक संदेश भेजकर, फिर एक अन्य inbound tunnel के माध्यम से वापस घर आने में कितना समय लगता है, जिससे हमें यह अनुमान मिलता है कि हमारे tunnels कितने अच्छे हैं।

ठीक है, अभी के लिए इतनी सुंदर तस्वीरें काफ़ी हैं। आप 0.4.1.1-6 के बाद की किसी भी रिलीज़ के साथ, router कॉन्फ़िग प्रॉपर्टी “stat.logFilters” को stat नामों की कॉमा-सेपरेटेड सूची (नाम /stats.jsp पेज से ले लें) पर सेट करके डेटा स्वयं जनरेट कर सकते हैं। वह stats.log में डंप हो जाता है, जिसे आप के साथ प्रोसेस कर सकते हैं

java -cp lib/i2p.jar net.i2p.stat.StatLogFilter stat.log

जो इसे प्रत्येक आँकड़े (stat) के लिए अलग-अलग फ़ाइलों में विभाजित करता है, ताकि उन्हें आपके पसंदीदा टूल (उदाहरण के लिए gnuplot) में लोड किया जा सके।

3) 0.4.1.2 और 0.4.2

0.4.1.1 रिलीज़ के बाद से कई अपडेट हुए हैं (पूर्ण सूची के लिए इतिहास देखें), लेकिन अभी तक कोई गंभीर फिक्स नहीं हैं। हम उन्हें इस सप्ताह बाद में आने वाली अगली 0.4.1.2 पैच रिलीज़ में जारी करेंगे, जब IP स्वचालित पहचान (autodetection) से संबंधित कुछ लंबित बग सुलझा लिए जाएंगे।

उस समय अगला प्रमुख कार्य 0.4.2 तक पहुँचना होगा, जिसे फिलहाल tunnel processing के बड़े पुनर्गठन के रूप में तय किया गया है। इसमें बहुत काम लगेगा, एन्क्रिप्शन और संदेश प्रसंस्करण के साथ-साथ tunnel pooling का पुनरीक्षण करना होगा, लेकिन यह काफ़ी महत्वपूर्ण है, क्योंकि कोई हमलावर अभी tunnels पर अपेक्षाकृत आसानी से कुछ सांख्यिकीय हमले अंजाम दे सकता है (उदाहरण के लिए, predecessor (पूर्ववर्ती) के साथ यादृच्छिक tunnel ordering या netDb का एकत्रण)।

हालाँकि, dm ने यह प्रश्न उठाया कि क्या पहले streaming lib (स्ट्रीमिंग लाइब्रेरी) करना समझदारी होगी (वर्तमान में 0.4.3 रिलीज़ के लिए योजनाबद्ध)। उसका लाभ यह होगा कि नेटवर्क अधिक विश्वसनीय बनेगा और उसका थ्रूपुट बेहतर होगा, जिससे अन्य डेवलपर्स को क्लाइंट ऐप्स पर काम शुरू करने के लिए प्रोत्साहन मिलेगा। जब वह लागू हो जाएगा, तब मैं tunnel के पुनर्गठन पर लौट सकता हूँ और (उपयोगकर्ता को दिखाई न देने वाले) सुरक्षा मुद्दों को संबोधित कर सकता हूँ।

तकनीकी रूप से, 0.4.2 और 0.4.3 के लिए योजनाबद्ध दोनों कार्य परस्पर स्वतंत्र हैं, और दोनों वैसे भी हो ही जाएँगे, इसलिए उन्हें आपस में बदल देने में कोई खास नुकसान नहीं दिखता। मैं dm से सहमत होने की ओर हूँ, और जब तक कोई यह कारण नहीं बताता कि 0.4.2 को tunnel अपडेट ही रखा जाए और 0.4.3 को streaming lib, तब तक हम उनका क्रम बदल देंगे।

4) बंडल किया गया eepserver

जैसा कि 0.4.1 रिलीज़ नोट्स में उल्लेख किया गया था, हमने eepsite(I2P Site) चलाने के लिए आवश्यक सॉफ़्टवेयर और कॉन्फ़िगरेशन को पहले से साथ में शामिल कर दिया है ताकि यह तुरंत उपयोग के लिए तैयार हो - आप बस ./eepsite/docroot/ डायरेक्टरी में एक फ़ाइल रख दें और router कंसोल पर दिखने वाला I2P destination साझा कर दें।

हालाँकि .war फ़ाइलों के प्रति मेरे उत्साह पर कुछ लोगों ने सवाल उठाया - दुर्भाग्य से, अधिकांश ऐप्स को सिर्फ ./eepsite/webapps/ डायरेक्टरी में कोई फ़ाइल डाल देने से अधिक, थोड़ा और काम चाहिए। मैंने blojsom ब्लॉगिंग इंजन को चलाने पर एक संक्षिप्त ट्यूटोरियल तैयार किया है, और आप detonate की साइट पर देख सकते हैं कि वह कैसा दिखता है।

5) ???

फिलहाल मेरे पास बस इतना ही है — अगर आप कुछ चर्चा करना चाहते हैं तो 90 मिनट में बैठक में आ जाइए।

=jr