نظرة عامة
بروتوكول شبكة I2P (I2NP)، الذي يقع بين I2CP والبروتوكولات النقل المختلفة لـ I2P، يُعنى بإدارة توجيه وخلط الرسائل بين الراوترات، وكذلك اختيار وسائط النقل المستخدمة عند التواصل مع ندّ يدعم عدة وسائط نقل مشتركة.
تعريف I2NP
يمكن استخدام رسائل I2NP (بروتوكول شبكة I2P) للرسائل من نوع “وجهة واحدة”، أو من نوع “راوتر إلى راوتر”، أو من نوع “نقطة إلى نقطة”. وبتشفير الرسائل ولفّها داخل رسائل أخرى، يمكن إرسالها بطريقة آمنة عبر عدة محطات وسيطة حتى تصل إلى الوجهة النهائية. ويُستخدم الأولوية فقط محليًا في نقطة المنشأ، أي عند ترتيبها في قائمة الانتظار للإرسال الخارجي.
قد لا تكون الأولويات المذكورة أدناه حالية وتخضع للتغيير. وقد تختلف طريقة تنفيذ قائمة الانتظار حسب الأولوية.
تنسيق الرسالة
تحدد الجدول التالي الرأس التقليدي بحجم 16 بايت المستخدم في NTCP. تستخدم وسائط النقل 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 كيلوبايت.
بالإضافة إلى ذلك، قد تكون هناك قيود إضافية على وسائل النقل. فإن الحد الأقصى لـ NTCP هو 16 كيلوبايت - 6 = 16378 بايت. والحد الأقصى لـ SSU هو تقريبًا 32 كيلوبايت. والحد الأقصى لـ NTCP2 هو تقريبًا 64 كيلوبايت - 20 = 65516 بايت، وهو أعلى مما يمكن أن تدعمه النفق.
لاحظ أن هذه ليست الحدود الخاصة بحزم البيانات التي يراها العميل، لأن الموجه قد يجمع مجموعة تأجير (leaseset) و/أو علامات جلسة (session tags) مع رسالة العميل ضمن رسالة ثومية (garlic message). حيث يمكن أن تضيف مجموعة التأجير والعلامات معًا حوالي 5.5 كيلوبايت. وبالتالي فإن الحد الحالي لحزمة البيانات هو حوالي 10 كيلوبايت. وسيتم زيادة هذا الحد في إصدار قادم.
أنواع الرسائل
كلما كان الرقم الأعلى أولوية أعلى. إن الجزء الأكبر من حركة المرور يتكون من TunnelDataMessages (الأولوية 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 للحصول على مواصفات البروتوكول الكاملة. انظر أيضًا صفحة مواصفات هياكل البيانات المشتركة .
العمل المستقبلي
ليست واضحة ما إذا كان نظام الأولوية الحالي فعالًا بشكل عام، أو ما إذا كان ينبغي تعديل أولويات الرسائل المختلفة أكثر. هذا موضوع يحتاج إلى مزيد من البحث والتحليل والاختبار.