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

فهرس:

قدّم الترجمة فقط، ولا شيء آخر:

  1. 0.4.1.1 status
  2. Pretty pictures
  3. 0.4.1.2 and 0.4.2
  4. Bundled eepserver
  5. ???

1) 0.4.1.1 الحالة

بعد إصدار 0.4.1 الوعِر إلى حد ما (والتحديث السريع اللاحق 0.4.1.1)، يبدو أن الشبكة عادت إلى الوضع الطبيعي - هناك نحو 50 نظيراً نشطاً في الوقت الراهن، وكلا من irc و eepsites(مواقع I2P) يمكن الوصول إليهما. كان معظم العناء ناتجاً عن عدم كفاية اختبار آلية النقل الجديدة خارج ظروف المختبر (مثلاً: تعطل المقابس في أوقات غريبة، تأخيرات مفرطة، إلخ). في المرة القادمة التي نحتاج فيها إلى إجراء تغييرات على تلك الطبقة، سنتأكد من اختبارها على نطاق أوسع قبل الإصدار.

2) صور جميلة

خلال الأيام القليلة الماضية كان هناك عدد كبير من التحديثات الجارية في CVS، وأحد الأمور الجديدة التي أضيفت كان مكوّنًا جديدًا لتسجيل الإحصاءات، مما يتيح لنا ببساطة استخراج البيانات الخام للإحصاءات أثناء توليدها، بدلاً من التعامل مع المتوسطات البدائية المجمّعة على /stats.jsp. وباستخدامه، كنت أراقب بعض الإحصاءات الرئيسية على بضعة routers (موجّهات)، ونحن نقترب من تتبّع مشكلات الاستقرار المتبقية. الإحصاءات الخام ضخمة إلى حد ما (تشغيل لمدة 20 ساعة على جهاز duck ولّد ما يقارب 60MB من البيانات)، لكن لهذا السبب لدينا رسوم بيانية جميلة - http://dev.i2p.net/~jrandom/stats/

المحور Y في معظم هذه الرسوم البيانية هو بالميلي ثانية، بينما المحور X بالثواني. هناك بعض الأمور الجديرة بالانتباه. أولاً، إن client.sendAckTime.webp يعطي تقريباً جيداً لزمن تأخير رحلة واحدة ذهاباً وإياباً، إذ تُرسل رسالة التأكيد (ack) مع الحمولة ثم تعود عبر المسار الكامل للـ tunnel؛ وبناءً على ذلك، كان زمن الرحلة ذهاباً وإياباً لمعظم الرسائل الناجحة البالغ عددها نحو 33,000 أقل من 10 ثوانٍ. إذا راجعنا بعد ذلك client.sendsPerFailure.webp إلى جانب client.sendAttemptAverage.webp، سنرى أن عمليات الإرسال الفاشلة البالغ عددها 563 قد أُعيدت محاولتها في الغالب حتى الحد الأقصى لعدد المحاولات الذي نسمح به (5 محاولات مع مهلة لينة لكل محاولة مدتها 10 ثوانٍ (soft timeout) ومهلة صارمة مدتها 60 ثانية (hard timeout))، بينما نجحت معظم المحاولات الأخرى من المحاولة الأولى أو الثانية.

صورة أخرى مثيرة للاهتمام هي client.timeout.webp التي تثير الكثير من الشكوك حول فرضية كانت لديّ - أن حالات فشل إرسال الرسائل كانت مرتبطة بنوع من الازدحام المحلي. تُظهر البيانات المرسومة أن استخدام عرض النطاق الترددي الوارد كان يتفاوت بشكل كبير عندما حدثت حالات الفشل، ولم تكن هناك قمم متسقة في زمن معالجة الإرسال المحلي، ولا يبدو أن هناك أي نمط على الإطلاق فيما يتعلق بكمون اختبار tunnel.

الملفان dbResponseTime.webp و dbResponseTime2.webp مشابهان لـ client.sendAckTime.webp، إلا أنهما يتوافقان مع رسائل netDb بدلاً من رسائل العميل من طرف إلى طرف.

تُظهر transport.sendMessageFailedLifetime.webp المدة التي نحتفظ فيها بالرسالة محلياً قبل إعلان فشلها لأي سببٍ ما (على سبيل المثال، بسبب بلوغ وقت انتهاء صلاحيتها أو عدم قابلية الوصول إلى النظير الذي تستهدفه). بعض حالات الفشل لا يمكن تجنّبها، لكن هذه الصورة تُظهر عدداً كبيراً يفشل مباشرةً بعد مهلة الإرسال المحلية (10 ثوانٍ). هناك بعض الأمور التي يمكننا القيام بها لمعالجة ذلك: - أولاً، يمكننا جعل القائمة السوداء أكثر تكيفاً- بزيادة أسّية لمدة حظر النظير بدلاً من مدة ثابتة قدرها 4 دقائق لكل نظير. (تم إدراج هذا بالفعل في CVS) - ثانياً، يمكننا إفشال الرسائل بشكل استباقي عندما يبدو أنها ستفشل على أي حال. للقيام بذلك، نجعل كل اتصال يتتبّع معدل الإرسال الخاص به، وكلما أضيفت رسالة جديدة إلى طابوره، إذا كان عدد البايتات المصطفّة بالفعل مقسوماً على معدل الإرسال يتجاوز الوقت المتبقي حتى انتهاء الصلاحية، نفشل الرسالة فوراً. قد نتمكّن أيضاً من استخدام هذا المقياس عند تحديد ما إذا كان ينبغي قبول أي طلبات tunnel إضافية عبر نظير.

على أي حال، ننتقل إلى الصورة الجميلة التالية - transport.sendProcessingTime.webp. فيها ترى أن هذا الجهاز تحديدًا نادرًا ما يكون مسؤولًا عن قدر كبير من التأخير - عادةً بين 10 و100 مللي ثانية، مع بعض الارتفاعات إلى ثانية واحدة أو أكثر.

كل نقطة مرسومة في tunnel.participatingMessagesProcessed.webp تمثل عدد الرسائل التي تم تمريرها عبر tunnel شارك فيها ذلك router. وبدمج ذلك مع متوسط حجم الرسالة نحصل على تقدير لحِمل الشبكة الذي يتحمله النظير لأجل الآخرين.

الصورة الأخيرة هي tunnel.testSuccessTime.webp، والتي تُظهر المدة اللازمة لإرسال رسالة عبر tunnel إلى الخارج ثم عودتها إلينا مرة أخرى عبر inbound tunnel آخر، مما يمنحنا تقديراً لمدى جودة الـ tunnels لدينا.

حسنًا، هذا يكفي من الصور الجميلة في الوقت الحالي. يمكنك توليد البيانات بنفسك باستخدام أي إصدار بعد 0.4.1.1-6 عبر ضبط خاصية إعداد router “stat.logFilters” لتكون قائمة بأسماء الإحصاءات مفصولة بفواصل (استخرج الأسماء من صفحة /stats.jsp). سيتم تفريغ ذلك في stats.log والذي يمكنك معالجته باستخدام

java -cp lib/i2p.jar net.i2p.stat.StatLogFilter stat.log

والذي يقسّمه إلى ملفات منفصلة لكل إحصائية، ما يجعلها ملائمة للاستيراد في أداتك المفضلة (مثل gnuplot).

3) 0.4.1.2 و 0.4.2

حدثت العديد من التحديثات منذ إصدار 0.4.1.1 (انظر السجلّ للاطلاع على القائمة الكاملة)، لكن لا توجد إصلاحات حرجة بعد. سنطرحها في الإصدار التصحيحي التالي 0.4.1.2 في وقت لاحق من هذا الأسبوع بعد معالجة بعض الأخطاء العالقة المتعلقة بالاكتشاف التلقائي لعناوين IP.

المهمة الرئيسية التالية في تلك المرحلة ستكون الوصول إلى 0.4.2، والذي من المقرر حالياً أن يكون إعادة هيكلة كبيرة لمعالجة tunnel. سيكون ذلك عملاً كثيراً، يتضمن مراجعة التشفير ومعالجة الرسائل وكذلك تجميع tunnel، لكنه بالغ الأهمية، إذ يمكن لمهاجمٍ بسهولةٍ نسبية أن يشنّ بعض الهجمات الإحصائية على tunnels حالياً (على سبيل المثال: predecessor مع ترتيب tunnel عشوائي أو حصاد netDb).

طرح dm مع ذلك سؤالاً عمّا إذا كان من المنطقي تنفيذ الـ streaming lib (مكتبة البث) أولاً (المخطط له حالياً في الإصدار 0.4.3). تكمن فائدة ذلك في أن الشبكة ستصبح أكثر موثوقية وستتمتع بمعدل نقل بيانات أفضل، مما يشجّع مطورين آخرين على الشروع في تطوير تطبيقات العميل. بعد تطبيق ذلك، سأتمكن حينها من العودة إلى إعادة تصميم الـ tunnel ومعالجة قضايا الأمان (غير المرئية للمستخدم).

من الناحية التقنية، المهمتان المخطط لهما للإصدارين 0.4.2 و0.4.3 مستقلتان عن بعضهما، وسيتم إنجازهما على أي حال، لذا لا يبدو أن هناك ضرراً كبيراً في تبديل ترتيبهما. أميل إلى موافقة dm، وما لم يتمكن أحد من تقديم أسباب للإبقاء على 0.4.2 كتحديث tunnel وعلى 0.4.3 كـ streaming lib (مكتبة البث)، فسنقوم بتبديلهما.

4) eepserver المضمّن

كما ذُكر في ملاحظات الإصدار 0.4.1، قمنا بتضمين البرمجيات والتهيئة اللازمة لتشغيل eepsite(I2P Site) مباشرة دون إعداد إضافي - يمكنك ببساطة وضع ملف في الدليل ./eepsite/docroot/ ومشاركة وجهة I2P الموجودة في وحدة تحكم router.

عاتبني بعض الأشخاص على حماسي لملفات ‎.war، إذ إن معظم التطبيقات — للأسف — تتطلب عملًا أكثر قليلًا من مجرد إسقاط ملف في الدليل ./eepsite/webapps/. لقد أعددت شرحًا موجزًا لتشغيل محرك التدوين blojsom، ويمكنك رؤية كيف يبدو ذلك على موقع detonate.

5) ???

هذا تقريبًا كل ما لدي في الوقت الحالي - مرّ على الاجتماع بعد 90 دقيقة إذا أردت مناقشة الأمور.

=jr