مرحباً جميعاً، عذرًا على التأخر…
فهرس:
- 0.4
- Capacity and overload
- Website updates
- I2PTunnel web interface
- Roadmap and todo
- ???
1) 0.4
كما أنا متأكد أنكم جميعاً قد رأيتم، فقد صدر إصدار 0.4 قبل أيام، وعموماً تسير الأمور بشكل جيد جداً. من الصعب تصديق أن ستة أشهر قد مضت منذ صدور 0.3 (وسنة منذ إطلاق حزمة تطوير البرمجيات (SDK) 1.0)، لكننا قطعنا شوطاً طويلاً، وعملكم الجاد وحماستكم وصبركم حققت نتائج مدهشة. تهانينا، وشكراً!
وكما هو الحال مع أي إصدار جيد، ما إن خرج إلى العلن حتى وجدنا بعض المشكلات، وعلى مدى الأيام القليلة الماضية كنا نجمع تقارير الأخطاء ونطبق التصحيحات بوتيرة محمومة (يمكنك متابعة التغييرات أثناء إصلاحها). لا تزال لدينا بضعة أخطاء أخرى ينبغي القضاء عليها قبل طرح المراجعة التالية، لكن يُفترض إنجاز ذلك خلال اليوم القادم أو نحو ذلك.
2) السعة والحمل الزائد
لقد شهدنا بعض التخصيصات غير المتوازنة إلى حد ما لـ tunnels خلال الإصدارات القليلة الماضية، ومع أن بعضها مرتبط بأخطاء برمجية (تم إصلاح اثنين منها منذ صدور 0.4)، لا يزال هناك سؤال عام يتعلق بالخوارزمية - متى ينبغي لـ router التوقف عن قبول المزيد من tunnels؟
قبل بضع مراجعات، أضفنا شفرة لتحديد المعدل لرفض الطلبات للمشاركة في tunnel إذا كان الـ router مُحمَّلًا بشكل زائد (زمن معالجة الرسائل المحلي يتجاوز 1 ثانية)، وقد ساعد ذلك بشكل كبير. ومع ذلك، هناك جانبان في تلك الخوارزمية البسيطة لم يُعالَجا: - عندما تكون سعة النطاق الترددي لدينا مشبعة، قد يظل زمن المعالجة المحلي سريعًا، لذا سنواصل قبول المزيد من طلبات الـ tunnel - عندما يشارك نظير واحد في “أكثر مما ينبغي” من الـ tunnels، فعندما تفشل، تتضرر الشبكة أكثر.
يُعالَج الإشكال الأول بسهولة نسبية بمجرد تفعيل مُقيِّد عرض النطاق الترددي (لأن تقييد عرض النطاق يبطئ زمن معالجة الرسائل بما يتوافق مع التأخير المرتبط بعرض النطاق). أما الإشكال الثاني فأكثر تعقيدًا، وهناك حاجة إلى مزيد من البحث والمحاكاة. أفكّر في شيء على غرار رفض طلبات tunnel على نحو احتمالي استنادًا إلى نسبة الـ tunnels التي نشارك فيها إلى الـ tunnels المطلوبة من الشبكة، بما في ذلك “kindness factor” أساسي، مع ضبط P(reject) = 0 إذا كنا نشارك في أقل من ذلك.
ولكن كما قلت، هناك حاجة إلى المزيد من العمل والمحاكاة.
3) تحديثات الموقع
الآن بعد أن أصبح لدينا واجهة الويب الجديدة الخاصة بـ I2P، فإن تقريبًا كل وثائق المستخدم النهائي القديمة لدينا أصبحت متقادمة. نحتاج إلى بعض المساعدة في مراجعة تلك الصفحات وتحديثها لوصف كيفية الحال الآن. وكما اقترح duck وآخرون، نحتاج إلى دليل ‘الانطلاق السريع’ جديد يتجاوز ملف readme على http://localhost:7657/ - شيئًا يساعد الناس على الانطلاق والدخول إلى النظام.
بالإضافة إلى ذلك، توفر واجهة الويب الجديدة لدينا مساحة واسعة لدمج مساعدة تعتمد على السياق. كما ترى في الملف المرفق help.jsp، “هممم. ربما ينبغي أن نضع نص مساعدة هنا.”
سيكون من الرائع على الأرجح لو أمكننا إضافة روابط ‘حول’ و/أو ‘استكشاف الأخطاء وإصلاحها’ إلى الصفحات المختلفة، تشرح ما تعنيه العناصر وكيفية استخدامها.
4) واجهة الويب لـ I2PTunnel
إن وصف الواجهة الجديدة http://localhost:7657/i2ptunnel/ بأنها “متقشفة” سيكون تقليلاً من شأن الأمر. نحتاج إلى القيام بالكثير من العمل للاقتراب بها من حالة قابلة للاستخدام - في الوقت الحالي، الوظائف موجودة من الناحية التقنية، لكنك تحتاج فعلاً إلى معرفة ما يجري خلف الكواليس لتتمكن من فهمها. أعتقد أن لدى duck بعض الأفكار الإضافية بشأن هذا الموضوع لطرحها خلال الاجتماع.
5) خارطة الطريق وقائمة المهام
كنت متهاونًا في إبقاء خارطة الطريق محدَّثة، لكن الحقيقة هي أن أمامنا مزيدًا من المراجعات. وللمساعدة في شرح ما أراه «مشكلات كبيرة»، أعددت قائمة مهام جديدة تتناول كل واحدة منها بشيء من التفصيل. أرى أنه ينبغي لنا في هذه المرحلة أن نكون منفتحين إلى حدّ كبير على مراجعة خياراتنا وربما إعادة صياغة خارطة الطريق.
هناك أمر واحد نسيت أن أذكره في تلك قائمة المهام، وهو أنه عند إضافة بروتوكول الاتصال خفيف الوزن، يمكننا تضمين (اختياري) الاكتشاف التلقائي لعنوان IP. قد يكون هذا ‘خطيراً’ (ولهذا سيكون اختيارياً)، لكنه سيقلل بشكل كبير من عدد طلبات الدعم التي نتلقاها :)
على أي حال، تلك القضايا المدرجة على قائمة المهام هي أمور خططنا لها لمختلف الإصدارات، وبالتأكيد لن تكون كلها في 1.0 أو حتى 2.0. لقد وضعت تصوّرًا لعدة خيارات مختلفة لترتيب الأولويات/الإصدارات، لكنني لست ملتزمًا بها بشكل نهائي بعد. ومع ذلك، إذا كان بإمكان الناس تحديد أمور كبيرة أخرى على الطريق، فسيكون ذلك محل تقدير كبير، إذ إن المشكلة غير المجدولة تكون دائمًا مزعجة للغاية.
6) ???
حسنًا، هذا كل ما لدي الآن (وهذا أمر جيد أيضًا، إذ يبدأ الاجتماع بعد بضع دقائق). زورونا على #i2p على irc.freenode.net، أو www.invisiblechat.com، أو irc.duck.i2p عند الساعة 9 مساءً بتوقيت غرينتش لمواصلة الدردشة.