مرحباً يا جماعة، حان وقت تحديث الحالة
فهرس:
- Net status
- Streaming lib
- 0.4.2
- Addressbook.py 0.3.1
- ???
1) حالة الشبكة
بعد فترة امتدت 2-3 أيام من الازدحام الشديد الأسبوع الماضي، عادت الشبكة إلى مسارها الصحيح (يرجّح أن ذلك بسبب توقفنا عن إجراء اختبارات الضغط على منفذ bittorrent ;)). لقد كانت الشبكة موثوقة إلى حد كبير منذ ذلك الحين - لدينا بالفعل عدد قليل من routers (أجهزة التوجيه) التي ظلت قيد التشغيل لمدة 30-40+ يومًا، لكن اتصالات IRC لا تزال تتعرض لبعض التعثرات العرضية. ومن ناحية أخرى…
2) Streaming lib (مكتبة التدفق)
خلال الأسبوع الماضي تقريباً، قمنا بإجراء المزيد من الاختبارات المباشرة لمكتبة البث على الشبكة، وكانت النتائج جيدة جداً. قام Duck بإعداد tunnel باستخدامها ليتمكن الناس من الوصول إلى خادوم IRC الخاص به، وعلى مدى بضعة أيام لم أتعرض سوى لانقطاعين غير ضروريين (مما ساعدنا على تتبّع بعض الأخطاء البرمجية). كما كان لدينا مثيل i2ptunnel موجّه إلى squid outproxy جرّبه الناس، وقد تحسّن معدل النقل وزمن الاستجابة والموثوقية بشكل ملحوظ مقارنةً بالمكتبة القديمة، التي اختبرناها جنباً إلى جنب.
عمومًا، تبدو مكتبة البث (streaming lib) في حالة جيدة بما يكفي للإصدار الأول. لا تزال هناك بعض الأمور غير المكتملة، لكنها تمثّل تحسّنًا كبيرًا مقارنة بالمكتبة القديمة، وعلينا أن نعطيك سببًا للترقية لاحقًا، أليس كذلك؟ ;)
في الواقع، فقط لإغاظتك (أو ربما لإلهامك لتبتكر بعض الحلول)، فإن أهم الأمور التي أراها قادمة لـ streaming lib (مكتبة البث/التدفق في I2P) هي: - بعض الخوارزميات لمشاركة معلومات الازدحام وRTT (زمن الذهاب والإياب) عبر التدفقات (لكل وجهة مستهدفة؟ لكل وجهة مصدر؟ لجميع الوجهات المحلية؟) - المزيد من التحسينات للتدفقات التفاعلية (يركز التنفيذ الحالي أساسًا على التدفقات كبيرة الحجم) - استخدام أكثر صراحةً لميزات streaming lib الجديدة في I2PTunnel، بما يقلل العبء الإضافي لكل tunnel. - تقييد عرض النطاق على مستوى العميل (على تدفق ما، في أحد الاتجاهين أو كليهما، أو ربما مشتركًا عبر عدة تدفقات). سيكون ذلك بالإضافة إلى تقييد عرض النطاق الإجمالي لدى router، بالطبع. - ضوابط متنوعة للوجهات لتقييد عدد التدفقات التي تقبلها أو تنشئها (لدينا بعض الشيفرة الأساسية، لكنها معطّلة إلى حد كبير) - قوائم التحكم في الوصول (السماح فقط بالتدفقات المتجهة إلى أو القادمة من وجهات أخرى معروفة معينة) - ضوابط عبر الويب ومراقبة صحة التدفقات المختلفة، بالإضافة إلى القدرة على إغلاقها صراحةً أو تقييدها
يمكنكم على الأرجح ابتكار أمور أخرى أيضاً، ولكن هذه مجرد قائمة مختصرة بالأشياء التي أرغب في رؤيتها في الـstreaming lib (مكتبة البث)، ولن أؤخر من أجلها إصدار 0.4.2. إذا كان أيٌّ منكم مهتماً بأيٍّ منها، رجاءً أخبروني!
3) 0.4.2
إذًا، إذا كانت streaming lib (مكتبة البث) في حالة جيدة، فمتى سنحصل على الإصدار؟ الخطة الحالية هي طرحه بحلول نهاية الأسبوع، وربما حتى غدًا. هناك بعض الأمور الأخرى الجارية التي أود ترتيبها أولًا، وبالطبع ينبغي اختبارها، وما إلى ذلك.
سيكون التغيير الكبير في إصدار 0.4.2 بالطبع هو مكتبة البث الجديدة. من منظور واجهة برمجة التطبيقات (API)، فهي مطابقة للمكتبة القديمة - تستخدمه تلقائيًا I2PTunnel وتدفقات SAM، ولكن من منظور الحزم، فهي غير متوافقة مع الإصدارات السابقة. يضعنا هذا أمام معضلة مثيرة للاهتمام - لا يوجد داخل I2P ما يفرض علينا جعل 0.4.2 ترقية إلزامية، غير أن الأشخاص الذين لا يقومون بالترقية لن يكونوا قادرين على استخدام I2PTunnel - لا eepsites(مواقع I2P)، ولا IRC، ولا outproxy، ولا بريد إلكتروني. لا أريد أن أنفّر مستخدمينا القدامى بإجبارهم على الترقية، لكنني أيضًا لا أريد أن أنفّرهم بأن يتعطّل كل ما هو مفيد ;)
أنا منفتح على الاقتناع بأي من الخيارين - سيكون من السهل بما يكفي تغيير سطر واحد من الكود بحيث لا يتواصل إصدار 0.4.2 مع الإصدارات الأقدم، أو يمكننا ترك الأمر كما هو وندع الناس يجرون الترقية كلما قصدوا الموقع أو المنتدى ليتذمّروا من أن كل شيء معطّل. ما رأيكم جميعًا؟
4) AddressBook.py 0.3.1
أصدر Ragnarok إصدار تصحيح جديد لتطبيق دفتر العناوين الخاص به - انظر http://ragnarok.i2p/ لمزيد من المعلومات (أو ربما يمكنه أن يزوّدنا بتحديث في الاجتماع؟)
5) ؟؟؟
أعلم أن هناك الكثير من النشاط يجري — مثل منفذ BitTorrent وsusimail وخدمة الاستضافة الجديدة لـ slacker، وغيرها من الأمور. هل لدى أي شخص أمور أخرى يود طرحها؟ إن كان الأمر كذلك، فمرّوا على الاجتماع بعد ~30 دقيقة في #i2p على خوادم IRC المعتادة!
=jr