متتبعات UDP

الحالة

تمت الموافقة عليه في المراجعة 2025-06-24. المواصفة متوفرة في مواصفة UDP. مُنفذ في zzzot 0.20.0-beta2. مُنفذ في i2psnark اعتباراً من API 0.9.67. تحقق من وثائق التنفيذات الأخرى للحالة.

نظرة عامة

هذا الاقتراح مخصص لتطبيق UDP trackers في I2P.

Change History

تم نشر اقتراح أولي لمتتبعات UDP في I2P على صفحة مواصفات bittorrent الخاصة بنا في مايو 2014؛ وقد سبق هذا عملية الاقتراح الرسمية لدينا، ولم يتم تنفيذه قط. تم إنشاء هذا الاقتراح في أوائل عام 2022 ويبسط نسخة 2014.

نظرًا لأن هذا الاقتراح يعتمد على رسائل البيانات القابلة للرد، تم تعليقه بمجرد أن بدأنا العمل على اقتراح Datagram2 في أوائل عام 2023. تمت الموافقة على ذلك الاقتراح في أبريل 2025.

حددت نسخة 2023 من هذا الاقتراح وضعين، “التوافق” و"السريع". كشف التحليل الإضافي أن الوضع السريع سيكون غير آمن، وسيكون أيضاً غير فعال للعملاء الذين لديهم عدد كبير من ملفات التورنت. علاوة على ذلك، أشار BiglyBT إلى تفضيله لوضع التوافق. سيكون هذا الوضع أسهل في التنفيذ لأي متتبع أو عميل يدعم معيار BEP 15.

في حين أن وضع التوافق أكثر تعقيداً للتنفيذ من الصفر على جانب العميل، لدينا كود أولي له بدأناه في عام 2023.

لذلك، الإصدار الحالي هنا مبسط أكثر لإزالة الوضع السريع، وإزالة مصطلح “التوافق”. الإصدار الحالي ينتقل إلى تنسيق Datagram2 الجديد، ويضيف مراجع إلى بروتوكول إعلان UDP الإضافي BEP 41.

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

Motivation

مع استمرار نمو قاعدة المستخدمين بشكل عام وعدد مستخدمي bittorrent على وجه التحديد، نحتاج إلى جعل trackers والإعلانات أكثر كفاءة بحيث لا تكون trackers مثقلة بالأعباء.

اقترح Bittorrent متتبعات UDP في BEP 15 BEP 15 في عام 2008، والغالبية العظمى من المتتبعات على الشبكة العادية أصبحت الآن تعمل بـ UDP فقط.

من الصعب حساب توفير عرض النطاق الترددي للـ datagrams مقابل بروتوكول streaming. الطلب القابل للرد له نفس حجم streaming SYN تقريباً، ولكن الـ payload أصغر بحوالي 500 بايت لأن HTTP GET يحتوي على سلسلة معاملات URL ضخمة بحجم 600 بايت. الرد الخام أصغر بكثير من streaming SYN ACK، مما يوفر تقليلاً كبيراً لحركة البيانات الصادرة من الـ tracker.

بالإضافة إلى ذلك، يجب أن تكون هناك تخفيضات في الذاكرة خاصة بالتنفيذ، حيث أن datagrams تتطلب حالة في الذاكرة أقل بكثير من اتصال streaming.

التشفير وطرق التوقيع Post-Quantum كما هو متصور في /en/proposals/169-pq-crypto/ ستزيد بشكل كبير من الحمولة الإضافية للهياكل المشفرة والموقعة، بما في ذلك destinations و leasesets و streaming SYN و SYN ACK. من المهم تقليل هذه الحمولة الإضافية قدر الإمكان قبل اعتماد تشفير PQ في I2P.

الدافع

هذا الاقتراح يستخدم repliable datagram2 و repliable datagram3 و raw datagrams، كما هو محدد في /en/docs/spec/datagrams/. Datagram2 و Datagram3 هما متغيران جديدان من repliable datagrams، محددان في الاقتراح 163 /en/proposals/163-datagram2/. Datagram2 يضيف مقاومة إعادة التشغيل ودعم التوقيع في وضع عدم الاتصال. Datagram3 أصغر من تنسيق datagram القديم، ولكن بدون مصادقة.

BEP 15

للمرجعية، تدفق الرسائل المحدد في BEP 15 هو كما يلي:

Client                        Tracker
    Connect Req. ------------->
      <-------------- Connect Resp.
    Announce Req. ------------->
      <-------------- Announce Resp.
    Announce Req. ------------->
      <-------------- Announce Resp.

مرحلة الاتصال مطلوبة لمنع انتحال عناوين IP. يُرجع المتتبع معرف اتصال يستخدمه العميل في الإعلانات اللاحقة. ينتهي صلاحية معرف الاتصال هذا افتراضياً خلال دقيقة واحدة عند العميل، وخلال دقيقتين عند المتتبع.

سوف يستخدم I2P نفس تدفق الرسائل كما في BEP 15، لسهولة الاعتماد في قواعد الأكواد الحالية للعملاء القادرة على UDP: من أجل الكفاءة، ولأسباب أمنية مناقشة أدناه:

Client                        Tracker
    Connect Req. ------------->       (Repliable Datagram2)
      <-------------- Connect Resp.   (Raw)
    Announce Req. ------------->      (Repliable Datagram3)
      <-------------- Announce Resp.  (Raw)
    Announce Req. ------------->      (Repliable Datagram3)
      <-------------- Announce Resp.  (Raw)
             ...

هذا يوفر احتمالياً توفيراً كبيراً في عرض النطاق الترددي مقارنة بإعلانات التدفق (TCP). بينما يكون حجم Datagram2 تقريباً نفس حجم streaming SYN، فإن الاستجابة الخام أصغر بكثير من streaming SYN ACK. الطلبات اللاحقة تستخدم Datagram3، والاستجابات اللاحقة تكون خام.

طلبات الإعلان هي Datagram3 بحيث لا يحتاج الـ tracker إلى الاحتفاظ بجدول تعيين كبير لمعرفات الاتصال إلى وجهة الإعلان أو الـ hash. بدلاً من ذلك، قد يقوم الـ tracker بتوليد معرفات الاتصال تشفيرياً من hash المرسل، والطابع الزمني الحالي (بناءً على فترة زمنية معينة)، وقيمة سرية. عندما يتم استلام طلب إعلان، يقوم الـ tracker بالتحقق من صحة معرف الاتصال، ثم يستخدم hash مرسل الـ Datagram3 كهدف الإرسال.

تاريخ التغييرات

بالنسبة للتطبيقات المتكاملة (router والعميل في عملية واحدة، على سبيل المثال i2psnark، وإضافة ZzzOT Java)، أو للتطبيقات المبنية على I2CP (على سبيل المثال BiglyBT)، يجب أن يكون من المباشر تنفيذ وتوجيه حركة البيانات المتدفقة والرسائل المباشرة بشكل منفصل. من المتوقع أن يكون ZzzOT و i2psnark أول متتبع وعميل لتنفيذ هذا الاقتراح.

سيتم مناقشة المتتبعات والعملاء غير المدمجة أدناه.

Trackers

هناك أربعة تطبيقات معروفة لـ I2P tracker:

• zzzot، مكون إضافي متكامل لـ Java router، يعمل على opentracker.dg2.i2p وعدة مواقع أخرى
• tracker2.postman.i2p، يعمل على الأرجح خلف Java router ونفق HTTP Server
• opentracker القديم المكتوب بـ C، تم نقله بواسطة zzz، مع تعطيل دعم UDP
• opentracker الجديد المكتوب بـ C، تم نقله بواسطة r4sas، يعمل على opentracker.r4sas.i2p وربما مواقع أخرى، يعمل على الأرجح خلف i2pd router ونفق HTTP Server

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

Clients

عملاء التورنت الخارجيون المبنيون على SAM مثل qbittorrent والعملاء الأخرى المبنية على libtorrent سوف تتطلب SAM v3.3 والذي غير مدعوم من قبل i2pd. هذا مطلوب أيضاً لدعم DHT، ومعقد بما فيه الكفاية بحيث لم يقم أي عميل تورنت SAM معروف بتطبيقه. لا يُتوقع تطبيقات مبنية على SAM لهذا الاقتراح قريباً.

Connection Lifetime

BEP 15 يحدد أن معرف الاتصال ينتهي خلال دقيقة واحدة في العميل، وخلال دقيقتين في المتتبع. وهو غير قابل للتكوين. هذا يحد من مكاسب الكفاءة المحتملة، ما لم يقم العملاء بتجميع الإعلانات للقيام بها جميعاً ضمن نافزة زمنية مدتها دقيقة واحدة. i2psnark لا يقوم حالياً بتجميع الإعلانات؛ بل ينشرها على فترات، لتجنب اندفاعات حركة المرور. يُذكر أن المستخدمين المتقدمين يشغلون آلاف التورنتات في آن واحد، واندفاع هذا العدد الكبير من الإعلانات في دقيقة واحدة غير واقعي.

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

Compatibility with BEP 15

يحافظ هذا التصميم على التوافق مع BEP 15 قدر الإمكان لتقليل التغييرات المطلوبة في العملاء والمتتبعات الموجودة.

التغيير الوحيد المطلوب هو تنسيق معلومات النظير في استجابة الإعلان. إضافة حقل lifetime في استجابة الاتصال غير مطلوبة ولكنها موصى بها بشدة للكفاءة، كما هو موضح أعلاه.

BEP 15

هدف مهم لبروتوكول الإعلان UDP هو منع انتحال العناوين. يجب أن يكون العميل موجوداً فعلياً ويحزم leaseset حقيقي. يجب أن يملك tunnels واردة لاستقبال Connect Response. هذه tunnels يمكن أن تكون بدون قفزات ومبنية فورياً، لكن ذلك سيكشف المنشئ. هذا البروتوكول يحقق ذلك الهدف.

دعم Tracker/Client

• هذا الاقتراح لا يدعم الوجهات المعماة (blinded destinations)، ولكن قد يتم توسيعه لدعمها. انظر أدناه.

التصميم

Protocols and Ports

Repliable Datagram2 يستخدم I2CP protocol 19؛ repliable Datagram3 يستخدم I2CP protocol 20؛ raw datagrams تستخدم I2CP protocol 18. الطلبات قد تكون Datagram2 أو Datagram3. الردود دائماً raw. تنسيق repliable datagram الأقدم (“Datagram1”) الذي يستخدم I2CP protocol 17 يجب ألا يُستخدم للطلبات أو الردود؛ يجب إسقاط هذه إذا تم استقبالها على منافذ الطلب/الرد. لاحظ أن Datagram1 protocol 17 لا يزال يُستخدم لبروتوكول DHT.

تستخدم الطلبات منفذ I2CP “to port” من رابط الإعلان؛ انظر أدناه. يتم اختيار “from port” للطلب بواسطة العميل، ولكن يجب أن يكون غير صفر، ومنفذ مختلف عن تلك المستخدمة بواسطة DHT، بحيث يمكن تصنيف الاستجابات بسهولة. يجب على المتتبعات رفض الطلبات المستلمة على المنفذ الخاطئ.

الاستجابات تستخدم “منفذ الوجهة” من I2CP من الطلب. “منفذ المصدر” للطلب هو “منفذ الوجهة” من الطلب.

Announce URL

تنسيق URL للإعلان غير محدد في BEP 15، ولكن كما هو الحال في clearnet، فإن URLs الإعلان UDP تكون بالشكل “udp://host:port/path”. يتم تجاهل المسار وقد يكون فارغاً، ولكنه عادة ما يكون “/announce” على clearnet. يجب أن يكون جزء :port موجوداً دائماً، ومع ذلك، إذا تم حذف جزء “:port”، استخدم منفذ I2CP افتراضي وهو 6969، حيث أن هذا هو المنفذ الشائع على clearnet. قد تكون هناك أيضاً معاملات cgi مُضافة &a=b&c=d، والتي يمكن معالجتها وتوفيرها في طلب الإعلان، انظر BEP 41. إذا لم تكن هناك معاملات أو مسار، فيمكن أيضاً حذف الرمز / الأخير، كما هو مضمن في BEP 41.

مدة الاتصال

جميع القيم يتم إرسالها بترتيب البايت الشبكي (big endian). لا تتوقع أن تكون الحزم بحجم معين بالضبط. التحسينات المستقبلية قد تزيد من حجم الحزم.

Connect Request

العميل إلى المتتبع. 16 بايت. يجب أن يكون Datagram2 قابل للرد عليه. نفس الشيء كما في BEP 15. لا توجد تغييرات.

Offset  Size            Name            Value
  0       64-bit integer  protocol_id     0x41727101980 // magic constant
  8       32-bit integer  action          0 // connect
  12      32-bit integer  transaction_id

Connect Response

من المتتبع إلى العميل. 16 أو 18 بايت. يجب أن تكون خام. نفس الشيء كما في BEP 15 باستثناء ما هو مذكور أدناه.

Offset  Size            Name            Value
  0       32-bit integer  action          0 // connect
  4       32-bit integer  transaction_id
  8       64-bit integer  connection_id
  16      16-bit integer  lifetime        optional  // Change from BEP 15

يجب إرسال الاستجابة إلى “منفذ الوجهة” في I2CP الذي تم استلامه كـ “منفذ المصدر” في الطلب.

حقل lifetime اختياري ويشير إلى مدة بقاء connection_id للعميل بالثواني. القيمة الافتراضية هي 60، والحد الأدنى إذا تم تحديده هو 60. الحد الأقصى هو 65535 أو حوالي 18 ساعة. يجب على المتتبع الحفاظ على connection_id لمدة 60 ثانية إضافية أكثر من مدة بقاء العميل.

Announce Request

من العميل إلى المتتبع. 98 بايت كحد أدنى. يجب أن يكون Datagram3 قابل للرد عليه. مطابق لما هو موجود في BEP 15 باستثناء ما هو مذكور أدناه.

الـ connection_id هو كما تم استلامه في استجابة الاتصال.

Offset  Size            Name            Value
  0       64-bit integer  connection_id
  8       32-bit integer  action          1     // announce
  12      32-bit integer  transaction_id
  16      20-byte string  info_hash
  36      20-byte string  peer_id
  56      64-bit integer  downloaded
  64      64-bit integer  left
  72      64-bit integer  uploaded
  80      32-bit integer  event           0     // 0: none; 1: completed; 2: started; 3: stopped
  84      32-bit integer  IP address      0     // default
  88      32-bit integer  key
  92      32-bit integer  num_want        -1    // default
  96      16-bit integer  port
  98      varies          options     optional  // As specified in BEP 41

التغييرات من BEP 15:

• key يتم تجاهلها
• port على الأرجح يتم تجاهلها
• قسم الخيارات، إذا كان موجوداً، يتم تعريفه كما في BEP 41

يجب إرسال الاستجابة إلى “منفذ الوجهة” الخاص بـ I2CP الذي تم استلامه كـ “منفذ المصدر” للطلب. لا تستخدم المنفذ من طلب الإعلان.

Announce Response

من المتتبع إلى العميل. 20 بايت كحد أدنى. يجب أن يكون خاماً. نفس ما هو موجود في BEP 15 باستثناء ما هو مذكور أدناه.

Offset  Size            Name            Value
  0           32-bit integer  action          1 // announce
  4           32-bit integer  transaction_id
  8           32-bit integer  interval
  12          32-bit integer  leechers
  16          32-bit integer  seeders
  20   32 * n 32-byte hash    binary hashes     // Change from BEP 15
  ...                                           // Change from BEP 15

التغييرات من BEP 15:

• بدلاً من 6-byte IPv4+port أو 18-byte IPv6+port، نقوم بإرجاع مضاعف من “الاستجابات المضغوطة” بحجم 32-byte مع SHA-256 binary peer hashes. كما هو الحال مع استجابات TCP المضغوطة، لا نقوم بتضمين port.

يجب إرسال الاستجابة إلى “منفذ الوجهة” I2CP الذي تم استلامه كـ “منفذ المصدر” للطلب. لا تستخدم المنفذ من طلب الإعلان.

تحتوي مخططات البيانات I2P على حد أقصى كبير جداً يبلغ حوالي 64 كيلوبايت؛ ومع ذلك، للتسليم الموثوق، يجب تجنب مخططات البيانات الأكبر من 4 كيلوبايت. من أجل كفاءة عرض النطاق الترددي، يجب أن تقوم أجهزة التتبع بتقييد الحد الأقصى للأقران إلى حوالي 50، مما يتوافق مع حوالي 1600 بايت لكل حزمة قبل الحمولة الإضافية في الطبقات المختلفة، ويجب أن يكون ضمن حد الحمولة لرسالتي tunnel بعد التجزئة.

كما هو الحال في BEP 15، لا يوجد عداد مُضمّن لعدد عناوين الأقران (IP/port في BEP 15، الخلاصات المُجمّعة هنا) التي ستتبع. وبينما لم يُؤخذ هذا في الاعتبار في BEP 15، يمكن تعريف علامة نهاية الأقران المكونة من جميع الأصفار للإشارة إلى أن معلومات الأقران مكتملة وأن بعض بيانات الإضافة تتبع.

لذلك حتى يكون التوسع ممكناً في المستقبل، يجب على العملاء تجاهل hash مكون من 32 بايت جميعها أصفار، وأي بيانات تتبعها. يجب على أجهزة التتبع رفض الإعلانات من hash جميعه أصفار، رغم أن هذا الـ hash محظور بالفعل بواسطة موجهات Java.

Scrape

طلب/استجابة Scrape من BEP 15 غير مطلوب بواسطة هذا الاقتراح، ولكن يمكن تنفيذه إذا رغبت في ذلك، لا توجد تغييرات مطلوبة. يجب على العميل الحصول على معرف الاتصال أولاً. طلب scrape هو دائماً Datagram3 قابل للرد. استجابة scrape هي دائماً خام.

المتتبعات

من المتتبع إلى العميل. 8 بايت كحد أدنى (إذا كانت الرسالة فارغة). يجب أن تكون خام. نفس الشيء كما في BEP 15. لا توجد تغييرات.

Offset  Size            Name            Value
  0       32-bit integer  action          3 // error
  4       32-bit integer  transaction_id
  8       string          message

Extensions

لا يتم تضمين بتات التمديد أو حقل الإصدار. يجب على العملاء والمتتبعات عدم افتراض أن الحزم لها حجم معين. بهذه الطريقة، يمكن إضافة حقول إضافية دون كسر التوافق. يُنصح بتنسيق التمديدات المعرّف في BEP 41 إذا لزم الأمر.

يتم تعديل استجابة الاتصال لإضافة مدة صالحية اختيارية لمعرف الاتصال.

إذا كان دعم الوجهة المخفية (blinded destination) مطلوباً، يمكننا إما إضافة العنوان المخفي المكون من 35 بايت إلى نهاية طلب الإعلان، أو طلب الـ hashes المخفية في الاستجابات، باستخدام تنسيق BEP 41 (المعاملات TBD). يمكن إضافة مجموعة عناوين النظراء (peer addresses) المخفية المكونة من 35 بايت إلى نهاية رد الإعلان، بعد hash مكون من 32 بايت من الأصفار.

Implementation guidelines

راجع قسم التصميم أعلاه لمناقشة التحديات التي تواجه العملاء والمتتبعات غير المتكاملة وغير المستخدمة لـ I2CP.

التوافق مع BEP 15

لاسم مضيف tracker معين، يجب على العميل تفضيل UDP على عناوين HTTP، ويجب ألا يعلن لكليهما.

العملاء الذين يدعمون BEP 15 حاليًا يجب أن يحتاجوا فقط إلى تعديلات صغيرة.

إذا كان العميل يدعم DHT أو بروتوكولات datagram أخرى، فيجب عليه على الأرجح اختيار منفذ مختلف كـ “منفذ المرسل” للطلب بحيث تعود الردود إلى ذلك المنفذ ولا تختلط مع رسائل DHT. العميل يستقبل فقط datagrams خام كردود. أجهزة التتبع لن ترسل أبداً datagram2 قابل للرد إلى العميل.

العملاء الذين لديهم قائمة افتراضية من الـ opentrackers يجب أن يحدثوا القائمة لإضافة عناوين UDP بعد أن تصبح الـ opentrackers المعروفة معروفة بدعمها لـ UDP.

قد يقوم العملاء بتنفيذ إعادة إرسال الطلبات أو قد لا يقومون بذلك. إعادة الإرسال، في حال تنفيذها، يجب أن تستخدم مهلة زمنية أولية لا تقل عن 15 ثانية، وتضاعف المهلة الزمنية لكل إعادة إرسال (التراجع الأسي).

يجب على العملاء التراجع بعد تلقي استجابة خطأ.

تحليل الأمان

المتتبعات التي تدعم BEP 15 حاليًا يجب أن تتطلب تعديلات صغيرة فقط. يختلف هذا الاقتراح عن اقتراح 2014، في أن المتتبع يجب أن يدعم استقبال datagram2 و datagram3 القابلة للرد على نفس المنفذ.

لتقليل متطلبات موارد tracker، تم تصميم هذا البروتوكول للقضاء على أي متطلب بأن يخزن tracker خرائط hashes العملاء إلى معرفات الاتصال للتحقق اللاحق. هذا ممكن لأن حزمة طلب الإعلان هي حزمة Datagram3 قابلة للرد، لذا فهي تحتوي على hash المرسل.

التنفيذ الموصى به هو:

• عرّف الحقبة الحالية كالوقت الحالي بدقة تساوي مدة الاتصال، epoch = now / lifetime.
• عرّف دالة تشفير تجمعية H(secret, clienthash, epoch) تولد مخرجات بحجم 8 بايت.
• ولّد الثابت العشوائي السري المستخدم لجميع الاتصالات.
• لاستجابات الاتصال، ولّد connection_id = H(secret, clienthash, epoch)
• لطلبات الإعلان، تحقق من معرف الاتصال المستلم في الحقبة الحالية بالتأكد من connection_id == H(secret, clienthash, epoch) || connection_id == H(secret, clienthash, epoch - 1)

Migration

العملاء الحاليون لا يدعمون عناوين URL للإعلان عبر UDP ويتجاهلونها.

أدوات التتبع الموجودة لا تدعم استقبال الرسائل القابلة للرد أو البيانات الخام، وسيتم إسقاطها.

هذا الاقتراح اختياري بالكامل. لا يُطلب من العملاء أو المتتبعات تنفيذه في أي وقت.

Rollout

من المتوقع أن تكون التطبيقات الأولى في ZzzOT و i2psnark. سيتم استخدامها لاختبار والتحقق من هذا الاقتراح.

التطبيقات الأخرى ستتبع حسب الرغبة بعد اكتمال الاختبار والتحقق.