نظرة عامة
تضيف هذه الاقتراحية خيار I2CP للأنفاق الصادرة الذي يتسبب في اختيار أو بناء الأنفاق عند إرسال رسالة بحيث يتطابق OBEP مع أحد IBGWs من LeaseSet للوجهة Destination المستهدفة.
الدافع
تستخدم معظم موجهات I2P نوعًا من إسقاط الحزم لإدارة الاحتقان. يستخدم التنفيذ المرجعي استراتيجية WRED التي تأخذ في الاعتبار حجم الرسالة ومسافة السفر (راجع وثائق tunnel throttling). بسبب هذه الاستراتيجية، يكون المصدر الأساسي لفقدان الحزم هو OBEP.
التصميم
عند إرسال رسالة، يختار المرسل أو يبني نفقًا مع OBEP يكون نفس جهاز التوجيه كإحدى IBGWs للمتلقي. عن طريق القيام بذلك، ستذهب الرسالة مباشرة من نفق إلى الآخر، دون الحاجة إلى إرسالها عبر الشبكة في المنتصف.
التبعات الأمنية
هذا الوضع يعني بشكل فعال أن المتلقي يختار OBEP للمرسل. للحفاظ على الخصوصية الحالية، سيسبب هذا الوضع بناء الأنفاق الصادرة بمقدار قفزة واحدة أطول من المحدد بواسطة خيار I2CP خيار الطول الصادر (مع احتمال أن تكون القفزة النهائية خارج النطاق السريع للمرسل).
المواصفات
تمت إضافة خيار I2CP جديد إلى مواصفات I2CP:
outbound.matchEndWithTarget
Boolean
القيمة الافتراضية: خاصة بالحالة
إذا كانت القيمة true، سيختار الموجه الأنفاق الصادرة للرسائل المرسلة خلال
هذه الجلسة بحيث يكون OBEP للنفق هو أحد IBGWs لوجهة الهدف. إذا لم يكن هناك مثل هذا النفق موجودًا، سيبني الموجه واحدًا.
التوافق
يتم ضمان التوافق العكسي، حيث يمكن للموجهات دائمًا إرسال الرسائل إلى أنفسهم.
التنفيذ
Java I2P
بناء الأنفاق وإرسال الرسائل هما نظامان منفصلان حاليًا:
لا يعرف BuildExecutor سوى خيارات *الأنفاق الصادرة الخاصة بحوض الأنفاق الصادرة، وليس لديه رؤية حول استخدامهم.
لا يمكن لـ OutboundClientMessageOneShotJob سوى اختيار نفق من الحوض الموجود؛ إذا دخلت رسالة عميل ولم تكن هناك أنفاق صادرة، يسقط الموجه الرسالة.
سيتطلب تنفيذ هذا الاقتراح تصميم طريقة لتفاعل هذين النظامين الفرعيين.
i2pd
تم الانتهاء من تنفيذ اختبار.
الأداء
لدى هذا الاقتراح تأثيرات مختلفة على التأخير والزمن اللاتيني وفقدان الحزم:
من المحتمل أنه في معظم الحالات، سيحتاج هذا الوضع إلى بناء نفق جديد لأول رسالة بدلاً من استخدام نفق موجود، مضيفًا تأخيرًا.
للأنفاق العادية، قد يحتاج OBEP إلى العثور على IBGW والاتصال به، مضيفًا تأخيرًا يزيد من الزمن اللاتيني الأول (حيث يحدث ذلك بعد إرسال الحزمة الأولى). باستخدام هذا الوضع، سيحتاج OBEP إلى العثور والاتصال بـ IBGW أثناء بناء النفق، مضيفًا نفس التأخير لكنه يقلل الزمن اللاتيني الأول (حيث يحدث ذلك قبل إرسال الحزمة الأولى).
الحجم الحالي القياسي لبناء الأنفاق VariableTunnelBuild هو 2641 بايت. وبالتالي من المتوقع أن ينتج عن هذا الوضع تقليل فقدان الحزم لأحجام الرسائل المتوسطة التي تزيد عن ذلك.
مزيد من البحث ضروري لاستقصاء هذه التأثيرات، من أجل اتخاذ قرار بشأن الأنفاق القياسية التي ستستفيد من تمكين هذا الوضع بشكل افتراضي.