सभी को नमस्कार, देरी के लिए क्षमा करें…
अनुक्रमणिका:
- 0.4
- Capacity and overload
- Website updates
- I2PTunnel web interface
- Roadmap and todo
- ???
1) 0.4
जैसा कि मुझे यक़ीन है, आप सभी ने देखा होगा, 0.4 रिलीज़ कुछ दिन पहले ही आई थी और कुल मिलाकर, सब कुछ काफ़ी अच्छी तरह चल रहा है। यक़ीन करना मुश्किल है कि 0.3 आए हुए 6 महीने हो गए हैं (और 1.0 SDK (सॉफ्टवेयर डेवलपमेंट किट) जारी हुए एक साल हो गया है), लेकिन हमने बहुत लंबा सफ़र तय किया है, और आप सभी की कड़ी मेहनत, उत्साह, और धैर्य ने कमाल कर दिखाया है। बधाई और धन्यवाद!
किसी भी अच्छी रिलीज़ की तरह, जैसे ही यह जारी हुई, हमें कुछ समस्याएँ मिलीं, और पिछले कुछ दिनों से हम बग रिपोर्टें एकत्र कर रहे हैं और तेजी से पैचिंग कर रहे हैं (जैसे-जैसे उन्हें ठीक किया जाता है, आप बदलाव देख सकते हैं)। हमारे पास अभी भी अगला रिविज़न जारी करने से पहले ठीक करने के लिए कुछ और बग्स बचे हैं, लेकिन यह अगले एक-दो दिनों में हो जाना चाहिए।
2) क्षमता और ओवरलोड
पिछली कुछ रिलीज़ों में हमने tunnels के आवंटन में काफी असंतुलन देखा है, और उनमें से कुछ बग-संबंधित हैं (उनमें से दो 0.4 जारी होने के बाद ठीक किए जा चुके हैं), फिर भी एक सामान्य एल्गोरिदम से जुड़ा प्रश्न बना हुआ है - एक router को और अधिक tunnels स्वीकार करना कब बंद करना चाहिए?
कुछ रिविज़न पहले, हमने एक थ्रॉटलिंग कोड जोड़ा था जो, यदि router ओवरलोड था (स्थानीय संदेश प्रसंस्करण समय 1s से अधिक हो जाता है), तो tunnel में भाग लेने के अनुरोधों को अस्वीकार कर देता है, और इससे काफ़ी मदद मिली है। हालांकि, उस सरल एल्गोरिद्म के दो पहलू हैं जिन्हें संबोधित नहीं किया गया है: - जब हमारी बैंडविड्थ संतृप्त होती है, तब भी हमारा स्थानीय प्रसंस्करण समय तेज़ रह सकता है, इसलिए हम अधिक tunnel अनुरोध स्वीकार करते रहेंगे - जब कोई एकल पीयर “बहुत अधिक” tunnels में भाग लेता है, तो उनके विफल होने पर नेटवर्क को अधिक नुकसान होता है।
पहली समस्या को अपेक्षाकृत आसानी से केवल बैंडविड्थ सीमक (bandwidth limiter) सक्षम करके संभाला जा सकता है (क्योंकि बैंडविड्थ सीमित करना संदेश प्रसंस्करण समय को बैंडविड्थ विलंब के अनुरूप धीमा कर देता है)। दूसरी समस्या अधिक जटिल है, और इसके लिए अधिक शोध और अधिक सिमुलेशन आवश्यक हैं। मेरा विचार कुछ इस प्रकार है कि नेटवर्क में जिन tunnels में हम भाग ले रहे हैं और नेटवर्क से माँगे जा रहे tunnels के अनुपात के आधार पर, प्रायिकता के आधार पर tunnel अनुरोधों को अस्वीकार किया जाए, जिसमें कोई आधार “kindness factor” (उदारता कारक) शामिल हो; और यदि हमारी भागीदारी उससे कम हो, तो P(reject) = 0 रखा जाए।
लेकिन जैसा कि मैंने कहा, अधिक कार्य और सिमुलेशन आवश्यक है।
3) वेबसाइट अद्यतन
अब जब हमारे पास नया I2P वेब इंटरफ़ेस है, हमारी पुरानी एंड-यूज़र दस्तावेज़ीकरण का लगभग सारा हिस्सा अप्रचलित हो चुका है। हमें उन पृष्ठों की समीक्षा करके उन्हें वर्तमान स्थिति का वर्णन करने के लिए अद्यतन करने में मदद चाहिए। जैसा कि duck और अन्य लोगों ने सुझाव दिया है, हमें http://localhost:7657/ वाली readme के अतिरिक्त, उससे भी आगे जाने वाला एक नया ‘kickstart’ (त्वरित शुरुआत) गाइड चाहिए — ऐसा कुछ जो लोगों को जल्दी से तैयार करके सिस्टम में ले आए।
इसके अलावा, हमारे नए वेब इंटरफेस में संदर्भ-संवेदी सहायता को एकीकृत करने के लिए काफी जगह है। जैसा कि आप बंडल में शामिल help.jsp पर देख सकते हैं, “हम्म. शायद हमें यहाँ कुछ सहायता पाठ रखना चाहिए.”
It’d probably be great if we could add ‘about’ and/or ’troubleshooting’ links to the different pages, explaining what things mean and how to use them.
4) I2PTunnel वेब इंटरफ़ेस
नए http://localhost:7657/i2ptunnel/ इंटरफ़ेस को “बहुत सादा” कहना भी कम कहना होगा। इसे उपयोग योग्य स्थिति के क़रीब लाने के लिए हमें अभी बहुत काम करना है — इस समय तकनीकी तौर पर इसकी कार्यक्षमता मौजूद तो है, लेकिन उसका मतलब समझने के लिए आपको सच में यह जानना पड़ता है कि पर्दे के पीछे क्या चल रहा है। मुझे लगता है कि duck के पास इस बारे में कुछ और विचार हो सकते हैं, जो बैठक के दौरान उठाए जा सकते हैं।
5) कार्ययोजना और लंबित कार्य
रोडमैप को अद्यतन बनाए रखने में मुझसे ढिलाई होती रही है, लेकिन सच यह है कि हमारे सामने अभी कुछ और संशोधन बाकी हैं। मेरी नज़र में जो “big problems” हैं, उन्हें समझाने में मदद के लिए मैंने एक नई कार्य-सूची तैयार की है, जो प्रत्येक के बारे में कुछ विस्तार से बताती है। मेरा मानना है कि इस समय हमें अपने विकल्पों की समीक्षा के प्रति काफ़ी खुले रहना चाहिए और संभवतः रोडमैप को फिर से तैयार करना चाहिए।
उस टू-डू सूची में एक बात बताना रह गया है कि lightweight connection protocol (हल्का कनेक्शन प्रोटोकॉल) जोड़ते समय हम IP address की (वैकल्पिक) autodetection (स्वतः-पहचान) शामिल कर सकते हैं। यह ‘खतरनाक’ भी हो सकता है (इसीलिए यह वैकल्पिक होगा), लेकिन इससे हमें मिलने वाले सपोर्ट अनुरोधों की संख्या काफी कम हो जाएगी :)
खैर, टू-डू सूची में दर्ज वे मुद्दे वे ही हैं जिन्हें हमने अलग-अलग रिलीज़ के लिए निर्धारित किया है, और यह निश्चित है कि वे सभी 1.0 में, बल्कि 2.0 में भी, नहीं होंगे। मैंने कुछ अलग-अलग संभावित प्राथमिकता‑क्रम / रिलीज़ का खाका तैयार किया है, लेकिन मैं उन पर अभी अंतिम रूप से तय नहीं हूँ। फिर भी, अगर लोग आगे के लिए अन्य बड़े काम पहचान सकें, तो बहुत सराहा जाएगा, क्योंकि कोई भी अनियोजित मुद्दा हमेशा काफी सिरदर्द होता है।
6) ???
ठीक है, फिलहाल मेरे पास कहने के लिए बस इतना ही (और अच्छा ही है, क्योंकि बैठक कुछ ही मिनटों में शुरू होने वाली है)। आगे बातचीत के लिए GMT के अनुसार रात 9 बजे irc.freenode.net पर #i2p, www.invisiblechat.com, या irc.duck.i2p पर आइए।