بروتوكول عميل I2P (I2CP)

نظرة عامة

هذه هي مواصفات بروتوكول I2P Control Protocol (I2CP)، وهو الواجهة منخفضة المستوى بين العملاء والـ router. عملاء Java سيستخدمون واجهة برمجة تطبيقات عميل I2CP، والتي تنفذ هذا البروتوكول.

لا توجد تطبيقات معروفة غير مكتوبة بـ Java لمكتبة من جانب العميل تنفذ I2CP. بالإضافة إلى ذلك، التطبيقات الموجهة للمقابس (streaming) ستحتاج إلى تنفيذ بروتوكول streaming، لكن لا توجد مكتبات غير مكتوبة بـ Java لذلك أيضاً. لذلك، يجب على العملاء غير المكتوبين بـ Java استخدام البروتوكول عالي المستوى SAM SAMv3 بدلاً من ذلك، والذي تتوفر له مكتبات بعدة لغات.

هذا بروتوكول منخفض المستوى مدعوم داخليًا وخارجيًا من قبل Java I2P router. يتم تسلسل البروتوكول فقط إذا لم يكن العميل وال router في نفس JVM؛ وإلا فإن رسائل I2CP Java objects يتم تمريرها عبر واجهة JVM داخلية. I2CP مدعوم أيضًا خارجيًا من قبل C++ router i2pd.

معلومات أكثر متاحة في صفحة نظرة عامة على I2CP I2CP .

الجلسات

تم تصميم البروتوكول للتعامل مع عدة “جلسات”، كل منها بمعرف جلسة من 2 بايت، عبر اتصال TCP واحد، ومع ذلك، لم يتم تنفيذ الجلسات المتعددة حتى الإصدار 0.9.21. راجع قسم الجلسات المتعددة أدناه . لا تحاول استخدام جلسات متعددة على اتصال I2CP واحد مع routers أقدم من الإصدار 0.9.21.

يبدو أيضًا أن هناك بعض الأحكام لعميل واحد للتحدث مع عدة routers عبر اتصالات منفصلة. هذا أيضًا غير مختبر، وربما غير مفيد.

لا توجد طريقة للحفاظ على الجلسة بعد قطع الاتصال، أو لاستعادتها على اتصال I2CP مختلف. عند إغلاق المقبس، يتم تدمير الجلسة.

أمثلة على تسلسل الرسائل

ملاحظة: الأمثلة أدناه لا تُظهر بايت البروتوكول (0x2a) الذي يجب إرساله من العميل إلى الـ router عند الاتصال لأول مرة. يمكن العثور على مزيد من المعلومات حول تهيئة الاتصال في صفحة نظرة عامة على I2CP I2CP .

إنشاء جلسة قياسية

  Client                                           Router

                           --------------------->  Get Date Message
        Set Date Message  <---------------------
                           --------------------->  Create Session Message
  Session Status Message  <---------------------
Request LeaseSet Message  <---------------------
                           --------------------->  Create LeaseSet Message

الحصول على حدود عرض النطاق (جلسة بسيطة)

  Client                                           Router

                           --------------------->  Get Bandwidth Limits Message
Bandwidth Limits Message  <---------------------

البحث عن الوجهة (جلسة بسيطة)

  Client                                           Router

                           --------------------->  Dest Lookup Message
      Dest Reply Message  <---------------------

الرسالة الصادرة

جلسة موجودة، مع i2cp.messageReliability=none

  Client                                           Router

                           --------------------->  Send Message Message

جلسة موجودة، مع i2cp.messageReliability=none و nonce غير صفري

  Client                                           Router

                           --------------------->  Send Message Message
  Message Status Message  <---------------------
  (succeeded)

جلسة موجودة، مع i2cp.messageReliability=BestEffort

  Client                                           Router

                           --------------------->  Send Message Message
  Message Status Message  <---------------------
  (accepted)
  Message Status Message  <---------------------
  (succeeded)

الرسالة الواردة

جلسة موجودة، مع i2cp.fastReceive=true (اعتباراً من الإصدار 0.9.4)

  Client                                           Router

 Message Payload Message  <---------------------

جلسة موجودة، مع i2cp.fastReceive=false (مهجور)

  Client                                           Router

  Message Status Message  <---------------------
  (available)
                           --------------------->  Receive Message Begin Message
 Message Payload Message  <---------------------
                           --------------------->  Receive Message End Message

ملاحظات الجلسات المتعددة

الجلسات المتعددة على اتصال I2CP واحد مدعومة اعتباراً من إصدار router 0.9.21. الجلسة الأولى التي يتم إنشاؤها هي “الجلسة الأساسية”. الجلسات الإضافية هي “جلسات فرعية”. تُستخدم الجلسات الفرعية لدعم وجهات متعددة تتشارك مجموعة مشتركة من tunnels. التطبيق الأولي هو أن تستخدم الجلسة الأساسية مفاتيح توقيع ECDSA، بينما تستخدم الجلسة الفرعية مفاتيح توقيع DSA للتواصل مع eepsites القديمة.

تتشارك الجلسات الفرعية نفس مجمعات الأنفاق الواردة والصادرة مع الجلسة الأساسية. يجب أن تستخدم الجلسات الفرعية نفس مفاتيح التشفير الخاصة بالجلسة الأساسية. وهذا ينطبق على كل من مفاتيح تشفير leaseSet ومفاتيح تشفير الوجهة (غير المستخدمة). يجب أن تستخدم الجلسات الفرعية مفاتيح توقيع مختلفة في الوجهة، لذا فإن hash الوجهة يختلف عن الجلسة الأساسية. وحيث أن الجلسات الفرعية تستخدم نفس مفاتيح التشفير والأنفاق الخاصة بالجلسة الأساسية، فمن الواضح للجميع أن الوجهات تعمل على نفس router، وبالتالي فإن ضمانات إخفاء الهوية المضادة للارتباط المعتادة لا تنطبق.

يتم إنشاء الجلسات الفرعية عن طريق إرسال رسالة CreateSession وتلقي رسالة SessionStatus كرد، كالمعتاد. يجب إنشاء الجلسات الفرعية بعد إنشاء الجلسة الأساسية. ستحتوي استجابة SessionStatus، عند النجاح، على معرف جلسة فريد، مختلف عن المعرف الخاص بالجلسة الأساسية. بينما يجب معالجة رسائل CreateSession بالترتيب، لا توجد طريقة مؤكدة لربط رسالة CreateSession بالاستجابة، لذلك يجب ألا يكون لدى العميل عدة رسائل CreateSession معلقة في نفس الوقت. قد لا يتم احترام خيارات SessionConfig للجلسة الفرعية عندما تختلف عن الجلسة الأساسية. على وجه الخصوص، نظراً لأن الجلسات الفرعية تستخدم نفس مجموعة tunnel كالجلسة الأساسية، فقد يتم تجاهل خيارات tunnel.

سيقوم الـ router بإرسال رسائل RequestVariableLeaseSet منفصلة لكل Destination إلى العميل، ويجب على العميل الرد برسالة CreateLeaseSet لكل منها. لن تكون الـ leases للـ Destinations الاثنين متطابقة بالضرورة، حتى لو تم اختيارها من نفس مجموعة الـ tunnel.

يمكن تدمير الجلسة الفرعية باستخدام رسالة DestroySession كالمعتاد. هذا لن يدمر الجلسة الأساسية أو يوقف اتصال I2CP. تدمير الجلسة الأساسية سيؤدي، مع ذلك، إلى تدمير جميع الجلسات الفرعية وإيقاف اتصال I2CP. رسالة Disconnect تدمر جميع الجلسات.

لاحظ أن معظم رسائل I2CP، وليس جميعها، تحتوي على معرف جلسة. بالنسبة للرسائل التي لا تحتوي على معرف جلسة، قد يحتاج العملاء إلى منطق إضافي للتعامل بشكل صحيح مع ردود router. DestLookup و DestReply لا تحتويان على معرفات الجلسة؛ استخدم بدلاً من ذلك HostLookup و HostReply الأحدث. GetBandwidthLimts و BandwidthLimits لا تحتويان على معرفات جلسة، ومع ذلك فإن الاستجابة ليست خاصة بجلسة معينة.

ملاحظات الإصدار

لا يُتوقع أن يتغير بايت إصدار البروتوكول الأولي (0x2a) المُرسل من العميل. قبل الإصدار 0.8.7، لم تكن معلومات إصدار الـ router متاحة للعميل، مما منع العملاء الجدد من العمل مع الـ routers القديمة. اعتباراً من الإصدار 0.8.7، يتم تبادل سلاسل إصدار البروتوكول للطرفين في رسائل Get/Set Date. مستقبلاً، يمكن للعملاء استخدام هذه المعلومات للتواصل بشكل صحيح مع الـ routers القديمة. يجب على العملاء والـ routers عدم إرسال رسائل غير مدعومة من الطرف الآخر، حيث أنها عادة ما تقطع الجلسة عند استلام رسالة غير مدعومة.

معلومات الإصدار المتبادلة هي إصدار واجهة برمجة التطبيقات “الأساسية” أو إصدار بروتوكول I2CP، وليست بالضرورة إصدار router.

ملخص أساسي لإصدارات بروتوكول I2CP كما يلي. للتفاصيل، انظر أدناه.

رأس رسالة I2CP

الوصف

رأس مشترك لجميع رسائل I2CP، يحتوي على طول الرسالة ونوع الرسالة.

المحتويات

1. 4 بايت Integer تحدد طول جسم الرسالة
2. 1 بايت Integer تحدد نوع الرسالة.
3. جسم رسالة I2CP، 0 أو أكثر من البايتات

ملاحظات

الحد الأقصى الفعلي لطول الرسالة هو حوالي 64 كيلوبايت.

معرف الرسالة

الوصف

يحدد بشكل فريد رسالة في انتظار على router معين في نقطة زمنية محددة. يتم إنشاء هذا دائماً بواسطة الـ router وليس نفس الـ nonce الذي ينشئه العميل.

المحتويات

1. 4 بايت Integer

ملاحظات

معرفات الرسائل فريدة داخل الجلسة فقط؛ وهي ليست فريدة على مستوى النظام بالكامل.

الحمولة

الوصف

هذا الهيكل هو محتوى رسالة يتم تسليمها من وجهة إلى أخرى.

المحتويات

1. 4 بايت طول Integer
2. عدد البايتات المقابل

ملاحظات

الحمولة في تنسيق gzip كما هو محدد في صفحة نظرة عامة على I2CP I2CP-FORMAT .

الحد الفعلي لطول الرسالة هو حوالي 64 كيلوبايت.

إعدادات الجلسة

الوصف

يحدد خيارات التكوين لجلسة عميل معينة.

المحتويات

1. Destination
2. Mapping للخيارات
3. Date الإنشاء
4. Signature للحقول الثلاثة السابقة، موقعة بواسطة SigningPrivateKey

ملاحظات

• يتم تحديد الخيارات في صفحة نظرة عامة على I2CP I2CP-OPTIONS .
• يجب ترتيب Mapping حسب المفتاح حتى يتم التحقق من صحة التوقيع بشكل صحيح في router.
• يجب أن يكون تاريخ الإنشاء ضمن +/- 30 ثانية من الوقت الحالي عند معالجته بواسطة router، وإلا سيتم رفض الإعداد.

التوقيعات غير المتصلة

• إذا كان Destination موقعاً بشكل غير متصل، فيجب أن يحتوي Mapping على الخيارات الثلاثة i2cp.leaseSetOfflineExpiration و i2cp.leaseSetTransientPublicKey و i2cp.leaseSetOfflineSignature. يتم بعد ذلك إنشاء Signature بواسطة SigningPrivateKey المؤقت ويتم التحقق منه باستخدام SigningPublicKey المحدد في i2cp.leaseSetTransientPublicKey. راجع I2CP-OPTIONS للتفاصيل.

معرف الجلسة

الوصف

يحدد بشكل فريد جلسة على router معين في نقطة زمنية محددة.

المحتويات

1. 2 بايت Integer

ملاحظات

يتم استخدام معرف الجلسة 0xffff للإشارة إلى “عدم وجود جلسة”، على سبيل المثال لعمليات البحث عن أسماء المضيفين.

الرسائل

انظر أيضاً I2CP Javadocs .

أنواع الرسائل

الوصف

أخبر العميل عن حدود عرض النطاق الترددي.

يُرسل من router إلى العميل كاستجابة لـ GetBandwidthLimitsMessage .

المحتويات

1. 4 بايت Integer حد العميل الوارد (KBps)
2. 4 بايت Integer حد العميل الصادر (KBps)
3. 4 بايت Integer حد router الوارد (KBps)
4. 4 بايت Integer حد انفجار router الوارد (KBps)
5. 4 بايت Integer حد router الصادر (KBps)
6. 4 بايت Integer حد انفجار router الصادر (KBps)
7. 4 بايت Integer وقت انفجار router (ثواني)
8. تسعة 4-بايت Integer (غير محدد)

ملاحظات

قد تكون حدود العميل القيم الوحيدة المحددة، وقد تكون الحدود الفعلية للـ router، أو نسبة مئوية من حدود الـ router، أو خاصة بعميل معين، حسب التنفيذ. جميع القيم المصنفة كحدود router قد تكون 0، حسب التنفيذ. اعتباراً من الإصدار 0.7.2.

BlindingInfoMessage

الوصف

أخبر الـ router أن الوجهة مخفية، مع كلمة مرور البحث الاختيارية والمفتاح الخاص الاختياري لفك التشفير. راجع المقترحات 123 و 149 للتفاصيل.

يحتاج الـ router إلى معرفة ما إذا كان الوجهة مخفية. إذا كانت مخفية وتستخدم مصادقة سرية أو لكل عميل، فإنه يحتاج إلى الحصول على تلك المعلومات أيضاً.

البحث عن المضيف لعنوان b32 بصيغة جديدة (“b33”) يخبر الموجه أن العنوان مخفي، ولكن لا توجد آلية لتمرير المفتاح السري أو المفتاح الخاص إلى الموجه في رسالة البحث عن المضيف. بينما يمكننا توسيع رسالة البحث عن المضيف لإضافة تلك المعلومات، فإن تعريف رسالة جديدة أكثر وضوحاً.

تُوفر هذه الرسالة طريقة برمجية للعميل لإخبار الـ router. وإلا، فسيتوجب على المستخدم تكوين كل وجهة يدوياً.

الاستخدام

قبل أن يرسل العميل رسالة إلى وجهة مخفية، يجب عليه إما البحث عن “b33” في رسالة Host Lookup، أو إرسال رسالة Blinding Info. إذا كانت الوجهة المخفية تتطلب سراً أو مصادقة لكل عميل، فيجب على العميل إرسال رسالة Blinding Info.

لا يرسل الـ router ردًا على هذه الرسالة. يتم الإرسال من العميل إلى الـ router.

المحتويات

1. معرف الجلسة
2. 1 بايت عدد صحيح أعلام

• ترتيب البتات: 76543210 > - البت 0: 0 للجميع، 1 لكل عميل > - البتات 3-1: مخطط المصادقة، إذا تم تعيين البت 0 إلى 1 لكل > عميل، وإلا 000 > - 000: مصادقة العميل DH (أو عدم وجود مصادقة لكل عميل) > - 001: مصادقة العميل PSK > - البت 4: 1 إذا كان السر مطلوباً، 0 إذا لم يكن السر مطلوباً > - البتات 7-5: غير مستخدمة، تعيين إلى 0 للتوافق المستقبلي

3. 1 بايت Integer نوع نقطة النهاية

• النوع 0 هو Hash > - النوع 1 هو اسم المضيف String > - النوع 2 هو Destination > - النوع 3 هو نوع التوقيع و > SigningPublicKey

4. 2 بايت Integer نوع التوقيع المعمى
5. 4 بايت Integer ثواني انتهاء الصلاحية منذ العصر
6. نقطة النهاية: البيانات كما هو محدد، واحدة من

• النوع 0: 32 بايت Hash > > - النوع 1: اسم المضيف String > > - النوع 2: ثنائي Destination > > > > - النوع 3: 2 بايت Integer نوع التوقيع، متبوعاً بـ > > - SigningPublicKey (الطول كما > يقترحه نوع التوقيع)

7. PrivateKey مفتاح فك التشفير موجود فقط إذا تم تعيين بت العلم 0 إلى 1. مفتاح خاص ECIES_X25519 بحجم 32 بايت، little-endian
8. String كلمة مرور البحث موجودة فقط إذا تم تعيين بت العلم 4 إلى 1.

ملاحظات

• اعتباراً من الإصدار 0.9.43.
• نوع نقطة النهاية Hash غالباً لا يكون مفيداً ما لم يتمكن الـ router من إجراء بحث عكسي في دفتر العناوين للحصول على الـ Destination.
• نوع نقطة النهاية hostname غالباً لا يكون مفيداً ما لم يتمكن الـ router من إجراء بحث في دفتر العناوين للحصول على الـ Destination.

CreateLeaseSetMessage

مُهمل. لا يمكن استخدامه مع LeaseSet2، أو المفاتيح غير المتصلة، أو أنواع التشفير غير ElGamal، أو أنواع التشفير المتعددة، أو LeaseSets المشفرة. استخدم CreateLeaseSet2Message مع جميع routers الإصدار 0.9.39 أو أعلى.

الوصف

يتم إرسال هذه الرسالة استجابة لـ RequestLeaseSetMessage أو RequestVariableLeaseSetMessage وتحتوي على جميع هياكل Lease التي يجب نشرها إلى قاعدة بيانات شبكة I2NP.

مُرسل من العميل إلى الموجه.

المحتويات

1. Session ID
2. DSA SigningPrivateKey أو 20 بايت يتم تجاهلها
3. PrivateKey
4. LeaseSet

ملاحظات

يتطابق SigningPrivateKey مع SigningPublicKey من داخل LeaseSet، فقط إذا كان نوع مفتاح التوقيع هو DSA. هذا مخصص لإبطال LeaseSet، والذي لم يتم تنفيذه ومن غير المحتمل أن يتم تنفيذه أبداً. إذا لم يكن نوع مفتاح التوقيع DSA، فإن هذا الحقل يحتوي على 20 بايت من البيانات العشوائية. طول هذا الحقل هو دائماً 20 بايت، ولا يساوي أبداً طول مفتاح التوقيع الخاص غير DSA.

يطابق PrivateKey الـ PublicKey من LeaseSet. PrivateKey ضروري لفك تشفير الرسائل المرسلة عبر garlic routing.

الإلغاء غير مُنفّذ. الاتصال بعدة routers غير مُنفّذ في أي مكتبة عميل.

CreateLeaseSet2Message

الوصف

يتم إرسال هذه الرسالة كاستجابة لـ RequestLeaseSetMessage أو RequestVariableLeaseSetMessage وتحتوي على جميع هياكل Lease التي يجب نشرها في قاعدة بيانات شبكة I2NP.

مُرسل من العميل إلى الـ router. منذ الإصدار 0.9.39. المصادقة لكل عميل لـ EncryptedLeaseSet مدعومة اعتباراً من الإصدار 0.9.41. MetaLeaseSet غير مدعوم بعد عبر I2CP. انظر الاقتراح 123 لمزيد من المعلومات.

المحتويات

1. معرف الجلسة
2. بايت واحد لنوع leaseSet المتبع.

• النوع 1 هو LeaseSet (مهجور) > - النوع 3 هو LeaseSet2 > - النوع 5 هو EncryptedLeaseSet > - النوع 7 هو MetaLeaseSet

3. LeaseSet أو LeaseSet2 أو EncryptedLeaseSet أو MetaLeaseSet
4. بايت واحد يحدد عدد المفاتيح الخاصة التي ستتبع.
5. قائمة PrivateKey . واحد لكل مفتاح عام في lease set، بنفس الترتيب. (غير موجود لـ Meta LS2)

• نوع التشفير (2 بايت Integer ) > - طول مفتاح التشفير (2 بايت Integer ) > - PrivateKey التشفير (عدد البايتات > المحددة)

ملاحظات

تتطابق PrivateKeys مع كل من PublicKey من LeaseSet. إن PrivateKeys ضرورية لفك تشفير الرسائل المُوجهة عبر garlic encryption.

راجع المقترح 123 للمزيد من المعلومات حول leaseSet المشفرة.

محتويات وتنسيق MetaLeaseSet أولية وقابلة للتغيير. لا يوجد بروتوكول محدد لإدارة عدة routers. راجع الاقتراح 123 للمزيد من المعلومات.

مفتاح التوقيع الخاص، الذي كان محدداً مسبقاً للإلغاء وغير مستخدم، غير موجود في LS2.

الإصدار الأولي مع نوع الرسالة 40 كان في 0.9.38 ولكن تم تغيير التنسيق. النوع 40 مهجور وغير مدعوم. النوع 41 غير صالح حتى 0.9.39.

CreateSessionMessage

الوصف

يتم إرسال هذه الرسالة من عميل لبدء جلسة، حيث يتم تعريف الجلسة كاتصال Destination واحد بالشبكة، والتي سيتم تسليم جميع الرسائل لذلك Destination إليها ومن خلالها سيتم إرسال جميع الرسائل التي يرسلها ذلك Destination إلى أي Destination آخر.

يتم إرساله من العميل إلى الـ router. يستجيب الـ router برسالة SessionStatusMessage .

المحتويات

1. إعدادات الجلسة

ملاحظات

• هذه هي الرسالة الثانية المرسلة من العميل. سابقاً أرسل العميل GetDateMessage وتلقى استجابة SetDateMessage .
• إذا كان التاريخ في إعداد الجلسة بعيداً جداً (أكثر من +/- 30 ثانية) عن الوقت الحالي للـ router، سيتم رفض الجلسة.
• إذا كانت هناك جلسة موجودة بالفعل على الـ router لهذا الـ Destination، فسيتم رفض الجلسة.
• يجب ترتيب Mapping في إعداد الجلسة حسب المفتاح حتى يتم التحقق من صحة التوقيع بشكل صحيح في الـ router.

رسالة البحث عن الوجهة

الوصف

يُرسل من العميل إلى الـ router. يرد الـ router برسالة DestReplyMessage .

المحتويات

1. SHA-256 Hash

ملاحظات

اعتبارًا من الإصدار 0.7.

اعتبارًا من الإصدار 0.8.3، يتم دعم عمليات البحث المتعددة المعلقة، كما يتم دعم عمليات البحث في كل من I2PSimpleSession والجلسات العادية.

HostLookupMessage مُفضل اعتباراً من الإصدار 0.9.11.

DestReplyMessage

الوصف

يُرسل من Router إلى العميل كاستجابة لـ DestLookupMessage .

المحتويات

1. Destination عند النجاح، أو Hash عند الفشل

ملاحظات

اعتباراً من الإصدار 0.7.

اعتباراً من الإصدار 0.8.3، يتم إرجاع Hash المطلوب في حالة فشل البحث، بحيث يمكن للعميل أن يكون لديه عدة عمليات بحث معلقة وربط الردود بعمليات البحث. لربط استجابة Destination بطلب، خذ Hash الخاص بـ Destination. قبل الإصدار 0.8.3، كانت الاستجابة فارغة عند الفشل.

DestroySessionMessage

الوصف

يتم إرسال هذه الرسالة من العميل لتدمير جلسة.

يُرسل من العميل إلى الموجه (Router). يجب على الموجه أن يستجيب برسالة SessionStatusMessage (محذوفة). ومع ذلك، راجع الملاحظات المهمة أدناه.

المحتويات

1. معرف الجلسة

ملاحظات

يجب على الـ router في هذه النقطة تحرير جميع الموارد المرتبطة بالجلسة.

من خلال API 0.9.66، فإن router Java I2P ومكتبات العميل تنحرف بشكل كبير عن هذه المواصفات. لا يرسل router أبداً استجابة SessionStatus(Destroyed). إذا لم تعد هناك جلسات متبقية، فإنه يرسل DisconnectMessage . إذا كانت هناك جلسات فرعية أو الجلسة الأساسية متبقية، فإنه لا يرد.

تستجيب مكتبة عميل Java لرسالة SessionStatus عن طريق تدمير جميع الجلسات وإعادة الاتصال.

قد لا يكون تدمير الجلسات الفرعية الفردية على اتصال يحتوي على جلسات متعددة مختبرًا بالكامل أو يعمل بشكل صحيح على تطبيقات router والعميل المختلفة. استخدم الحذر.

يجب على التطبيقات التعامل مع إشارة destroy للجلسة الأساسية كإشارة destroy لجميع الجلسات الفرعية، ولكن السماح بإشارة destroy لجلسة فرعية واحدة والحفاظ على الاتصال مفتوحاً، ولكن Java I2P لا تقوم بذلك حالياً. إذا تم تغيير سلوك Java I2P في الإصدارات اللاحقة، فسيتم توثيق ذلك هنا.

رسالة قطع الاتصال

الوصف

أخبر الطرف الآخر أن هناك مشاكل وأن الاتصال الحالي على وشك أن يتم إنهاؤه. هذا ينهي جميع الجلسات على ذلك الاتصال. سيتم إغلاق المقبس قريباً. يُرسل إما من router إلى العميل أو من العميل إلى router.

المحتويات

1. السبب String

ملاحظات

مُنفَّذ فقط في اتجاه router إلى العميل، على الأقل في Java I2P.

GetBandwidthLimitsMessage

الوصف

اطلب من الـ router أن يوضح ما هي حدود النطاق الترددي الحالية له.

يتم إرسالها من العميل إلى الـ router. يستجيب الـ router برسالة BandwidthLimitsMessage .

المحتويات

لا يوجد

ملاحظات

اعتباراً من الإصدار 0.7.2.

اعتباراً من الإصدار 0.8.3، مدعوم في كل من I2PSimpleSession وفي الجلسات القياسية.

GetDateMessage

الوصف

يُرسل من العميل إلى الموجه. يستجيب الموجه برسالة SetDateMessage .

المحتويات

1. إصدار I2CP API String
2. المصادقة Mapping (اختياري، اعتباراً من الإصدار 0.9.11)

ملاحظات

• بشكل عام هي أول رسالة يرسلها العميل بعد إرسال بايت إصدار البروتوكول.
• يتم تضمين سلسلة الإصدار اعتباراً من الإصدار 0.8.7. هذا مفيد فقط إذا لم يكن العميل و router في نفس JVM. إذا لم تكن موجودة، فإن العميل هو إصدار 0.8.6 أو أقدم.
• اعتباراً من الإصدار 0.9.11، قد يتم تضمين المصادقة Mapping ، مع المفاتيح i2cp.username و i2cp.password. لا يحتاج Mapping إلى أن يكون مرتباً حيث أن هذه الرسالة غير موقعة. قبل وبما في ذلك 0.9.10، يتم تضمين المصادقة في Session Config Mapping، ولا يتم فرض مصادقة لـ GetDateMessage ، GetBandwidthLimitsMessage ، أو DestLookupMessage . عند التمكين، تكون المصادقة عبر GetDateMessage مطلوبة قبل أي رسائل أخرى اعتباراً من الإصدار 0.9.16. هذا مفيد فقط خارج سياق router. هذا تغيير غير متوافق، لكنه سيؤثر فقط على الجلسات خارج سياق router مع المصادقة، والتي يجب أن تكون نادرة.

رسالة البحث عن المضيف

الوصف

يُرسل من العميل إلى الموجه. يستجيب الموجه برسالة HostReplyMessage .

هذا يحل محل DestLookupMessage ويضيف معرف طلب ومهلة زمنية ودعم البحث عن أسماء المضيفين. وبما أنه يدعم أيضاً عمليات البحث بالـ Hash، فيمكن استخدامه لجميع عمليات البحث إذا كان الـ router يدعمه. بالنسبة لعمليات البحث عن أسماء المضيفين، سيستعلم الـ router خدمة التسمية في سياقه. هذا مفيد فقط إذا كان العميل خارج سياق الـ router. داخل سياق الـ router، يجب على العميل الاستعلام من خدمة التسمية بنفسه، وهو أكثر كفاءة بكثير.

المحتويات

1. Session ID
2. 4 بايت Integer معرف الطلب
3. 4 بايت Integer المهلة الزمنية (ملي ثانية)
4. 1 بايت Integer نوع الطلب
5. SHA-256 Hash أو اسم المضيف String أو Destination

أنواع الطلبات:

ملاحظات

• اعتباراً من الإصدار 0.9.11. استخدم DestLookupMessage للـ routers الأقدم.
• سيتم إرجاع معرف الجلسة ومعرف الطلب في HostReplyMessage . استخدم 0xFFFF لمعرف الجلسة إذا لم تكن هناك جلسة.
• المهلة الزمنية مفيدة لعمليات البحث عن Hash. الحد الأدنى الموصى به 10,000 (10 ثوانٍ). في المستقبل قد تكون مفيدة أيضاً لعمليات البحث في خدمة الأسماء البعيدة. قد لا يتم احترام هذه القيمة لعمليات البحث عن أسماء المضيفين المحلية، والتي يجب أن تكون سريعة.
• البحث عن أسماء المضيفين بصيغة Base 32 مدعوم لكن من الأفضل تحويلها إلى Hash أولاً.

HostReplyMessage

الوصف

يُرسل من الـ Router إلى العميل كرد على HostLookupMessage .

المحتويات

1. Session ID
2. 4 بايت Integer معرف الطلب
3. 1 بايت Integer رمز النتيجة

• 0: نجح > - 1: فشل > - 2: كلمة مرور البحث مطلوبة (اعتباراً من 0.9.43) > - 3: المفتاح الخاص مطلوب (اعتباراً من 0.9.43) > - 4: كلمة مرور البحث والمفتاح الخاص مطلوبان (اعتباراً من 0.9.43) > - 5: فشل فك تشفير leaseSet (اعتباراً من 0.9.43) > - 6: فشل البحث عن leaseSet (اعتباراً من 0.9.66) > - 7: نوع البحث غير مدعوم (اعتباراً من 0.9.66)

4. Destination ، موجود فقط إذا كان رمز النتيجة صفراً، باستثناء أنه قد يُرجع أيضاً لأنواع البحث 2-4. انظر أدناه.
5. Mapping ، موجود فقط إذا كان رمز النتيجة صفراً، يُرجع فقط لأنواع البحث 2-4. اعتباراً من 0.9.66. انظر أدناه.

الاستجابات لأنواع البحث 2-4

يُعرّف الاقتراح 167 أنواعاً إضافية من البحث التي ترجع جميع الخيارات من الـ leaseset، إذا كانت موجودة. لأنواع البحث 2-4، يجب على الـ router جلب الـ leaseset، حتى لو كان مفتاح البحث موجوداً في دفتر العناوين.

في حالة النجاح، ستحتوي HostReply على خيارات Mapping من leaseset، وتتضمنها كعنصر رقم 5 بعد الوجهة. إذا لم تكن هناك خيارات في Mapping، أو كان leaseset إصدار 1، فسيتم تضمينها مع ذلك كـ Mapping فارغ (بايتان: 0 0). سيتم تضمين جميع الخيارات من leaseset، وليس فقط خيارات سجل الخدمة. على سبيل المثال، قد تكون خيارات للمعاملات المحددة في المستقبل موجودة. قد يكون Mapping المُرجع مرتبًا أو غير مرتب، حسب التنفيذ.

في حالة فشل البحث عن leaseSet، سيحتوي الرد على رمز خطأ جديد 6 (فشل البحث عن leaseSet) ولن يتضمن تطابقاً. عندما يتم إرجاع رمز الخطأ 6، قد يكون حقل الوجهة موجوداً أو غير موجود. سيكون موجوداً إذا نجح البحث عن اسم المضيف في دفتر العناوين، أو إذا نجح بحث سابق وتم تخزين النتيجة مؤقتاً، أو إذا كانت الوجهة موجودة في رسالة البحث (نوع البحث 4).

إذا لم يكن نوع البحث مدعوماً، فإن الرد سيحتوي على رمز خطأ جديد 7 (نوع البحث غير مدعوم).

ملاحظات

• اعتباراً من الإصدار 0.9.11. انظر ملاحظات HostLookupMessage .
• معرف الجلسة ومعرف الطلب هما نفسهما من HostLookupMessage .
• رمز النتيجة هو 0 للنجاح، 1-255 للفشل. 1 يشير إلى فشل عام. اعتباراً من 0.9.43، تم تعريف رموز الفشل الإضافية 2-5 لدعم الأخطاء الموسعة لعمليات البحث “b33”. انظر المقترحات 123 و 149 للحصول على معلومات إضافية. اعتباراً من 0.9.66، تم تعريف رموز الفشل الإضافية 6-7 لدعم الأخطاء الموسعة لعمليات البحث من النوع 2-4. انظر المقترح 167 للحصول على معلومات إضافية.

MessagePayloadMessage

الوصف

تسليم محتوى الرسالة إلى العميل.

يُرسل من الـ Router إلى العميل. إذا كان i2cp.fastReceive=true، وهو ليس الإعداد الافتراضي، يستجيب العميل برسالة ReceiveMessageEndMessage .

المحتويات

1. معرف الجلسة
2. معرف الرسالة
3. الحمولة

ملاحظات

MessageStatusMessage

الوصف

إشعار العميل بحالة التسليم لرسالة واردة أو صادرة. يُرسل من router إلى العميل. إذا كانت هذه الرسالة تشير إلى وجود رسالة واردة متاحة، يستجيب العميل برسالة ReceiveMessageBeginMessage . بالنسبة للرسالة الصادرة، هذا رد على رسالة SendMessageMessage أو SendMessageExpiresMessage .

المحتويات

1. Session ID
2. Message ID يتم إنشاؤه بواسطة router
3. 1 بايت Integer الحالة
4. 4 بايت Integer الحجم
5. 4 بايت Integer nonce تم إنشاؤه مسبقاً بواسطة العميل

ملاحظات

حتى الإصدار 0.9.4، قيم الحالة المعروفة هي 0 للرسالة متاحة، 1 للمقبولة، 2 لنجح بأفضل جهد، 3 لفشل بأفضل جهد، 4 لنجح مضمون، 5 لفشل مضمون. الرقم الصحيح للحجم يحدد حجم الرسالة المتاحة وهو ذو صلة فقط عندما الحالة = 0. على الرغم من أن المضمون غير مُطبق، (أفضل جهد هو الخدمة الوحيدة)، فإن تنفيذ router الحالي يستخدم رموز حالة المضمون، وليس رموز أفضل جهد.

اعتباراً من إصدار router 0.9.5، تم تعريف رموز حالة إضافية، ولكنها ليست بالضرورة مُطبقة. انظر MessageStatusMessage Javadocs للتفاصيل. بالنسبة للرسائل الصادرة، تشير الرموز 1، 2، 4، و 6 إلى النجاح؛ جميع الرموز الأخرى تشير إلى فشل. قد تختلف رموز الفشل المُرجعة وهي خاصة بالتطبيق.

جميع رموز الحالة:

ReceiveMessageBeginMessage

مُهمَل. غير مدعوم من قبل i2pd.

الوصف

اطلب من الـ router تسليم رسالة تم إشعاره بها مسبقاً. يُرسل من العميل إلى الـ Router. يستجيب الـ router برسالة MessagePayloadMessage .

المحتويات

1. معرف الجلسة
2. معرف الرسالة

ملاحظات

يتم إرسال ReceiveMessageBeginMessage كاستجابة لـ MessageStatusMessage التي تفيد بأن رسالة جديدة متاحة للاستلام. إذا كان معرف الرسالة المحدد في ReceiveMessageBeginMessage غير صالح أو غير صحيح، فقد لا يرد الـ router ببساطة، أو قد يرسل DisconnectMessage .

هذا غير مستخدم في وضع “الاستقبال السريع”، والذي يُعد الافتراضي اعتباراً من الإصدار 0.9.4.

ReceiveMessageEndMessage

مُهمل. غير مدعوم من قبل i2pd.

الوصف

أخبر الـ router أن تسليم الرسالة قد تم بنجاح وأن الـ router يمكنه التخلص من الرسالة.

مُرسل من العميل إلى الـ router.

المحتويات

1. معرف الجلسة
2. معرف الرسالة

ملاحظات

يتم إرسال ReceiveMessageEndMessage بعد أن تقوم MessagePayloadMessage بتسليم حمولة الرسالة بالكامل.

هذا غير مستخدم في وضع “الاستقبال السريع”، والذي يُعتبر الوضع الافتراضي اعتباراً من الإصدار 0.9.4.

ReconfigureSessionMessage

الوصف

يُرسل من العميل إلى الـ router لتحديث إعدادات الجلسة. يستجيب الـ router برسالة SessionStatusMessage .

المحتويات

1. معرف الجلسة
2. إعدادات الجلسة

ملاحظات

• اعتباراً من الإصدار 0.7.1.
• إذا كان التاريخ في Session Config بعيداً جداً (أكثر من +/- 30 ثانية) عن الوقت الحالي للـ router، سيتم رفض الجلسة.
• يجب ترتيب Mapping في Session Config حسب المفتاح بحيث يتم التحقق من التوقيع بشكل صحيح في الـ router.
• قد يتم تعيين بعض خيارات التكوين فقط في CreateSessionMessage ، والتغييرات هنا لن يتعرف عليها الـ router. التغييرات في خيارات tunnel inbound.* و outbound.* يتم التعرف عليها دائماً.
• بشكل عام، يجب على الـ router دمج التكوين المحدث مع التكوين الحالي، لذا فإن التكوين المحدث يحتاج فقط إلى احتواء الخيارات الجديدة أو المتغيرة. ومع ذلك، بسبب الدمج، لا يمكن إزالة الخيارات بهذه الطريقة؛ يجب تعيينها صراحة إلى القيمة الافتراضية المرغوبة.

ReportAbuseMessage

مُهمل، غير مُستخدم، غير مدعوم

الوصف

أخبر الطرف الآخر (client أو router) أنه تحت الهجوم، مع إشارة محتملة إلى MessageId معين. إذا كان الـ router تحت الهجوم، قد يقرر الـ client الانتقال إلى router آخر، وإذا كان client تحت الهجوم، قد يعيد الـ router بناء routers الخاصة به أو يضع في القائمة السوداء بعض العقد التي أرسلت له رسائل تحمل الهجوم.

يُرسل إما من router إلى العميل أو من العميل إلى router.

المحتويات

1. Session ID
2. 1 byte Integer شدة الإساءة (0 هو الحد الأدنى من الإساءة، 255 هو الحد الأقصى من الإساءة)
3. السبب String
4. Message ID

ملاحظات

غير مستخدم. غير مُنفذ بالكامل. يمكن لكل من router والعميل إنتاج ReportAbuseMessage ، لكن لا يملك أي منهما معالج للرسالة عند استلامها.

RequestLeaseSetMessage

مُهْمَل. غير مدعوم من قِبل i2pd. لا يتم إرساله من Java I2P إلى عملاء الإصدار 0.9.7 أو أعلى (2013-07). استخدم RequestVariableLeaseSetMessage.

الوصف

طلب من العميل للموافقة على تضمين مجموعة معينة من tunnels الواردة. يُرسل من الـ router إلى العميل. يستجيب العميل برسالة CreateLeaseSetMessage .

أول هذه الرسائل المُرسلة في جلسة هي إشارة للعميل بأن الأنفاق قد تم بناؤها وهي جاهزة لحركة البيانات. يجب على الـ router عدم إرسال أول هذه الرسائل حتى يتم بناء نفق واحد على الأقل للبيانات الواردة ونفق واحد للبيانات الصادرة. يجب على العملاء إنهاء الجلسة وتدميرها إذا لم يتم استلام أول هذه الرسائل بعد فترة زمنية معينة (مُوصى به: 5 دقائق أو أكثر).

المحتويات

1. Session ID
2. 1 بايت عدد Integer من الأنفاق
3. هذا العدد من أزواج:
   1. Hash
   2. TunnelId
4. تاريخ الانتهاء Date

ملاحظات

هذا يطلب LeaseSet مع جميع إدخالات Lease مُعيّنة لتنتهي صلاحيتها في نفس الوقت. لإصدارات العميل 0.9.7 أو أحدث، يتم استخدام RequestVariableLeaseSetMessage .

RequestVariableLeaseSetMessage

الوصف

طلب من العميل الترخيص بإدراج مجموعة معينة من الأنفاق الواردة.

يُرسل من الـ router إلى العميل. يستجيب العميل برسالة CreateLeaseSetMessage أو CreateLeaseSet2Message .

أول هذه الرسائل المُرسلة في جلسة معينة هي إشارة للعميل بأن الـ tunnels قد تم بناؤها وهي جاهزة لحركة البيانات. يجب على الـ router عدم إرسال أول هذه الرسائل حتى يتم بناء tunnel واحد على الأقل للبيانات الواردة وآخر للبيانات الصادرة. يجب على العملاء إنهاء الجلسة وتدميرها إذا لم يتم استقبال أول هذه الرسائل خلال فترة زمنية معينة (الموصى به: 5 دقائق أو أكثر).

المحتويات

1. Session ID
2. 1 بايت Integer عدد tunnels
3. بهذا العدد من إدخالات Lease

ملاحظات

هذا يطلب LeaseSet مع وقت انتهاء صلاحية فردي لكل Lease .

اعتباراً من الإصدار 0.9.7. بالنسبة للعملاء قبل ذلك الإصدار، استخدم RequestLeaseSetMessage .

SendMessageMessage

الوصف

هذه هي الطريقة التي يرسل بها العميل رسالة (الحمولة) إلى Destination . سيستخدم الـ router انتهاء صلاحية افتراضي.

يُرسل من العميل إلى router. يستجيب router برسالة MessageStatusMessage .

المحتويات

1. معرف الجلسة
2. الوجهة
3. الحمولة
4. 4 بايت عدد صحيح nonce

ملاحظات

بمجرد وصول SendMessageMessage بشكل كامل وسليم، يجب على الـ router أن يُرجع MessageStatusMessage يُفيد بأنه تم قبولها للتسليم. ستحتوي تلك الرسالة على نفس الـ nonce المُرسل هنا. لاحقاً، بناءً على ضمانات التسليم لإعدادات الجلسة، قد يرسل الـ router إضافياً MessageStatusMessage آخر لتحديث الحالة.

اعتباراً من الإصدار 0.8.1، لا يرسل الـ router أي MessageStatusMessage إذا كان i2cp.messageReliability=none.

قبل الإصدار 0.9.4، لم تكن قيمة nonce البالغة 0 مسموحة. اعتباراً من الإصدار 0.9.4، أصبحت قيمة nonce البالغة 0 مسموحة، وتخبر router أنه يجب ألا يرسل MessageStatusMessage ، أي أنه يتصرف كما لو أن i2cp.messageReliability=none لهذه الرسالة فقط.

قبل الإصدار 0.9.14، لم يكن بإمكان تجاوز جلسة بها i2cp.messageReliability=none على أساس كل رسالة على حدة. اعتباراً من الإصدار 0.9.14، في جلسة بها i2cp.messageReliability=none، يمكن للعميل طلب تسليم MessageStatusMessage مع نجاح أو فشل التسليم عن طريق تعيين nonce لقيمة غير صفرية. لن يرسل router رسالة MessageStatusMessage الخاصة بـ “accepted” ولكنه سيرسل لاحقاً للعميل MessageStatusMessage بنفس nonce، وقيمة نجاح أو فشل.

SendMessageExpiresMessage

الوصف

يُرسل من العميل إلى الـ router. مماثل لـ SendMessageMessage ، باستثناء أنه يتضمن انتهاء صلاحية وخيارات.

المحتويات

1. Session ID
2. Destination
3. Payload
4. 4 بايت Integer nonce
5. 2 بايت من الخيارات (flags)
6. تاريخ انتهاء الصلاحية Date مقطوع من 8 بايت إلى 6 بايت

ملاحظات

اعتباراً من الإصدار 0.7.1.

في وضع “أفضل جهد”، بمجرد وصول SendMessageExpiresMessage كاملة وسليمة، يجب على الـ router أن يُرجع MessageStatusMessage تُفيد بأنه تم قبولها للتسليم. ستحتوي تلك الرسالة على نفس الـ nonce المُرسل هنا. لاحقاً، بناءً على ضمانات التسليم لتكوين الجلسة، قد يُرسل الـ router أيضاً MessageStatusMessage أخرى لتحديث الحالة.

اعتباراً من الإصدار 0.8.1، لا يرسل الـ router أي Message Status Message إذا كان i2cp.messageReliability=none.

قبل الإصدار 0.9.4، لم تكن قيمة nonce بـ 0 مسموحة. اعتباراً من الإصدار 0.9.4، أصبحت قيمة nonce بـ 0 مسموحة، وتخبر الـ router أنه يجب ألا يرسل أي Message Status Message، أي أنها تعمل كما لو أن i2cp.messageReliability=none لهذه الرسالة فقط.

قبل الإصدار 0.9.14، لم يكن بالإمكان تجاوز جلسة بإعداد i2cp.messageReliability=none على أساس كل رسالة على حدة. اعتباراً من الإصدار 0.9.14، في جلسة بإعداد i2cp.messageReliability=none، يمكن للعميل طلب تسليم Message Status Message مع نجاح أو فشل التسليم عن طريق تعيين nonce إلى قيمة غير صفرية. لن يرسل الموجه Message Status Message “مقبولة” ولكنه سيرسل لاحقاً للعميل Message Status Message بنفس nonce، وقيمة نجاح أو فشل.

حقل الأعلام

اعتباراً من الإصدار 0.8.4، تم إعادة تعريف البايتين العلويين من التاريخ لاحتواء الأعلام. يجب أن تكون الأعلام افتراضياً جميعها أصفار للتوافق مع الإصدارات السابقة. لن يتداخل التاريخ مع حقل الأعلام حتى عام 10889. قد يستخدم التطبيق الأعلام لتوفير تلميحات للموجه حول ما إذا كان يجب تسليم LeaseSet و/أو ElGamal/AES Session Tags مع الرسالة. ستؤثر الإعدادات بشكل كبير على كمية الحمولة الإضافية للبروتوكول وموثوقية تسليم الرسائل. يتم تعريف بتات الأعلام الفردية كما يلي، اعتباراً من الإصدار 0.9.2. التعريفات عرضة للتغيير. استخدم فئة SendMessageOptions لبناء الأعلام.

ترتيب البت: 15…0

البتات 15-11

غير مستخدم، يجب أن يكون صفراً

البتات 10-9

تجاوز موثوقية الرسالة (غير مُنفذ، سيتم إزالته).

: إذا كان 1، لا تضمن lease set في garlic encryption مع هذه الرسالة. إذا

0, the router may bundle a lease set at its discretion.

البتات 7-4

الحد الأدنى للعلامات. إذا كان عدد العلامات المتاحة أقل من هذا الرقم،

send more. This is advisory and does not force tags to be delivered. For ElGamal only. Ignored for ECIES-Ratchet.

: عدد العلامات المراد إرسالها عند الحاجة. هذا استشاري ولا

force tags to be delivered. For ElGamal only. Ignored for
ECIES-Ratchet.

الوصف

توجيه العميل بخصوص حالة جلسته.

يُرسل من الـ Router إلى العميل، كاستجابة لـ CreateSessionMessage أو ReconfigureSessionMessage أو DestroySessionMessage . في جميع الحالات، بما في ذلك الاستجابة لـ CreateSessionMessage ، يجب على الـ router أن يستجيب فوراً (لا تنتظر بناء الـ tunnels).

المحتويات

1. معرف الجلسة
2. 1 بايت عدد صحيح الحالة

قيم الحالة محددة أعلاه. إذا كانت الحالة Created، فإن معرف الجلسة هو المعرف الذي سيتم استخدامه لبقية الجلسة.

SetDateMessage

الوصف

التاريخ والوقت الحالي. يتم إرساله من الـ Router إلى العميل كجزء من المصافحة الأولية. اعتباراً من الإصدار 0.9.20، يمكن أيضاً إرساله في أي وقت بعد المصافحة لإشعار العميل بتغيير في الساعة.

المحتويات

1. التاريخ
2. إصدار I2CP API String

ملاحظات

هذه عموماً أول رسالة يرسلها الـ router. يتم تضمين نص الإصدار اعتباراً من الإصدار 0.8.7. هذا مفيد فقط إذا لم يكن العميل والـ router في نفس JVM. إذا لم تكن موجودة، فإن الـ router هو إصدار 0.8.6 أو أقدم.

لن يتم إرسال رسائل SetDate إضافية إلى العملاء في نفس JVM.

المراجع

• التاريخ
• الوجهة
• EncryptedLeaseSet
• الهاش
• نظرة عامة على I2CP
• وثائق I2CP Javadocs
• العدد الصحيح
• Lease
• LeaseSet
• LeaseSet2
• التخطيط
• MetaLeaseSet
• وثائق MessageStatusMessage Javadocs
• المفتاح الخاص
• المفتاح العام
• هوية router
• SAMv3
• التوقيع
• مفتاح التوقيع الخاص
• مفتاح التوقيع العام
• النص
• معرف tunnel