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

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

  1. 0.4.1.2
  2. 0.4.1.3
  3. 0.4.2
  4. mail discussions
  5. ???

1) 0.4.1.2

नया 0.4.1.2 रिलीज़ कुछ दिन पहले जारी हुआ था और चीज़ें काफी हद तक उम्मीद के मुताबिक चल रही हैं—हालाँकि नए watchdog घटक के साथ कुछ अड़चनें आई हैं, जिनके चलते वह स्थिति Bad होने पर आपके router को रीस्टार्ट करने के बजाय किल कर देता है। जैसा कि मैंने आज पहले भी बताया था, मैं चाहता हूँ कि लोग नए stats logging टूल का उपयोग करके मुझे कुछ डेटा भेजें, इसलिए इसमें आपकी मदद की बहुत सराहना की जाएगी।

2) 0.4.1.3

0.4.2 के जारी होने से पहले एक और रिलीज़ होगी, क्योंकि मैं आगे बढ़ने से पहले चाहता हूँ कि नेटवर्क जितना संभव हो उतना मजबूत हो। मैं इस समय जिस चीज़ के साथ प्रयोग कर रहा हूँ वह tunnel भागीदारी पर एक गतिशील थ्रॉटल है - routers को निर्देश देना कि यदि वे ट्रैफ़िक से भर गए हों या उनके tunnels सामान्य से धीमे हों, तो वे अनुरोधों को संभाव्यता के आधार पर अस्वीकार करें। इन संभावनाओं और सीमा-मानों की गणना रखे जा रहे आँकड़ों से गतिशील रूप से की जाती है - यदि आपका 10 मिनट का tunnel परीक्षण समय आपके 60 मिनट के tunnel परीक्षण समय से अधिक है, तो 60minRate/10minRate की संभावना के साथ उस tunnel अनुरोध को स्वीकार करें (और यदि आपके वर्तमान tunnels की संख्या आपके 60 मिनट के औसत tunnels की संख्या से अधिक है, तो इसे p=60mRate/curTunnels के साथ स्वीकार करें)।

एक और संभावित थ्रॉटल यह है कि उसी तर्ज पर बैंडविड्थ के उतार-चढ़ाव को समतल किया जाए - जब हमारी बैंडविड्थ उपयोग में उछाल आए, तो tunnels को प्रायिकता-आधारित तरीके से अस्वीकार किया जाए। वैसे, इन सबका उद्देश्य नेटवर्क उपयोग को फैलाना और अधिक लोगों में tunnels का संतुलित वितरण करना है। लोड बैलेंसिंग के साथ हमारी मुख्य समस्या क्षमता के अत्यधिक अधिशेष की रही है, और इसी कारण हमारे “धत्त, हम धीमे हैं, चलो अस्वीकार करें” ट्रिगर्स में से कोई भी सक्रिय नहीं हुआ। उम्मीद है कि ये नए प्रायिकता-आधारित उपाय तेज बदलाव को नियंत्रण में रखेंगे।

मेरे पास यह बताने की कोई निश्चित योजना नहीं है कि 0.4.1.3 रिलीज़ कब आएगी - शायद सप्ताहांत में। लोग जो डेटा भेजेंगे (जैसा ऊपर बताया गया है) उससे यह तय करने में मदद मिलनी चाहिए कि यह सार्थक होगा या नहीं, या फिर क्या अन्य अधिक सार्थक विकल्प मौजूद हैं।

3) 0.4.2

जैसा कि हमने पिछले सप्ताह की बैठक में चर्चा की थी, हमने 0.4.2 और 0.4.3 रिलीज़ों की अदला-बदली कर दी है - 0.4.2 नई स्ट्रीमिंग लाइब्रेरी होगी, और 0.4.3 tunnel अपडेट होगा.

I’ve been rereviewing the literature for TCP’s streaming functionality and there are some interesting topics of concern for I2P. Specifically, our high round trip time leans towards something like XCP, and we should probably be quite aggressive with various forms of explicit congestion notification, though we can’t take advantage of something like the timestamp option, since our clocks can be skewed by up to a minute.

इसके अलावा, हम यह सुनिश्चित करना चाहेंगे कि हम streaming lib (स्ट्रीमिंग लाइब्रेरी) को अल्पकालिक कनेक्शनों को संभालने के लिए अनुकूलित कर सकें (जिसमें साधारण TCP का प्रदर्शन काफ़ी कमजोर है) - उदाहरण के लिए, मैं सक्षम होना चाहता हूँ कि मैं छोटे (<32KB) HTTP GET अनुरोध और छोटे (<32KB) उत्तर वास्तव में केवल तीन संदेशों में भेज सकूँ:

Alice-->Bob: syn+data+close
Bob-->Alice: ack+data+close (the browser gets the response now)
Alice-->Bob: ack (so he doesn't resend the payload)

खैर, अभी तक बहुत अधिक कोड नहीं लिखा गया है; प्रोटोकॉल पक्ष काफी हद तक TCP जैसा दिख रहा है और पैकेट कुछ हद तक human के प्रस्ताव और पुराने प्रस्ताव के मेल जैसे हैं। यदि किसी के पास कोई सुझाव या विचार हों, या वे कार्यान्वयन में मदद करना चाहें, तो कृपया संपर्क करें।

4) ईमेल चर्चा

I2P के भीतर (और बाहर) ईमेल के बारे में कुछ दिलचस्प चर्चाएँ हुई हैं - postman ने विचारों का एक सेट ऑनलाइन रखा है और सुझावों की तलाश में है। संबंधित चर्चाएँ #mail.i2p पर भी हुई हैं। शायद हम postman से हमें एक अपडेट देने के लिए कह सकते हैं?

5) ???

फिलहाल के लिए इतना ही। कुछ ही मिनट में बैठक में आ जाना और अपनी टिप्पणियाँ साथ लाना :)

=jr