अवलोकन
यह प्रस्ताव आउटबाउंड टनल्स के लिए एक I2CP विकल्प जोड़ता है जो संदेश भेजे जाने पर टनल्स का चयन या निर्माण करता है ताकि OBEP लक्ष्य Destination के LeaseSet के किसी IBGW से मेल खाता हो।
प्रेरणा
अधिकांश I2P राउटर भीड़ प्रबंधन के लिए एक प्रकार की पैकेट-ड्रॉपिंग का उपयोग करते हैं। संदर्भ कार्यान्वयन एक WRED रणनीति का उपयोग करता है जो दोनों संदेश आकार और यात्रा दूरी को ध्यान में रखता है (देखें tunnel throttling दस्तावेज़)। इस रणनीति के कारण, पैकेट हानि का मुख्य स्रोत OBEP है।
डिज़ाइन
जब एक संदेश भेजा जाता है, तो प्रेषक एक टनल का चयन या निर्माण करता है जिसका OBEP प्राप्तकर्ता के IBGW में से किसी एक के समान राउटर होता है। ऐसा करके, संदेश सीधे एक टनल से बाहर निकल जाएगा और दूसरे में प्रवेश करेगा, बिना बीच में वायर पर भेजे जाने की आवश्यकता के।
सुरक्षा प्रभाव
यह मोड प्रभावी रूप से मतलब होगा कि प्राप्तकर्ता प्रेषक के OBEP का चयन कर रहा है। वर्तमान गोपनीयता को बनाए रखने के लिए, यह मोड आउटबाउंड टनल्स को आउटबाउंड.length I2CP विकल्प द्वारा निर्दिष्ट से एक हॉप लंबा बनाने का कारण बनेगा (अंतिम हॉप संभवतः प्रेषक के तेज़ टीयर के बाहर हो सकता है)।
विनिर्देशन
I2CP विनिर्देशन के लिए एक नया I2CP विकल्प जोड़ा गया है:
outbound.matchEndWithTarget
बूलियन
डिफ़ॉल्ट मूल्य: मामले-विशिष्ट
यदि सत्य है, तो राउटर इस सत्र के दौरान भेजे गए संदेशों के लिए आउटबाउंड टनल्स का चयन करेगा ताकि टनल का OBEP लक्ष्य Destination के IBGWs में से एक हो। यदि ऐसा कोई टनल मौजूद नहीं है, तो राउटर एक का निर्माण करेगा।
संगतता
पिछली संगतता सुनिश्चित की गई है, क्योंकि राउटर हमेशा संदेश खुद को भेज सकते हैं।
कार्यान्वयन
Java I2P
टनल निर्माण और संदेश भेजना वर्तमान में अलग उपप्रणालियां हैं:
BuildExecutor केवल आउटबाउंड टनल पूल के आउटबाउंड.* विकल्पों के बारे में जानता है और उनके उपयोग के संबंध में कोई दृश्यता नहीं है।
OutboundClientMessageOneShotJob केवल मौजूदा पूल से एक टनल का चयन कर सकता है; यदि एक क्लाइंट संदेश आता है और कोई आउटबाउंड टनल नहीं है, तो राउटर संदेश को ड्रॉप करता है।
इस प्रस्ताव को लागू करना इन दो उपप्रणालियों को इंटरैक्ट करने के लिए एक तरीका डिजाइन करने की आवश्यकता होगी।
i2pd
एक परीक्षण कार्यान्वयन पूरा हो चुका है।
प्रदर्शन
इस प्रस्ताव के कई प्रभाव हैं जैसे विलंबता, RTT और पैकेट हानि:
संभावना है कि अधिकांश मामलों में, इस मोड के लिए पहले संदेश पर एक नया टनल बनाने की आवश्यकता होगी बजाय कि मौजूदा टनल का उपयोग करने के, जिससे विलंबता बढ़ती है।
मानक टनल्स के लिए, OBEP को IBGW ढूंढना और कनेक्ट करना पड़ सकता है, जिससे विलंबता बढ़ जाती है जो पहले RTT को बढ़ा सकती है (क्योंकि यह पहले पैकेट के भेजे जाने के बाद होता है)। इस मोड का उपयोग करते समय, OBEP को टनल बिल्डिंग के दौरान IBGW से कनेक्ट करना होगा, जिससे समान विलंबता बढ़ जाती है लेकिन पहले RTT को कम कर देती है (क्योंकि यह पहले पैकेट के भेजे जाने से पहले होता है)।
वर्तमान मानक VariableTunnelBuild आकार 2641 बाइट्स है। इस तरह यह उम्मीद की जाती है कि इस मोड का परिणाम सामान्य संदेश आकार जो इस से बड़ा है, के लिए कम पैकेट हानि का होगा।
इन प्रभावों की जांच करने के लिए अधिक शोध आवश्यक है, ताकि निर्णय लिया जा सके कि किन मानक टनल्स को इस मोड का डिफ़ॉल्ट रूप से सक्षम होने का लाभ होगा।