नमस्ते आप सब, आज फिर मंगलवार है
अनुक्रमणिका
- 0.4.1.3
- Tunnel test time, and send processing time
- Streaming lib
- files.i2p
- ???
1) 0.4.1.3
0.4.1.3 रिलीज़ एक-दो दिन पहले आई थी और लगता है कि अधिकांश लोगों ने अपग्रेड कर लिया है (धन्यवाद!). नेटवर्क काफ़ी ठीक काम कर रहा है, लेकिन विश्वसनीयता में अभी भी कोई क्रांतिकारी बढ़ोतरी नहीं है। हालांकि, 0.4.1.2 के वॉचडॉग बग्स दूर हो गए हैं (या कम से कम किसी ने उनका उल्लेख नहीं किया है)। मेरा लक्ष्य है कि यह 0.4.1.3 रिलीज़ 0.4.2 से पहले का आख़िरी पैच हो; बेशक, अगर कोई बड़ी बात सामने आती है जिसे ठीक करने की ज़रूरत हो, तो हम एक और जारी करेंगे।
2) Tunnel परीक्षण समय, और प्रेषण प्रसंस्करण समय
0.4.1.3 रिलीज़ में सबसे महत्वपूर्ण बदलाव tunnel परीक्षण में थे - एक स्थिर (30 सेकंड!) की परीक्षण अवधि रखने के बजाय, अब हमारे पास मापे गए प्रदर्शन से व्युत्पन्न कहीं अधिक आक्रामक टाइमआउट्स हैं। यह अच्छी बात है, क्योंकि अब हम tunnels को विफल के रूप में चिह्नित करते हैं जब वे किसी उपयोगी काम के लिए बहुत धीमे होते हैं। हालाँकि, यह बुरा भी है, क्योंकि कभी-कभी tunnels अस्थायी रूप से जाम हो जाते हैं, और यदि हम उस अवधि के दौरान उनका परीक्षण करते हैं तो हम ऐसे tunnel को विफल घोषित कर देते हैं जो अन्यथा काम कर सकता था।
एक हालिया प्लॉट, जो दिखाता है कि एक router पर tunnel परीक्षण में कितना समय लगता है:
ये सामान्यतः ठीक-ठाक tunnel परीक्षण समय हैं — वे 4 दूरस्थ peers (पीयर्स) से होकर गुजरते हैं (2 hop tunnels के साथ), जिससे उनमें से अधिकांश को प्रति hop (हॉप) ~1-200ms लगते हैं। हालांकि, जैसा कि आप देख सकते हैं, ऐसा हमेशा नहीं होता — कभी-कभी प्रति hop के लिए सेकंडों के क्रम का समय लग जाता है।
यहीं यह अगला प्लॉट काम आता है - वह कतार में प्रतीक्षा का समय जब एक विशेष router कोई संदेश भेजना चाहता था से लेकर जब वह संदेश socket (नेटवर्क सॉकेट) से फ्लश होकर बाहर निकला:
लगभग 95% मामलों में समय 50ms से कम होता है, लेकिन स्पाइक्स बहुत खराब हैं।
हमें उन उछालों को खत्म करना है, और साथ ही अधिक विफल होने वाले peers (समकक्ष नोड्स) वाली स्थितियों से निपटने का उपाय भी निकालना है। जैसा कि अभी स्थिति है, जब हम किसी peer के हमारे tunnels को विफल करने के बारे में ‘सीखते’ हैं, तो हम वास्तव में उनके router के बारे में कोई विशेष बात नहीं जान रहे होते - वे उछाल ऐसे समय पर भी उच्च क्षमता वाले peers को धीमा दिखा सकते हैं, यदि हमारा सामना ठीक उसी समय उनसे हो जाए।
3) स्ट्रीमिंग लाइब्रेरी
विफल हो रही tunnels से निपटने का दूसरा भाग आंशिक रूप से streaming lib (स्ट्रीमिंग लाइब्रेरी) के माध्यम से पूरा किया जाएगा — जो हमें कहीं अधिक मज़बूत एंड-टू-एंड स्ट्रीमिंग संचार देगी। यह चर्चा नई नहीं है — lib वे सारी उन्नत क्षमताएँ प्रदान करेगी जिनके बारे में हम कुछ समय से बात कर रहे हैं (और बेशक, उसमें अपने हिस्से के बग्स भी होंगे)। इस मोर्चे पर काफ़ी प्रगति हुई है, और कार्यान्वयन शायद 60% तक पहुँच चुका है।
जैसे ही कुछ नया होगा, हम आपको बताएँगे।
4) files.i2p
ठीक है, हाल ही में हमारे पास बहुत‑सी नई eepsites(I2P Sites) आई हैं, जो वाकई जबरदस्त हैं। मैं खास तौर पर इस एक का ज़िक्र करना चाहता हूँ, क्योंकि इसमें हम सबके लिए एक काफ़ी बढ़िया फ़ीचर है। यदि आप files.i2p पर नहीं गए हैं, तो यह मूलतः एक Google‑जैसा सर्च इंजन है, जिसमें यह जिन साइटों को क्रॉल करता है उनका कैश भी रहता है (ताकि जब eepsite(I2P Site) ऑफ़लाइन हो तब भी आप खोज और ब्राउज़ कर सकें)। बहुत बढ़िया।
5) ???
इस सप्ताह के स्थिति नोट्स काफी संक्षिप्त हैं, लेकिन बहुत कुछ चल रहा है - - मेरे पास बैठक से पहले और लिखने का समय नहीं है। तो, कुछ ही मिनटों में #i2p पर आ जाइए और हम जो भी बातें मैंने मूर्खतावश नज़रअंदाज़ कर दी हों, उन पर चर्चा कर सकते हैं।
=jr