अवलोकन
I2P नेटवर्क प्रोटोकॉल (I2NP), जो I2CP तथा विभिन्न I2P परिवहन प्रोटोकॉल के बीच स्थित है, राउटरों के बीच संदेशों के मार्गदर्शन और मिश्रण के साथ-साथ उस पीयर के साथ संचार के लिए किन परिवहन प्रोटोकॉल का उपयोग करना है, इसके चयन का प्रबंधन करता है, जिसके लिए कई सामान्य परिवहन प्रोटोकॉल समर्थित हैं।
I2NP परिभाषा
I2NP (I2P नेटवर्क प्रोटोकॉल) संदेशों का उपयोग एक-हॉप, राउटर-से-राउटर, पॉइंट-टू-पॉइंट संदेशों के लिए किया जा सकता है। संदेशों को अन्य संदेशों में एन्क्रिप्ट और लपेटकर, उन्हें अंतिम गंतव्य तक कई हॉप्स के माध्यम से सुरक्षित तरीके से भेजा जा सकता है। प्राथमिकता का उपयोग केवल उत्पत्ति स्थल पर स्थानीय स्तर पर किया जाता है, अर्थात आउटबाउंड डिलीवरी के लिए कतार में लगाते समय।
नीचे सूचीबद्ध प्राथमिकताएँ वर्तमान नहीं हो सकती हैं और परिवर्तन के अधीन हैं। प्राथमिकता कतार लागूकरण में भिन्नता हो सकती है।
संदेश प्रारूप
निम्नलिखित तालिका NTCP में उपयोग किए जाने वाले पारंपरिक 16-बाइट हेडर को निर्दिष्ट करती है। SSU और NTCP2 ट्रांसपोर्ट संशोधित हेडर का उपयोग करते हैं।
| Field | Bytes |
|---|---|
| Type | 1 |
| Unique ID | 4 |
| Expiration | 8 |
| Payload Length | 2 |
| Checksum | 1 |
| Payload | 0 - 61.2KB |
अधिकतम फ्रैगमेंट्स की संख्या 64 है, और संदेश पूरी तरह संरेखित नहीं हो सकता है, इसलिए संदेश को आम तौर पर 63 फ्रैगमेंट्स में फिट होना चाहिए।
एक प्रारंभिक खंड का अधिकतम आकार 956 बाइट्स है (TUNNEL डिलीवरी मोड मानते हुए); एक अनुवर्ती खंड का अधिकतम आकार 996 बाइट्स है। इसलिए अधिकतम आकार लगभग 956 + (62 * 996) = 62708 बाइट्स, या 61.2 KB है।
इसके अतिरिक्त, ट्रांसपोर्ट में अतिरिक्त प्रतिबंध हो सकते हैं। NTCP सीमा 16KB - 6 = 16378 बाइट्स है। SSU सीमा लगभग 32 KB है। NTCP2 सीमा लगभग 64KB - 20 = 65516 बाइट्स है, जो किसी टनल द्वारा समर्थित सीमा से अधिक है।
ध्यान दें कि ये वे सीमाएं नहीं हैं जो क्लाइंट डेटाग्राम के लिए देखता है, क्योंकि राउटर एक गैरलिक संदेश में क्लाइंट संदेश के साथ एक रिप्लाई लीज़सेट और/या सत्र टैग्स को एक साथ पैक कर सकता है। लीज़सेट और टैग्स मिलकर लगभग 5.5KB जोड़ सकते हैं। इसलिए वर्तमान डेटाग्राम सीमा लगभग 10KB है। भविष्य के संस्करण में इस सीमा में वृद्धि की जाएगी।
संदेश प्रकार
उच्च संख्या वाली प्राथमिकता का अर्थ है उच्च प्राथमिकता। अधिकांश ट्रैफ़िक TunnelDataMessages (प्राथमिकता 400) होता है, इसलिए 400 से ऊपर कुछ भी व्यावहारिक रूप से उच्च प्राथमिकता का होता है, और 400 से नीचे कुछ भी निम्न प्राथमिकता का होता है। ध्यान दें कि कई संदेशों को आमतौर पर क्लाइंट टनल के बजाय अन्वेषणात्मक टनल के माध्यम से रूट किया जाता है, और इसलिए जब तक पहले छलांग (हॉप्स) संयोगवश एक ही पीयर पर न हों, तब तक वे समान कतार में नहीं हो सकते।
इसके अलावा, सभी संदेश प्रकार एन्क्रिप्टेड किए बिना भेजे नहीं जाते हैं। उदाहरण के लिए, एक टनल का परीक्षण करते समय, राउटर एक DeliveryStatusMessage को लपेटता है, जिसे GarlicMessage में लपेटा जाता है, जिसे बदले में DataMessage में लपेटा जाता है।
| Message | Type | Payload Length | Priority | Comments |
|---|---|---|---|---|
| DatabaseLookupMessage | 2 | 500 | May vary | |
| DatabaseSearchReplyMessage | 3 | Typ. 161 | 300 | Size is 65 + 32*(number of hashes) where typically, the hashes for three floodfill routers are returned. |
| DatabaseStoreMessage | 1 | Varies | 460 | Priority may vary. Size is 898 bytes for a typical 2-lease leaseSet. RouterInfo structures are compressed, and size varies; however there is a continuing effort to reduce the amount of data published in a RouterInfo. |
| DataMessage | 20 | 4 - 62080 | 425 | Priority may vary on a per-destination basis |
| DeliveryStatusMessage | 10 | 12 | Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage | |
| GarlicMessage | 11 | Generally wrapped in a DataMessage - but when unwrapped, given a priority of 100 by the forwarding router | ||
| TunnelBuildMessage | 21 | 4224 | 500 | |
| TunnelBuildReplyMessage | 22 | 4224 | 300 | |
| TunnelDataMessage | 18 | 1028 | 400 | The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was reduced to 200 as of release 0.6.1.33. Outbound gateway messages (i.e. those originated locally) remains at 400. |
| TunnelGatewayMessage | 19 | 300/400 | ||
| VariableTunnelBuildMessage | 23 | 1057 - 4225 | 500 | Shorter TunnelBuildMessage as of 0.7.12 |
| VariableTunnelBuildReplyMessage | 24 | 1057 - 4225 | 300 | Shorter TunnelBuildReplyMessage as of 0.7.12 |
| Others (Types 0, 4-9, 12) | 0, 4-9, 12 | Obsolete, Unused |
पूर्ण प्रोटोकॉल विनिर्देश के लिए I2NP विनिर्देश पृष्ठ देखें। साथ ही सामान्य डेटा संरचना विनिर्देश पृष्ठ भी देखें।
भावी कार्य
यह स्पष्ट नहीं है कि वर्तमान प्राथमिकता योजना सामान्य रूप से प्रभावी है या नहीं, और विभिन्न संदेशों के लिए प्राथमिकताओं को आगे समायोजित करने की आवश्यकता है या नहीं। यह आगे के अनुसंधान, विश्लेषण और परीक्षण का विषय है।