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

  • Index
  1. حالة الشبكة 2) 0.5 3) i2pmail.v2 4) azneti2p_0.2 5) ???
    1. Net status

هممم، لا جديد يُذكر هنا - الأمور لا تزال تعمل كما كانت في الأسبوع الماضي، وحجم الشبكة ما يزال مشابهًا إلى حد كبير، وربما أصبح أكبر قليلًا. بعض المواقع الجديدة الرائعة بدأت بالظهور - راجع المنتدى [1] و orion [2] للتفاصيل.

[1] http://forum.i2p.net/viewforum.php?f=16 [2] http://orion.i2p/

    1. 0.5

بفضل مساعدة postman وdox وfrosk وcervantes (وكل من مرّروا البيانات عبر routers الخاصة بهم ;))، جمعنا إحصاءات أحجام الرسائل ليوم كامل [3]. هناك مجموعتان من الإحصاءات - ارتفاع وعرض التكبير. وقد جاء ذلك بدافع الرغبة في استكشاف تأثير استراتيجيات حشو الرسائل المختلفة على الحمل على الشبكة، كما هو مبيّن [4] في إحدى مسودات توجيه tunnel 0.5. (ooOOoo صور جميلة).

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

[3] http://dev.i2p.net/~jrandom/messageSizes/ [4] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ tunnel.html?rev=HEAD#tunnel.padding

في الواقع، ذلك الرابط [4] يأخذنا إلى وضع خطط الإصدار 0.5 لتوجيه الـ tunnel. كما نشر Connelly [5]، كان هناك الكثير من النقاش مؤخراً على IRC حول بعض المسودات، مع مساهمة كل من polecat وbla وduck وnickster وdetonate وآخرين باقتراحات وأسئلة متعمقة (حسناً، وتعليقات لاذعة أيضاً ;). بعد أكثر بقليل من أسبوع، صادفنا ثغرة محتملة في [4] تتعلق بخصم تمكن بطريقة ما من الاستيلاء على بوابة الـ tunnel الوارد وكان أيضاً يسيطر على أحد النظراء الآخرين لاحقاً داخل ذلك الـ tunnel. ومع أن هذا بمفرده لن يكشف نقطة النهاية في معظم الحالات، وسيكون تحقيقه صعباً من الناحية الاحتمالية مع نمو الشبكة، فإنه يظل أمراً سيئاً جداً (tm).

وهنا يأتي دور [6]. هذا يتخلص من تلك المشكلة، ويتيح لنا إنشاء tunnels بأي طول، ويحلّ مشكلة الجوع العالمي [7]. لكنه يثير مشكلةً أخرى حيث يمكن لمهاجم أن يبني حلقات داخل tunnel، ولكن استناداً إلى اقتراح [8] قدّمه Taral العام الماضي بخصوص وسوم الجلسة المستخدمة في ElGamal/AES، يمكننا تقليل الضرر الناتج باستخدام سلسلة من مولدات الأعداد شبه العشوائية المتزامنة [9].

[5] http://dev.i2p.net/pipermail/i2p/2005-January/000557.html [6] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ tunnel-alt.html?rev=HEAD [7] خمّن أي عبارة غير صحيحة؟ [8] http://www.i2p.net/todo#sessionTag [9] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ tunnel-alt.html?rev=HEAD#tunnel.prng

لا تقلق إذا بدا ما سبق مربكًا - فأنت ترى خفايا بعض مشكلات التصميم الشائكة وهي تُعالج علنًا. إذا كان ما سبق لا يبدو مربكًا، يرجى التواصل معنا، فنحن دائمًا نبحث عن مزيد من العقول لمناقشة وتمحيص هذه الأمور :)

على أيّ حال، كما ذكرتُ في القائمة [10]، بعد ذلك أرغب في تنفيذ الاستراتيجية الثانية [6] لمعالجة التفاصيل المتبقية. الخطة لإصدار 0.5 حالياً هي جمع جميع التغييرات غير المتوافقة مع الإصدارات السابقة معاً - تشفير tunnel الجديد، إلخ - وإصدار ذلك كـ 0.5.0، ثم بعد أن يستقر ذلك على الشبكة، ننتقل إلى الأجزاء الأخرى من 0.5 [11]، مثل تعديل استراتيجية pooling (التجميع) كما هو موصوف في المقترحات، وإصدار ذلك كـ 0.5.1. آمل أن نتمكّن من الوصول إلى 0.5.0 بحلول نهاية الشهر، لكن سنرى.

[10] http://dev.i2p.net/pipermail/i2p/2005-January/000558.html [11] http://www.i2p.net/roadmap#0.5

    1. i2pmail.v2

قبل أيام، طرح postman مسودة خطة عمل للبنية التحتية للبريد من الجيل التالي [12]، وتبدو رائعة بحق. بالطبع، هناك دائمًا المزيد من الميزات الإضافية التي يمكن أن نحلم بها، لكنها تتمتع بمعمارية جيدة جدًا من نواحٍ عديدة. اطّلع على ما تم توثيقه حتى الآن [13]، وتواصل مع postman بآرائك!

[12] http://forum.i2p.net/viewtopic.php?t=259 [13] http://www.postman.i2p/mailv2.html

    1. azneti2p_0.2

كما نشرتُ في القائمة [14]، كان المُلحق azneti2p الأصلي لِـazureus يحتوي على خلل خطير في إخفاء الهوية. كانت المشكلة أنه في تورنتات مختلطة يكون بعض المستخدمين مجهولين وآخرون غير ذلك، كان المستخدمون المجهولون يتواصلون مع المستخدمين غير المجهولين /مباشرةً/ لا عبر I2P. كان Paul Gardner وبقية مطوري azureus متجاوبين للغاية وأصدروا تصحيحاً على الفور. المشكلة التي رأيتها لم تعد موجودة في azureus v. 2203-b12 + azneti2p_0.2.

لم نقم بعد بمراجعة الشيفرة وتدقيقها لرصد أي مشكلات محتملة تتعلق بإخفاء الهوية، لذا فالاستخدام على مسؤوليتك الخاصة (ومن ناحية أخرى، نقول الشيء نفسه عن I2P قبل إصدار 1.0). إذا كنت مستعدًا لذلك، فأنا أعلم أن مطوري Azureus سيقدّرون الحصول على مزيد من الملاحظات وتقارير الأخطاء المتعلقة بالملحق. سنبقي الجميع على اطلاع بالطبع إذا اكتشفنا أي مشكلات أخرى.

[14] http://dev.i2p.net/pipermail/i2p/2005-January/000553.html

    1. ???

هناك الكثير مما يجري، كما ترى. أظن أن هذا تقريباً كل ما لدي لأطرحه، لكن يرجى الانضمام إلى الاجتماع بعد 40 دقيقة إذا كان هناك شيء آخر تود مناقشته (أو إذا كنت تريد فقط التذمر بشأن المذكور أعلاه)

=jr