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

الفهرس:

  1. 0.3.3 & current updates
  2. NativeBigInteger
  3. ???

1) 0.3.3

أصدرنا الإصدار 0.3.3 يوم الجمعة الماضي، وبعد يوم أو يومين من بعض التقلبات، يبدو أنه يعمل على نحو جيد. ليس بجودة 0.3.2.3، لكني عادةً ما كنت أستطيع البقاء على irc.duck.i2p لفترات تتراوح بين ساعتين وسبع ساعات. ومع ذلك، وبما أنني رأيت كثيرين يواجهون مشكلات، شغّلت أداة التسجيل وراقبتُ بالتفصيل ما يجري. الخلاصة هي أننا كنا ببساطة نستخدم نطاقاً ترددياً أكبر مما نحتاج إليه، مما تسبب في ازدحام وإخفاقات في الـ tunnel (بسبب انتهاء مهلة رسائل الاختبار، إلخ).

لقد قضيت الأيام القليلة الماضية مجدداً في المحاكي، أقوم بتشغيل سلسلة من heartbeats (رسائل نبض دورية) عبر شبكة لمعرفة ما يمكننا تحسينه، ولدينا مجموعة كبيرة من التحديثات في الطريق بناءً على ذلك:

netDb update to operate more efficiently

رسائل الاستعلام الحالية في netDb يصل حجمها إلى 10+KB، ومع أن الردود الناجحة شائعة، فإن الردود غير الناجحة قد تصل إلى 30+KB (لأن كليهما احتوى على هياكل RouterInfo كاملة). يستبدل netDb الجديد تلك هياكل RouterInfo الكاملة بـ hash الخاص بالـ router - محولاً رسائل 10KB و 30KB إلى رسائل بحجم ~100 بايت.

throw out the SourceRouteBlock and SourceRouteReplyMessage

كانت هذه الهياكل بقايا لفكرة قديمة، لكنها لا تضيف أي قيمة إلى إخفاء الهوية أو أمان النظام. وبالتخلي عنها لصالح مجموعة أبسط من نقاط بيانات الرد، قلّصنا أحجام رسائل إدارة tunnel بشكل كبير، وخفّضنا زمن garlic encryption إلى النصف.

تحديث netDb ليعمل بكفاءة أعلى

كانت الشيفرة ‘ثرثارة’ قليلًا أثناء إنشاء الـ tunnel، لذلك تمت إزالة الرسائل غير الضرورية.

استبعد SourceRouteBlock و SourceRouteReplyMessage

كان جزءٌ من شيفرة التشفير الخاصة بـgarlic routing (آلية التوجيه Garlic) يستخدم حشواً ثابتاً استناداً إلى بعض تقنيات garlic routing التي لا نستخدمها (عندما كتبتها في سبتمبر وأكتوبر، ظننت أننا سنقوم بتنفيذ garlic routing متعدد القفزات بدلاً من tunnels).

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

كما ترى في خارطة الطريق، فإن هذا يشمل جزءًا كبيرًا من إصدار 0.4.1، ولكن بما أن تغيير netDb أدى إلى فقدان التوافق مع الإصدارات السابقة، فمن الأفضل أن نُنجز مجموعة كبيرة من الأمور غير المتوافقة مع الإصدارات السابقة مرةً واحدة.

ما زلتُ أجري اختبارات في المُحاكي، ويجب أن أرى إن كان بإمكاني إنهاء موضوع per-hop tunnel id (معرّف tunnel لكل قفزة)، لكني آمل أن أطرح إصداراً تصحيحياً جديداً خلال يوم أو يومين. لن يكون متوافقاً مع الإصدارات السابقة، لذا ستكون الترقية غير سلسة، لكنه ينبغي أن يكون مستحقاً للعناء.

2) NativeBigInteger

لقد قام Iakin ببعض التحديثات على شيفرة NativeBigInteger لفريق Freenet، حيث حسّن بعض الأجزاء التي لا نستخدمها، كما أعدّ أيضًا بعض شفرة اكتشاف وحدة المعالجة المركزية (CPU detection code) التي يمكننا استخدامها لاختيار المكتبة الأصلية (native library) المناسبة تلقائيًا. هذا يعني أننا سنتمكن من نشر jbigi ضمن مكتبة واحدة في التثبيت الافتراضي، وستختار المكتبة المناسبة دون الحاجة إلى سؤال المستخدم عن أي شيء. كما وافق على إتاحة تعديلاته وشفرة اكتشاف وحدة المعالجة المركزية الجديدة حتى نتمكن من تضمينها في الشيفرة المصدرية لدينا (يا للروعة يا Iakin!). لست متأكدًا من موعد نشر ذلك، لكنني سأبلغ الجميع عند حدوثه، إذ إن من لديهم مكتبات jbigi الحالية سيحتاجون على الأرجح إلى واحدة جديدة.

3) ???

حسنًا، كان الأسبوع الماضي انشغالًا مكثفًا بالعمل على الكود، لذا لا توجد تحديثات كثيرة. هل لدى أي شخص شيء آخر يود طرحه؟ إن كان كذلك، تفضلوا بالانضمام إلى الاجتماع الليلة، الساعة 9 مساءً بتوقيت غرينتش في #i2p.

=jr