مرحباً يا جماعة، إنه يوم الثلاثاء مجدداً

الفهرس

  1. 0.4.1.3
  2. Tunnel test time, and send processing time
  3. Streaming lib
  4. files.i2p
  5. ???

1) 0.4.1.3

صدر إصدار 0.4.1.3 قبل يوم أو يومين، ويبدو أن معظم المستخدمين قد حدّثوا (شكرًا!). تعمل الشبكة بشكل جيد إلى حدٍّ ما، لكننا لم نشهد بعد زيادةً ثورية في الاعتمادية. ومع ذلك، فإن أخطاء الـ watchdog (مراقب النظام) في 0.4.1.2 قد اختفت (أو على الأقل لم يذكرها أحد). هدفي أن يكون إصدار 0.4.1.3 آخر تصحيح قبل 0.4.2، وبالطبع إذا ظهر شيء كبير يحتاج إلى إصلاح، فسنصدر تصحيحًا آخر.

2) زمن اختبار Tunnel، وزمن معالجة الإرسال

أهم التغييرات في إصدار 0.4.1.3 كانت على اختبار tunnel - فبدلاً من وجود فترة اختبار ثابتة (30 ثانية!)، أصبح لدينا مهلات زمنية (timeouts) أكثر صرامة مشتقة من الأداء المقاس. هذا أمر جيد، إذ إننا الآن نصنّف tunnels على أنها فاشلة عندما تكون بطيئة جداً بحيث لا تستطيع إنجاز أي شيء مفيد. ومع ذلك، فهذا أمر سيئ، إذ إن tunnels أحياناً تتكدّس مؤقتاً، وإذا اختبرناها خلال تلك الفترة نعلن فشل tunnel كانت لتعمل لولا ذلك.

رسم بياني حديث يوضح المدة التي يستغرقها اختبار tunnel على router واحد:

تلك أزمنة اختبار tunnel (نفق) مقبولة عمومًا - فهي تمر عبر 4 أقران بعيدين (مع tunnels من قفزتين)، مما يجعل معظمها ~1-200ms لكل قفزة. ومع ذلك، فليس هذا هو الحال دائمًا، كما ترى - ففي بعض الأحيان يستغرق الأمر بحدود ثوانٍ لكل قفزة.

وهنا يأتي دور المخطط التالي - زمن قائمة الانتظار منذ اللحظة التي أراد فيها router معيّن إرسال رسالة إلى أن تم تفريغ تلك الرسالة إلى مقبس الشبكة:

حوالي 95% من القيم تحت 50 مللي ثانية، لكن الارتفاعات المفاجئة قاتلة.

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

3) مكتبة التدفق

سيُتحقَّق الجزء الثاني من الالتفاف على tunnels المتعطلة جزئياً بفضل مكتبة البث، مما يمنحنا اتصالات بث من طرف إلى طرف أكثر متانة بكثير. هذه المناقشة ليست جديدة — فالمكتبة ستقوم بكل الأمور المبهرة التي نتحدث عنها منذ مدة (وطبعاً سيكون لها نصيبها من الأخطاء البرمجية). لقد تحقق الكثير من التقدم على هذا الصعيد، ومن المرجح أن التنفيذ قد وصل إلى نحو 60%.

سنوافيكم بالمزيد من الأخبار عندما تتوفر أخبار جديدة.

4) files.i2p

حسنًا، شهدنا في الآونة الأخيرة الكثير من eepsites(مواقع I2P) الجديدة، وهو أمر رائع جدًا. فقط أردت أن أشير إلى هذا على وجه الخصوص لأنه يقدّم ميزة لطيفة تفيدنا جميعًا. إن لم تزُر files.i2p، فهو أساسًا محرّك بحث شبيه بـGoogle، مع ذاكرة تخزين مؤقت للمواقع التي يزحف إليها (حتى تتمكّن من البحث والتصفّح عندما يكون eepsite(موقع I2P) غير متصل). رائع جدًا.

5) ???

ملاحظات الحالة لهذا الأسبوع موجزة إلى حد ما، لكن هناك الكثير مما يجري - - فقط لا أملك وقتًا لكتابة المزيد قبل الاجتماع. لذا، مرّ على #i2p بعد بضع دقائق ويمكننا مناقشة أي شيء فاتني بحماقة.

=jr