مرحباً يا جماعة، حان وقت تحديثنا الأسبوعي

الفهرس:

  1. 0.4.1.2
  2. 0.4.1.3
  3. 0.4.2
  4. mail discussions
  5. ???

1) 0.4.1.2

صدرت النسخة الجديدة 0.4.1.2 منذ بضعة أيام، والأمور تسير إلى حدٍ كبير كما كان متوقعًا — إلا أن هناك بعض العثرات مع مكوّن الـ watchdog الجديد، إذ يؤدي ذلك إلى قتل الـ router عندما تكون الأمور سيئة بدلًا من إعادة تشغيله. كما ذكرتُ في وقتٍ سابق اليوم، أبحث عن أشخاص يستخدمون أداة تسجيل الإحصاءات الجديدة لإرسال بعض البيانات إليّ، لذا سيكون دعمكم في ذلك محل تقدير كبير.

2) 0.4.1.3

سيكون هناك إصدار آخر قبل صدور 0.4.2، لأنني أريد أن تكون الشبكة مستقرة قدر الإمكان قبل المضي قدمًا. ما أُجرّبه حاليًا هو آلية خنق ديناميكية للمشاركة في tunnel — بإبلاغ الـ routers برفض الطلبات احتماليًا إذا كانت مُغرَقة بالطلبات أو كانت الـ tunnels لديها أبطأ من المعتاد. تُحسَب هذه الاحتمالات والعتبات ديناميكيًا من الإحصاءات المُسجَّلة — إذا كان زمن اختبار الـ tunnel خلال 10 دقائق أكبر من زمن اختبار الـ tunnel خلال 60 دقيقة، فاقبل طلب الـ tunnel باحتمال 60minRate/10minRate (وإذا كان عدد tunnels الحالي لديك أكبر من متوسط عدد tunnels خلال 60 دقيقة، فاقبله باحتمال p=60mRate/curTunnels).

آلية تقييد محتملة أخرى هي تنعيم عرض النطاق الترددي على هذا المنوال - رفض tunnels بشكل احتمالي عندما يشهد استخدامنا لعرض النطاق الترددي ارتفاعات حادة. على أي حال، الهدف من كل ذلك هو المساعدة على توزيع استخدام الشبكة وموازنة tunnels عبر عدد أكبر من الأشخاص. كانت المشكلة الرئيسية التي واجهتنا مع موازنة التحميل هي وجود فائض ساحق في السعة، وبناءً على ذلك لم يتم تفعيل أي من مشغلاتنا “اللعنة، نحن بطيئون، فلنرفض”. من المفترض أن تساعد هذه الآليات الاحتمالية الجديدة في إبقاء التغيّر السريع تحت السيطرة.

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

3) 0.4.2

كما ناقشنا في اجتماع الأسبوع الماضي، قمنا بمبادلة إصداري 0.4.2 و0.4.3 - سيكون الإصدار 0.4.2 هو مكتبة التدفق الجديدة، وسيكون الإصدار 0.4.3 تحديث tunnel.

لقد كنت أعيد مراجعة الأدبيات المتعلقة بوظائف التدفق في TCP، وهناك بعض الموضوعات المثيرة للاهتمام ذات الصلة بـ I2P. على وجه التحديد، إن زمن الذهاب والإياب (RTT) المرتفع لدينا يدفعنا نحو شيء مثل XCP، وربما ينبغي لنا أن نكون استباقيين بقوة مع أشكال مختلفة من إشعار الازدحام الصريح، على الرغم من أننا لا نستطيع الاستفادة من شيء مثل خيار الطابع الزمني، لأن ساعاتنا قد تنحرف بما يصل إلى دقيقة.

بالإضافة إلى ذلك، سنرغب في التأكد من قدرتنا على تحسين streaming lib (مكتبة التدفق) للتعامل مع الاتصالات قصيرة العمر (والتي يكون TCP القياسي سيئًا للغاية فيها) - على سبيل المثال، أريد أن أتمكن من إرسال طلبات HTTP GET صغيرة (<32KB) وردود صغيرة (<32KB) حرفيًا في ثلاث رسائل:

Alice-->Bob: syn+data+close
Bob-->Alice: ack+data+close (the browser gets the response now)
Alice-->Bob: ack (so he doesn't resend the payload)

على أي حال، لم يُكتب الكثير من الشيفرة لهذا بعد، إذ يبدو جانب البروتوكول شبيهاً إلى حد كبير بـ TCP، بينما تبدو الحزم كأنها دمجٌ بين اقتراح human والاقتراح القديم. إذا كان لدى أي شخص اقتراحات أو أفكار، أو يرغب في المساعدة في التنفيذ، فيُرجى التواصل.

4) مناقشة عبر البريد

كانت هناك بعض النقاشات الشيقة حول البريد الإلكتروني داخل (وخارج) I2P - قام postman بنشر مجموعة من الأفكار على الإنترنت وهو يبحث عن اقتراحات. كانت هناك أيضًا مناقشات ذات صلة على #mail.i2p. ربما يمكننا أن نجعل postman يطلعنا على المستجدات؟

5) ???

هذا تقريباً كل شيء في الوقت الحالي. تعال إلى الاجتماع بعد بضع دقائق وأحضر تعليقاتك :)

=jr