يوجد عدة عملاء وخوادم تتبع bittorrent على I2P. نظراً لأن عنونة I2P تستخدم Destination بدلاً من عنوان IP ومنفذ، فإن تغييرات طفيفة مطلوبة على برامج خوادم التتبع والعملاء للعمل على I2P. هذه التغييرات محددة أدناه. لاحظ بعناية الإرشادات للتوافق مع عملاء وخوادم تتبع I2P الأقدم.
تحدد هذه الصفحة تفاصيل البروتوكول المشتركة بين جميع العملاء والمتتبعات. قد تنفذ عملاء ومتتبعات محددة ميزات أو بروتوكولات فريدة أخرى.
نرحب بالمزيد من عمليات نقل برامج العميل والمتتبع إلى I2P.
إرشادات عامة للمطورين
معظم عملاء bittorrent غير المكتوبة بـ Java ستتصل بـ I2P عبر SAMv3 . جلسات SAM (أو داخل I2P، مجمعات tunnel أو مجموعات من tunnels) مصممة لتكون طويلة المدى. معظم عملاء bittorrent ستحتاج فقط لجلسة واحدة، يتم إنشاؤها عند البدء وإغلاقها عند الخروج. I2P مختلف عن Tor، حيث يمكن إنشاء الدوائر والتخلص منها بسرعة. فكر بعناية واستشر مطوري I2P قبل تصميم تطبيقك لاستخدام أكثر من جلسة أو اثنتين متزامنتين، أو لإنشاؤها والتخلص منها بسرعة. يجب على عملاء bittorrent عدم إنشاء جلسة فريدة لكل اتصال. صمم عميلك لاستخدام نفس الجلسة للإعلانات واتصالات العميل.
أيضاً، يرجى التأكد من أن إعدادات العميل الخاص بك (والإرشادات للمستخدمين حول إعدادات الـ router، أو الإعدادات الافتراضية للـ router إذا كنت تقوم بتجميع router) ستؤدي إلى مساهمة المستخدمين بموارد أكثر للشبكة مما يستهلكونه. I2P هي شبكة نظير إلى نظير، ولا يمكن للشبكة البقاء إذا كان تطبيق شائع يدفع الشبكة إلى ازدحام دائم.
لا تقدم الدعم لـ bittorrent من خلال outproxy الخاص بـ I2P إلى الشبكة العادية (clearnet) لأنه على الأرجح سيتم حظره. استشر مشغلي outproxy للحصول على التوجيه.
تطبيقات router الخاصة بـ Java I2P و i2pd مستقلة ولديها اختلافات طفيفة في السلوك ودعم الميزات والإعدادات الافتراضية. يرجى اختبار تطبيقك مع أحدث إصدار من كلا الـ router.
i2pd SAM مُفعّل افتراضياً؛ أما Java I2P SAM فليس كذلك. قدم تعليمات لمستخدميك حول كيفية تفعيل SAM في Java I2P (عبر /configclients في وحدة تحكم router)، و/أو قدم رسالة خطأ واضحة للمستخدم في حالة فشل الاتصال الأولي، مثل “تأكد من أن I2P يعمل وأن واجهة SAM مُفعّلة”.
router Java I2P وi2pd لديهما إعدادات افتراضية مختلفة لكميات tunnel. الافتراضي لـ Java هو 2 والافتراضي لـ i2pd هو 5. بالنسبة لمعظم عمليات النقل ذات النطاق الترددي المنخفض إلى المتوسط وأعداد الاتصالات المنخفضة إلى المتوسطة، 3 كافية. يرجى تحديد كمية tunnel في رسالة SESSION CREATE للحصول على أداء متسق مع router Java I2P وi2pd.
يدعم I2P أنواعاً متعددة من التوقيع والتشفير. للتوافق، يستخدم I2P بشكل افتراضي أنواعاً قديمة وغير فعالة، لذلك يجب على جميع العملاء تحديد أنواع أحدث.
إذا كنت تستخدم SAM، فيتم تحديد نوع التوقيع في أوامر DEST GENERATE و SESSION CREATE (للجلسات المؤقتة). يجب على جميع العملاء تعيين SIGNATURE_TYPE=7 (Ed25519).
يتم تحديد نوع التشفير في أمر SAM SESSION CREATE أو في خيارات i2cp. يُسمح بأنواع تشفير متعددة. بعض المتتبعات تدعم ECIES-X25519، وبعضها يدعم ElGamal، وبعضها يدعم كليهما. يجب على العملاء تعيين i2cp.leaseSetEncType=4,0 (لـ ECIES-X25519 و ElGamal) حتى يتمكنوا من الاتصال بكليهما.
دعم DHT يتطلب SAMv3.3 PRIMARY و SUBSESSIONS لـ TCP و UDP عبر نفس الجلسة. هذا سيتطلب جهد تطوير كبير على جانب العميل، ما لم يكن العميل مكتوباً بـ Java. i2pd لا يدعم حالياً SAMv3.3. libtorrent لا يدعم حالياً SAMv3.3.
بدون دعم DHT، قد ترغب في الإعلان تلقائياً إلى قائمة قابلة للتكوين من trackers المفتوحة المعروفة حتى تعمل روابط magnet. استشر مستخدمي I2P للحصول على معلومات حول trackers المفتوحة المتاحة حالياً واحرص على إبقاء إعداداتك الافتراضية محدّثة. دعم امتداد i2p_pex سيساعد أيضاً في التخفيف من نقص دعم DHT.
للحصول على مزيد من التوجيه للمطورين حول ضمان استخدام تطبيقك للموارد التي يحتاجها فقط، يرجى مراجعة مواصفات SAMv3 ودليلنا لتجميع I2P مع تطبيقك . اتصل بمطوري I2P أو i2pd للحصول على مساعدة إضافية.
الإعلانات
عادة ما تتضمن العملاء معامل port=6881 وهمي في الإعلان، للتوافق مع أجهزة التتبع الأقدم. قد تتجاهل أجهزة التتبع معامل المنفذ، ولا يجب أن تطلبه.
معامل ip هو التشفير base 64 لـ Destination الخاص بالعميل، باستخدام أبجدية I2P Base 64 [A-Z][a-z][0-9]-~. Destinations تبلغ 387+ بايت، لذا فإن Base 64 يبلغ 516+ بايت. العملاء عادة ما يضيفون “.i2p” إلى Base 64 Destination للتوافق مع المتتبعات الأقدم. يجب ألا تتطلب المتتبعات إضافة “.i2p”.
المعاملات الأخرى هي نفسها كما في bittorrent القياسي.
الوجهات الحالية للعملاء هي 387 بايت أو أكثر (516 أو أكثر في ترميز Base 64). الحد الأقصى المعقول للافتراض، في الوقت الحالي، هو 475 بايت. نظرًا لأن المتتبع يجب أن يفك تشفير Base64 لتقديم استجابات مضغوطة (انظر أدناه)، فمن المحتمل أن يقوم المتتبع بفك التشفير ورفض Base64 السيء عند الإعلان.
نوع الاستجابة الافتراضي هو غير مضغوط. يمكن للعملاء طلب استجابة مضغوطة باستخدام المعامل compact=1. يمكن للمتتبع، ولكن ليس مطلوباً منه، إرجاع استجابة مضغوطة عند الطلب. ملاحظة: جميع المتتبعات الشائعة تدعم الآن الاستجابات المضغوطة وواحد على الأقل يتطلب compact=1 في الإعلان. يجب على جميع العملاء طلب ودعم الاستجابات المضغوطة.
يُشجع بقوة مطوري عملاء I2P الجدد على تنفيذ الإعلانات عبر tunnel خاص بهم بدلاً من HTTP client proxy على المنفذ 4444. القيام بذلك أكثر كفاءة ويسمح بفرض الوجهة من قبل المتتبع (انظر أدناه).
تم الانتهاء من مواصفات إعلانات UDP في يونيو 2025. سيتم طرح الدعم في عملاء I2P والـ trackers المختلفة لاحقاً في عام 2025. انظر أدناه للمزيد من المعلومات.
استجابات Tracker غير المضغوطة
ملاحظة: مهجور. جميع أجهزة التتبع الشائعة تدعم الآن الاستجابات المضغوطة وواحد على الأقل يتطلب compact=1 في الإعلان. يجب على جميع العملاء طلب ودعم الاستجابات المضغوطة.
الاستجابة غير المضغوطة تماماً كما هو الحال في bittorrent القياسي، مع “ip” خاص بـ I2P. هذا عبارة عن “سلسلة DNS” طويلة مُرمزة بـ base64، على الأرجح مع لاحقة “.i2p”.
تتضمن أجهزة التتبع (Trackers) عادةً مفتاح منفذ وهمي، أو تستخدم المنفذ من الإعلان، للتوافق مع العملاء الأقدم. يجب على العملاء تجاهل معامل المنفذ، ويجب ألا يطلبوه.
قيمة مفتاح ip هي base 64 لـ Destination الخاص بالعميل، كما هو موضح أعلاه. عادةً ما تلحق أجهزة التتبع “.i2p” بـ Base 64 Destination إذا لم تكن موجودة في ip الإعلان، للتوافق مع العملاء الأقدم. يجب ألا تتطلب العملاء إلحاق “.i2p” في الاستجابات.
مفاتيح وقيم الاستجابة الأخرى هي نفسها كما في بيتتورنت القياسي.
استجابات المتتبع المضغوطة
في الاستجابة المضغوطة، تكون قيمة مفتاح القاموس “peers” عبارة عن سلسلة بايت واحدة، يكون طولها مضاعفاً لـ 32 بايت. تحتوي هذه السلسلة على Hash SHA-256 بحجم 32 بايت المتسلسلة للـ Destinations الثنائية للأقران. يجب حساب هذا الـ hash بواسطة الـ tracker، إلا في حالة استخدام فرض الوجهة (انظر أدناه)، وفي هذه الحالة يمكن تحويل الـ hash المُسلم في رؤوس HTTP الخاصة بـ X-I2P-DestHash أو X-I2P-DestB32 إلى شكل ثنائي وتخزينه. قد يكون مفتاح الأقران غائباً، أو قد تكون قيمة الأقران بطول صفر.
بينما يعتبر دعم الاستجابة المضغوطة اختيارياً لكل من العملاء والـ trackers، إلا أنه موصى به بشدة لأنه يقلل من حجم الاستجابة الاسمي بأكثر من 90%.
فرض الوجهة
بعض عملاء I2P لـ bittorrent، وليس جميعها، تعلن عبر أنفاقها الخاصة. قد تختار المتتبعات منع التلاعب عن طريق طلب ذلك، والتحقق من Destination الخاص بالعميل باستخدام رؤوس HTTP المضافة بواسطة نفق I2PTunnel HTTP Server. الرؤوس هي X-I2P-DestHash و X-I2P-DestB64 و X-I2P-DestB32، والتي تمثل تنسيقات مختلفة لنفس المعلومات. لا يمكن للعميل تزييف هذه الرؤوس. المتتبع الذي يفرض استخدام destinations لا يحتاج إلى طلب معامل ip announce على الإطلاق.
نظراً لأن عدة clients تستخدم HTTP proxy بدلاً من tunnel الخاص بها للإعلانات، فإن فرض الوجهة سيمنع الاستخدام من قبل تلك العملاء إلا إذا أو حتى يتم تحويل هؤلاء العملاء للإعلان عبر tunnel الخاص بهم.
للأسف، مع نمو الشبكة، ستزداد أيضاً كمية الأنشطة الضارة، لذا نتوقع أن جميع أجهزة التتبع ستطبق في النهاية قيود الوجهات. يجب على مطوري أجهزة التتبع والعملاء توقع ذلك.
الإعلان عن أسماء المضيفين
أسماء المضيفين لعناوين URL الإعلانية في ملفات torrent تتبع عموماً معايير التسمية في I2P . بالإضافة إلى أسماء المضيفين من دفاتر العناوين وأسماء المضيفين Base 32 بصيغة “.b32.i2p”، يجب دعم Destination كامل بصيغة Base 64 (مع أو بدون إضافة “.i2p”). المتتبعات غير المفتوحة يجب أن تتعرف على اسم المضيف الخاص بها في أي من هذه التنسيقات.
للحفاظ على إخفاء الهوية، يجب على العملاء عموماً تجاهل عناوين URL للإعلان غير الخاصة بـ I2P في ملفات التورنت.
اتصالات العميل
تستخدم الاتصالات من عميل إلى عميل البروتوكول المعياري عبر TCP. لا توجد عملاء I2P معروفون يدعمون حالياً التواصل عبر uTP.
يستخدم I2P عناوين Destinations بحجم 387+ بايت، كما هو موضح أعلاه.
إذا كان لدى العميل فقط hash الخاص بالوجهة (مثل من استجابة مضغوطة أو PEX)، فيجب عليه تنفيذ بحث عن طريق تشفيرها باستخدام Base 32، وإلحاق “.b32.i2p”، والاستعلام من خدمة الأسماء، والتي ستعيد الوجهة الكاملة إذا كانت متوفرة.
إذا كان لدى العميل Destination كامل لنظير تلقاه في استجابة غير مضغوطة، فيجب عليه استخدامه مباشرة في إعداد الاتصال. لا تقم بتحويل Destination إلى hash Base 32 للبحث، فهذا غير فعال جداً.
منع الشبكات المتقاطعة
للحفاظ على إخفاء الهوية، عملاء bittorrent في I2P عادة لا يدعمون الإعلانات غير المتعلقة بـ I2P أو اتصالات الأقران. خوادم HTTP الوسيطة الخارجية في I2P غالباً ما تحجب الإعلانات. لا توجد خوادم SOCKS وسيطة خارجية معروفة تدعم حركة مرور bittorrent.
لمنع الاستخدام من قبل عملاء غير I2P عبر HTTP inproxy، غالباً ما تحجب متتبعات I2P الوصول أو الإعلانات التي تحتوي على رأس HTTP من نوع X-Forwarded-For. يجب على المتتبعات رفض إعلانات الشبكة العادية التي تحتوي على عناوين IPv4 أو IPv6، وعدم تسليمها في الاستجابات.
PEX
I2P PEX يعتمد على ut_pex. حيث أنه لا يبدو أن هناك مواصفة رسمية لـ ut_pex متاحة، قد يكون من الضروري مراجعة مصدر libtorrent للحصول على المساعدة. إنها رسالة إضافية، محددة باسم “i2p_pex” في مصافحة الإضافة . تحتوي على قاموس مُرمز bencoded بما يصل إلى 3 مفاتيح، “added” و “added.f” و “dropped”. قيم added و dropped هي كل واحدة منها سلسلة بايت واحدة، طولها مضاعف لـ 32 بايت. هذه سلاسل البايت هي هاشات SHA-256 المتسلسلة للـ Destinations الثنائية للنظراء. هذا هو نفس التنسيق كقيمة قاموس النظراء في تنسيق استجابة i2p المضغوط المحدد أعلاه. قيمة added.f، إذا كانت موجودة، هي نفسها كما في ut_pex.
DHT
دعم DHT مدرج في عميل i2psnark اعتباراً من الإصدار 0.9.2. الاختلافات الأولية عن BEP 5 موصوفة أدناه، وهي قابلة للتغيير. تواصل مع مطوري I2P إذا كنت ترغب في تطوير عميل يدعم DHT.
على عكس DHT المعياري، فإن I2P DHT لا يستخدم بت في مصافحة الخيارات، أو رسالة PORT. يتم الإعلان عنه برسالة إضافية، معرفة باسم “i2p_dht” في مصافحة الإضافة . تحتوي على قاموس مُرمز بـ bencoded مع مفتاحين، “port” و “rport”، كلاهما أعداد صحيحة.
منفذ UDP (الرزم البيانية) المدرج في معلومات العقدة المضغوطة يُستخدم لاستقبال الرزم البيانية القابلة للرد (الموقعة). يُستخدم هذا للاستعلامات، باستثناء الإعلانات. نطلق على هذا “منفذ الاستعلام”. هذه هي قيمة “port” من رسالة الإضافة. تستخدم الاستعلامات بروتوكول I2CP رقم 17.
بالإضافة إلى منفذ UDP ذلك، نستخدم منفذ datagram ثانٍ يساوي منفذ الاستعلام + 1. يُستخدم هذا لاستقبال datagram غير الموقعة (الخام) للردود والأخطاء والإعلانات. يوفر هذا المنفذ كفاءة متزايدة حيث أن الردود تحتوي على tokens مُرسلة في الاستعلام، ولا تحتاج إلى توقيع. نسمي هذا “منفذ الاستجابة”. هذه هي قيمة “rport” من رسالة التوسيع. يجب أن تكون 1 + منفذ الاستعلام. الاستجابات والإعلانات تستخدم بروتوكول I2CP رقم 18.
معلومات النظير المضغوطة هي 32 بايت (32 بايت SHA256 Hash) بدلاً من 4 بايت IP + 2 بايت منفذ. لا يوجد منفذ نظير. في الاستجابة، مفتاح “values” هو قائمة من السلاسل النصية، كل منها يحتوي على معلومات نظير مضغوطة واحدة.
معلومات العقدة المدمجة هي 54 بايت (20 بايت Node ID + 32 بايت SHA256 Hash + 2 بايت للمنفذ) بدلاً من 20 بايت Node ID + 4 بايت IP + 2 بايت للمنفذ. في الاستجابة، مفتاح “nodes” هو سلسلة بايت واحدة مع معلومات العقدة المدمجة المتسلسلة.
متطلب معرف العقدة الآمن: لجعل هجمات DHT المختلفة أكثر صعوبة، يجب أن تتطابق البايتات الأربعة الأولى من معرف العقدة مع البايتات الأربعة الأولى من hash الوجهة، ويجب أن تتطابق البايتان التاليان من معرف العقدة مع البايتين التاليين من hash الوجهة بعد إجراء عملية exclusive-OR مع المنفذ.
في ملف torrent، مفتاح القاموس “nodes” للـ torrent اللاتتبعي (trackerless) لا يزال قيد التحديد. يمكن أن يكون قائمة من السلاسل النصية الثنائية بطول 32 بايت (SHA256 Hashes) بدلاً من قائمة من القوائم التي تحتوي على نص المضيف ورقم المنفذ الصحيح. البدائل: سلسلة نصية واحدة من البايتات مع hashes متسلسلة، أو قائمة من السلاسل النصية وحدها.
متتبعات Datagram (UDP)
تم الانتهاء من مواصفات UDP announces في I2P في 2025-06. سيتم طرح الدعم في عملاء I2P والـ trackers المختلفة لاحقاً في عام 2025. الاختلافات عن BEP 15 موثقة في مواصفات UDP announce . تتطلب المواصفات أيضاً دعم تنسيقات Datagram 2/3 الجديدة .
معلومات إضافية
- معايير I2P bittorrent تُناقش عمومًا على zzz.i2p .
- مخطط بإمكانيات برمجيات المتتبع الحالية متاح أيضًا هناك .
- الأسئلة الشائعة حول I2P bittorrent
- نقاش DHT على I2P