نظرة عامة على Datagram
تعتمد الـ Datagrams على I2CP الأساسي لتوفير رسائل موثقة وقابلة للرد بتنسيق معياري. هذا يتيح للتطبيقات قراءة عنوان “المرسل” من الـ datagram بشكل موثوق ومعرفة أن العنوان قد أرسل الرسالة فعلاً. هذا ضروري لبعض التطبيقات لأن رسالة I2P الأساسية خام تماماً - ليس لديها عنوان “مرسل” (على عكس حزم IP). بالإضافة إلى ذلك، يتم توثيق الرسالة والمرسل من خلال توقيع الحمولة.
الـ Datagrams، مثل حزم مكتبة البث المتدفق ، هي بنية على مستوى التطبيق. هذه البروتوكولات مستقلة عن وسائل النقل منخفضة المستوى؛ يتم تحويل البروتوكولات إلى رسائل I2NP بواسطة الـ router، ويمكن حمل أي من البروتوكولين بواسطة أي من وسائل النقل.
دليل التطبيق
التطبيقات المكتوبة بـ Java قد تستخدم واجهة برمجة التطبيقات datagram API، بينما التطبيقات بلغات أخرى يمكنها استخدام دعم datagram في SAM . هناك أيضاً دعم محدود في i2ptunnel في SOCKS proxy ، وأنواع الأنفاق ‘streamr’، وفئات udpTunnel.
طول الـ Datagram
يجب على مصمم التطبيق النظر بعناية في المفاضلة بين الرسائل القابلة للرد وغير القابلة للرد. كما أن حجم الرسالة سيؤثر على الموثوقية، بسبب تجزئة tunnel إلى رسائل tunnel بحجم 1KB. كلما زاد عدد أجزاء الرسالة، زاد احتمال إسقاط أحدها بواسطة عقدة وسطية. لا يُنصح بالرسائل الأكبر من بضعة كيلوبايت. فوق حوالي 10 KB، تنخفض احتمالية التسليم بشكل كبير.
راجع صفحة مواصفات الـ Datagrams.
لاحظ أيضاً أن الأعباء الإضافية المختلفة التي تضيفها الطبقات السفلى، وخاصة garlic messages، تضع عبئاً كبيراً على الرسائل المتقطعة مثل تلك المستخدمة في تطبيق Kademlia-over-UDP. التطبيقات الحالية مُحسنة للحركة المرورية المتكررة التي تستخدم مكتبة البث المباشر.
رقم بروتوكول I2CP والمنافذ
رقم البروتوكول I2CP القياسي للرسائل المُوقعة (القابلة للرد عليها) هو PROTO_DATAGRAM (17). قد تختار التطبيقات تعيين البروتوكول في رأس I2CP أو قد لا تفعل ذلك. الافتراضي يعتمد على التنفيذ. يجب تعيينه لفصل حركة البيانات والتدفق المستلمة على نفس الوجهة.
نظراً لأن datagrams ليست موجهة بالاتصال، قد يتطلب التطبيق أرقام منافذ لربط datagrams مع أقران محددين أو جلسات اتصال معينة، كما هو تقليدي مع UDP عبر IP. يمكن للتطبيقات إضافة منافذ ‘من’ و’إلى’ إلى رأس I2CP (gzip) كما هو موضح في صفحة I2CP .
لا توجد طريقة داخل واجهة برمجة تطبيقات datagram لتحديد ما إذا كانت غير قابلة للرد (خام) أم قابلة للرد. يجب تصميم التطبيق لتوقع النوع المناسب. يجب على التطبيق استخدام رقم بروتوكول I2CP أو المنفذ للإشارة إلى نوع datagram. أرقام بروتوكولات I2CP المُعرَّفة PROTO_DATAGRAM (موقع، المعروف أيضاً باسم Datagram1)، PROTO_DATAGRAM_RAW، PROTO_DATAGRAM2، و PROTO_DATAGRAM3 محددة في واجهة برمجة تطبيقات I2PSession لهذا الغرض. نمط تصميم شائع في تطبيقات datagram العميل/الخادم هو استخدام datagrams موقعة للطلب الذي يتضمن nonce، واستخدام datagram خام للرد، مع إرجاع nonce من الطلب.
الافتراضيات:
- PROTO_DATAGRAM = 17
- PROTO_DATAGRAM_RAW = 18
- PROTO_DATAGRAM2 = 19
- PROTO_DATAGRAM3 = 20
سلامة البيانات
تسلامة البيانات مضمونة من خلال المجموع الاختباري gzip CRC-32 المطبق في طبقة I2CP . كما تضمن الرسائل النصية المصادق عليها (Datagram1 و Datagram2) التكامل. لا يوجد حقل مجموع اختباري في بروتوكول الرسائل النصية.
تغليف الحزم
يتم إرسال كل datagram عبر I2P كرسالة واحدة (أو كفص فردي في رسالة Garlic ). يتم تنفيذ تغليف الرسائل في طبقات I2CP و I2NP و رسالة tunnel الأساسية. لا توجد آلية فاصل حزم أو حقل طول في بروتوكول datagram.