अवलोकन
इस प्रस्ताव में नेटवर्क प्रदर्शन को सुधारने के लिए दो सुधारों पर ध्यान दिया गया है:
IBGW चयन को OBEP को सौंपना, उसे एक विकल्प की जगह विकल्पों की एक सूची प्रदान कर।
OBEP पर मल्टीकास्ट पैकेट रूटिंग को सक्षम करना।
प्रेरणा
प्रत्यक्ष कनेक्शन के मामले में, विचार यह है कि कनेक्शन भीड़ को कम किया जाए, OBEP को IBGWs से जुड़ने में लचीलापन देकर। एकाधिक टनल्स को निर्दिष्ट करने की क्षमता हमें OBEP पर मल्टीकास्ट को लागू करने में सक्षम बनाती है (सभी निर्दिष्ट टनल्स तक संदेश पहुंचा कर)।
इस प्रस्ताव के प्रतिनिधित्व भाग का एक विकल्प होगा एक LeaseSet हैश के माध्यम से भेजना, जैसा कि मौजूदा क्षमता के समान है एक लक्ष्य RouterIdentity हैश निर्दिष्ट करने की। इससे संदेश छोटा होगा और संभावित रूप से नया LeaseSet मिलेगा। हालाँकि:
इससे OBEP को एक लुकअप करना मजबूर होगा
LeaseSet फडफिल पर प्रकाशित नहीं हो सकता है, इसलिए लुकअप विफल होगा।
LeaseSet एन्क्रिप्टेड हो सकता है, इसलिए OBEP लीज़ प्राप्त नहीं कर पाएगा।
LeaseSet निर्दिष्ट करने से OBEP को संदेश के Destination का पता चलता है, जिसे वे अन्यथा नेटवर्क में सभी LeaseSets को स्क्रैप करके और एक लीज़ मैच खोजकर ही जान सकते थे।
डिज़ाइन
उद्गमकर्ता (OBGW) कुछ (सभी?) लक्षित Leases को डिलीवरी निर्देश TUNNEL-DELIVERY में रखेगा बजाय इसके कि केवल एक चयन करें।
OBEP उन में से एक को डिलीवर करने के लिए चुनेगा। OBEP एक का चयन करेगा, यदि उपलब्ध हो, वह जिसे वह पहले से जुड़ा हुआ है, या जिसे पहले से जानता है। इससे OBEP-IBGW पथ तेज और अधिक विश्वसनीय हो जाएगा और कुल नेटवर्क कनेक्शन्स कम होंगी।
हमारे पास एक अप्रयुक्त डिलीवरी प्रकार (0x03) और दो शेष बिट्स (0 और 1) TUNNEL-DELIVERY के लिए झंडे में हैं, जिन्हें हम इन विशेषताओं को लागू करने के लिए लाभ उठा सकते हैं।
सुरक्षा प्रभाव
यह प्रस्ताव OBGW’s के लक्ष्य गंतव्य या NetDB के उनके दृष्टिकोण के बारे में लीक की गई जानकारी की मात्रा को नहीं बदलता है:
एक प्रतिद्वंद्वी जो OBEP को नियंत्रित करता है और NetDB से LeaseSets को स्क्रैप कर रहा है, पहले से ही यह निर्धारित कर सकता है कि क्या एक संदेश विशेष गंतव्य पर भेजा जा रहा है, TunnelId / RouterIdentity जोड़ी को खोजकर। सबसे खराब स्थिति में, TMDI में एकाधिक लीज़ की उपस्थिति इसे प्रतिद्वंद्विता के डेटाबेस में मैच खोजने के लिए तेज़ बना सकती है।
एक प्रतिद्वंद्वी जो एक दुष्ट गंतव्य चला रहा है, पहले से ही एक कनेक्टिंग पीड़ित की NetDB के दृश्य के बारे में जानकारी प्राप्त कर सकता है, विभिन्न फडफिल्स पर विभिन्न इनबाउंड टनल्स वाले LeaseSets को प्रकाशित करके, और यह देखकर कि OBGW कौन से टनल्स के माध्यम से कनेक्ट होता है। उनकी दृष्टि से, उपयोग करने के लिए टनल का चयन करने के लिए OBEP कार्यात्मक रूप से OBGW के चयन करने के समान होता है।
मल्टीकास्ट फ़्लैग इस तथ्य को लीक करता है कि OBGW OBEPs को मल्टीकास्टिंग कर रहा है। यह प्रदर्शन बनाम गोपनीयता व्यापार-बंद बनाता है जिसे उच्च-स्तरीय प्रोटोकॉल लागू करते समय विचार किया जाना चाहिए। एक वैकल्पिक फ़्लैग होने के नाते, उपयोगकर्ता अपनी एप्लिकेशन के लिए उपयुक्त निर्णय ले सकते हैं। इसके बावजूद, संगत एप्लिकेशनों के लिए यह डिफ़ॉल्ट व्यवहार होने के लाभ हो सकते हैं, क्योंकि विभिन्न एप्लिकेशनों द्वारा व्यापक उपयोग यह जानकारी रिसाव को कम कर देगा कि विशेष रूप से कौन सी एप्लिकेशन से संदेश प्राप्त हो रहा है।
विशेष विवरण
प्रथम खंड डिलीवरी निर्देशों TUNNEL-DELIVERY को निम्नानुसार संशोधित किया जाएगा:
+----+----+----+----+----+----+----+----+
|flag| Tunnel ID (opt) | |
+----+----+----+----+----+ +
| |
+ +
| To Hash (optional) |
+ +
| |
+ +----+----+----+
| |dly | Message
+----+----+----+----+----+----+----+----+
ID (opt) |extended opts (opt)|cnt | (o)
+----+----+----+----+----+----+----+----+
Tunnel ID N | |
+----+----+----+ +
| |
+ +
| To Hash N (optional) |
+ +
| |
+ +----+----+----+----+----+
| | Tunnel ID N+1 (o) | |
+----+----+----+----+----+----+----+ +
| |
+ +
| To Hash N+1 (optional) |
+ +
| |
+ +----+
| | sz
+----+----+----+----+----+----+----+----+
|
+----+
flag ::
1 byte
बिट क्रम: 76543210
बिटस 6-5: डिलीवरी प्रकार
0x03 = TUNNELS
बिट 0: मल्टीकास्ट? यदि 0, टनल्स में से एक को डिलीवर करें
यदि 1, सभी टनल्स में डिलीवर करें
यदि डिलीवरी प्रकार TUNNELS नहीं है, तो भविष्य के उपयोगों के साथ संगतता के लिए इसे 0 पर सेट करें
Count ::
1.byte
वैकल्पिक, उपस्थित यदि डिलीवरी प्रकार TUNNELS है
2-255 - अनुसरण करने के लिए id/hash जोड़े की संख्या
Tunnel ID :: `TunnelId`
To Hash ::
36 bytes प्रत्येक
वैकल्पिक, उपस्थित यदि डिलीवरी प्रकार TUNNELS है
id/hash जोड़े
पूर्ण लंबाई: विशिष्ट लंबाई है:
75 बाइट्स गिनती 2 TUNNELS डिलीवरी (अविभाजित टनल संदेश);
79 बाइट्स गिनती 2 TUNNELS डिलीवरी (प्रथम खंड)
शेष डिलीवरी निर्देश अपरिवर्तित
संगतता
केवल वे साथियों को नई विशिष्टता को समझने की आवश्यकता है जो OBGWs और OBEPs हैं। इसलिए हम इस परिवर्तन को मौजूदा नेटवर्क के साथ संगत बना सकते हैं लक्ष्य I2P संस्करण VERSIONS पर इसके उपयोग को सशर्त बना कर:
OBGWs को आउटबाउंड टनल्स बनाते समय संगत OBEPs का चयन करना होगा, उनके RouterInfo में विज्ञापित I2P संस्करण के आधार पर।
लक्ष्य संस्करण का विज्ञापन करने वाले साथियों को नए झंडों को पार्स करने का समर्थन करना होगा, और निर्द
्शों को अवैध के रूप में अस्वीकार नहीं करना चाहिए।