اجتماع مطوري I2P - 25 أبريل 2005

16:12 <jrandom> 0) مرحباً 16:12 <jrandom> 1) حالة الشبكة و 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) مرحباً 16:13 * jrandom يلوّح 16:13 <@cervantes> هلا 16:13 <jrandom> ملاحظات الحالة الأسبوعية منشورة على @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 16:14 <jrandom> بينما تلقون نظرة سريعة على ذلك، دعونا ننتقل إلى 1) حالة الشبكة 16:14 <jrandom> إذن، كما رأى معظمكم، لدينا إصدار جديد، وحتى الآن، النتائج إيجابية جدًا 16:15 <@cervantes> (ياي!) 16:15 <jrandom> لسنا بعد حيث نريد، لكنها تعالج إلى حدٍ كبير القضايا الرئيسية التي كنا نراها 16:15 <jrandom> نعم، من الجميل أن نحصل مجددًا على معدلات بناء tunnels مقبولة إلى حدٍ ما، عند tunnels من 2+ قفزة :) 16:16 * jrandom يمتلك معدلات نجاح 50%+ على router آخر مع tunnels بقفزة واحدة 16:17 <jrandom> أعتقد أن التغييرات القليلة الأخيرة في 0.6.1.17 ينبغي أن تساعد أيضًا في تجنّب هذا النوع من انهيار الازدحام مستقبلًا 16:17 <jrandom> أما النتيجة الملموسة للمستخدم فهي أننا سنرى أحيانًا انتهاء صلاحية lease، ولكن بدلًا من أن تتفاقم المشكلة، ستتراجع 16:17 * cervantes يشغّل azureus 16:18 <+Complication> سجّلت هذا الصباح معدلات نجاح client tunnel (بطول 2 +/- 1) تقارب 35% 16:18 <+Complication> حاليًا هي أقل، إذ جرّبت إجراء بعض التعديلات، وكان آخرها غير جيّد :D 16:18 <@cervantes> jrandom: أحسنت تتبّع ذلك — بدأنا نبدو مثل freenet لبعض الوقت :) 16:19 <jrandom> *سعال* ;) 16:20 <+fox> <inkeystring> jrandom: هل تمانع في وصف آلية التراجع (backoff) بإيجاز؟ أنا أعمل على شيء من هذا القبيل لـ freenet 0.7 في الوقت الحالي 16:21 <jrandom> inkeystring: لدينا آلية تراجع على طبقة النقل لخفض الإرسال إلى نظير عندما تكون طبقة النقل مثقلة، لكن ذلك لم يكن كافيًا 16:21 <@cervantes> *سعال* هل قلت freenet، قصدت tor 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: التغيير الجديد كان ترقية ذلك إلى مستوى أعلى بحيث نتوقف عن محاولة بناء tunnels عندما تُشبَع طبقة الاتصال لدينا 16:22 <jrandom> (بدلًا من إرسال مزيد من محاولات بناء tunnel) 16:22 <+fox> <inkeystring> شكرًا — هل تقوم طبقة النقل بالتراجع فقط عند فقدان الرزم، أم أن هناك طريقة للمستقبِل للتحكم في التدفق؟ 16:23 * jrandom يبدو أنه يتذكر مناقشة تأثير الازدحام مقابل التوجيه مع toad عدة مرات (على irc و flog القديمة لدي)، رغم أنني لا أتذكر أي حل إيجابي للشبكة :/ 16:23 <jrandom> بإمكان المستقبِل إرسال NACK (سالب الإقرار)، ولدينا نقاط تكامل لـ ECN (إشعار الازدحام الصريح)، لكنها لم تكن ضرورية 16:23 <+fox> <inkeystring> نعم عاد الجدل على freenet-dev :-) لا حل سحري بعد 16:24 <+fox> <inkeystring> رائع، شكرًا على المعلومات 16:24 <+Complication> هم يستخدمون UDP هذه الأيام أيضًا، أليس كذلك؟ 16:24 <jrandom> حاليًا، يواجه النظراء المزدحمون بشدة مشاكل ليس مع الحدّ لكل نظير، بل مع اتساع نطاق اتصال النظراء 16:24 <+Complication> (كبروتوكول نقل) 16:24 <+fox> <inkeystring> الاتساع = عدد النظراء؟ 16:24 <jrandom> نعم 16:25 <jrandom> مع ارتفاع معدلات نجاح tunnel، لم يعد على النظراء التحدث إلى مئات النظراء فقط من أجل بناء tunnel 16:25 <jrandom> لذا يمكنهم الاكتفاء بـ 20-30 نظيرًا فقط 16:25 <jrandom> (أي النظراء المتصلون مباشرة) 16:26 <+fox> <inkeystring> أظن أن هذه أخبار جيدة لـ NAT hole punching وإشارات الإبقاء حيًا (keepalives) وغير ذلك؟ 16:26 <jrandom> ومن ناحية أخرى، مع 2-300 اتصال SSU نشِط، فإن وصلة بسرعة 6KBps ستواجه مشاكل 16:26 <jrandom> نعم 16:26 <+fox> <inkeystring> Complication: نعم 16:27 <+fox> <inkeystring> (في نسخة 0.7 ألفا) 16:27 <+Complication> آها، إذن هم على الأرجح يواجهون أمورًا مشابهة 16:27 <+Complication> آمل أن يجد أحدهم الحل السحري :D 16:27 <jrandom> لكن بطريقة مختلفة. طبقة النقل مسألة سهلة نسبيًا 16:27 <+fox> <inkeystring> أظنهم ربما أعادوا استخدام بعض شيفرة SSU... أو على الأقل تحدثوا عن ذلك 16:27 <jrandom> (أي أنها دُرست جيدًا منذ أكثر من 30 عامًا) 16:28 <jrandom> لكن موازنة الحمل في i2p (و freenet) تعمل على مستوى أعلى من الروابط نقطة-إلى-نقطة، ولها متطلبات مختلفة 16:28 <+fox> <inkeystring> نعم، التفاعل مع التوجيه هو الجزء المعقد 16:29 <jrandom> نعم، رغم أن i2p وضعها أسهل (لا نحتاج إلى العثور على نظراء محددين لديهم البيانات المعنية، بل أي شخص لديه قدرة على المشاركة في tunnels لدينا) 16:30 <+fox> <inkeystring> لذا لا يوجد فقدان في الكفاءة إذا تجنّبت نظيرًا مثقلًا... 16:30 <+fox> <inkeystring> بينما في freenet، قد يزيد التوجيه حول نظير مثقل من طول المسار 16:30 <+fox> <inkeystring> على أي حال آسف على الخروج عن الموضوع 16:31 <jrandom> لا مشكلة، رغم أن شرح سبب تأثير تغييرات 0.6.1.17 على انهيار الازدحام لدينا كان ذا صلة :) 16:31 <jrandom> حسنًا، هل لدى أحدٍ آخر شيء لـ 1) حالة الشبكة؟ 16:32 <+Complication> كما ذكرت من قبل، أثناء تشغيل .17 الصِرف، لاحظت دورية ملحوظة في عرض الحزمة والنظراء النشِطين 16:32 <+Complication> ويبدو أن بضعة أشخاص آخرين يواجهون ذلك أيضًا، رغم أنني لا أدري مدى شيوعه 16:33 <+Complication> كنت أتساءل عن أسبابه الأساسية، خصوصًا من منظور ضبط معدّل tunnel (throttling)، لكن لا حل حتى الآن 16:33 <+Complication> تمكنت من جعل الرسوم البيانية لدي أكثر تسطّحًا، لكن ذلك كان على حساب بعض التدهور العام 16:33 <+Complication> جرّبت تعديلات مثل: 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (كان هذا لتجنّب امتناعه تمامًا عن محاولات البناء لـ tunnels الخاصة به) 16:35 <jrandom> آه صحيح 16:35 <+Complication> (أوه، وطبعًا مستوى التسجيل loglevel مجنون، لأنني غيّرت ذلك لأغراض الاختبار) 16:35 <jrandom> لدينا بعض الشيفرة هناك تحاول إزاحة الدورية قليلًا، لكنها لا تعمل بشكل صحيح تمامًا (من الواضح) 16:36 * perv قضى للتوّ على نظامه :( 16:36 <+Complication> لكنني جرّبت أشياء من هذا النوع، وحاولت تقليل عامل النمو لعدد tunnels 16:36 <perv> هل هناك undelete لـ reiser4؟ 16:36 <jrandom> باختصار، إذا تصرّفنا كما لو أن tunnels تنتهي صلاحيتها (عشوائيًا) أبكر مما تفعل فعليًا، فمن المفترض أن يساعد ذلك 16:36 <+Complication> أقرأ حاليًا الدالة الكبيرة "countHowManyToBuild" في TunnelPool.java :D 16:36 <+Complication> لكنني لم أقرأها بالكامل بعد 16:37 <jrandom> (مع أنه سيزيد بوضوح من وتيرة بناء tunnel، وهو ما قبل 0.6.1.17 لم يكن معقولًا) 16:37 <+Complication> perv: هناك شيء 16:37 <jrandom> هممم، إدخال عشوائية هناك سيكون صعبًا يا Complication، لأننا نستدعي تلك الدالة بشكل متكرر جدًا 16:38 * perv يفكر في الإنقاذ والانتقال إلى gentoo 16:38 <jrandom> ما أوصي به هو النظر في عشوائية وقت انتهاء صلاحية tunnels التي بُنيت بنجاح 16:38 <+Complication> perv: أنت أفضل حالًا مع reiser من ext3 بالتأكيد 16:38 <+Complication> perv: لكنني لا أحفظ ذلك عن ظهر قلب 16:38 <+Complication> jrandom: صحيح، قد يُبالغ في البناء بهذه الطريقة أحيانًا 16:38 <jrandom> (بحيث يظن countHowManyToBuild الحالي أنه يحتاجها قبل أن يحتاجها فعليًا) 16:38 <+Complication> (وأحيانًا يُبالغ في البناء حتمًا، عندما تتعطّل tunnels ويصبح متعجّلًا) 16:40 <+Complication> هممم، احتمال لم أضعه في الحسبان... 16:41 <+Complication> على أي حال، أعبث به أنا أيضًا، ولا ملاحظات مفيدة بعد 16:42 <jrandom> جميل، لدي بعض التعديلات التي أعمل عليها في هذا، ربما يمكننا تجميعها للبناء التالي لمعرفة كيف تعمل على شبكة قابلة للعمل بشكل معقول ;) 16:43 <spinky> هل هناك إحصائية يمكنك من خلالها رؤية مقدار الـ overhead الذي تضيفه شبكة i2p إلى بيانات التطبيق؟ 16:43 <jrandom> "overhead" مصطلح محمّل بالدلالات... ;) 16:43 <jrandom> نسمّيه تكلفة المجهولية ;) 16:43 <spinky> ههه 16:45 <jrandom> (أي لا حقًا. حمولة طبقة التطبيق على شبكة مثالية مع 0 ازدحام و 1+1hops تحقق نحو 70-80% كفاءة للطرفين) 16:45 <jrandom> ((آخر مرة قست ذلك)) 16:45 <jrandom> لكن تلك ظروف مختبرية فعلاً 16:45 <jrandom> الشبكة الحية أعقد بكثير 16:47 <spinky> صحيح، قصدت فقط مقدار البيانات الإضافية المستخدمة لإعداد tunnels والمفاتيح والحشو وغير ذلك 16:47 <spinky> ... مقارنة ببيانات التطبيق المنقولة 16:47 <jrandom> يعتمد ذلك على تشكيل الرسائل، والازدحام، ومعدلات نجاح بناء tunnel، إلخ 16:48 <jrandom> يمكن للشبكة أن تتحمّل 20KB لبناء tunnel من قفزتين 16:48 <+Complication> كنت أرغب في اختبار ذلك أحيانًا، بهدف أساسي هو تقدير «الهدر» في تطبيقات النقل الجماعي مثل BitTorrent و I2Phex 16:48 <+Complication> لكنني لم أجد وقتًا لإجراء قياس نظيف بين عقدتيّ 16:48 <+Complication> يومًا ما سأعود إلى ذلك، على أية حال 16:49 <jrandom> Complication: الأمر صعب جدًا مع التطبيقات كثيرة الكلام، وأسهل بكثير قياس wget :) 16:49 <+Complication> صحيح تمامًا 16:50 <+Complication> فيما تمكنت من تجربته، لم يكن هناك أي شَبَهٍ بالدقة 16:54 <jrandom> حسنًا، إن لم يكن هناك شيء آخر في 1)، فلننتقل إلى 2) I2Phex 16:55 <jrandom> Complication: ماذا تفعل هذه الأيام؟ :) 16:55 <+Complication> حسنًا، كان التزام الأمس إصلاحًا لبعض المشاكل التي واجهها بعض الناس مع كاشف أول تشغيل السخيف خاصتي 16:56 <+Complication> كاشف أول تشغيل بات الآن أقل سخفًا، وقد أفاد bar بأنه بدا وكأنه بدأ يتصرف طبيعيًا 16:56 <+Complication> ومع ذلك، بما أن I2Phex يبدو قابلاً للتشغيل بالفعل في ظروف الشبكة الحالية، 16:56 <+Complication> سأحاول العثور على علة إعادة التهشير (rehash) أيضًا. 16:57 <+Complication> إن استطعت 16:57 <jrandom> جميل، أعلم أن تلك تطاردك منذ أشهر الآن 16:57 <+Complication> المثير للاهتمام أن Phex الرئيسي قد يعاني منها أيضًا، وسأحاول كذلك العثور على ملاحظاتهم وقراءتها 16:58 <jrandom> لكن من الجيد سماع أن إصلاح بدء التشغيل موجود 16:58 <jrandom> آه تمام 16:58 <+Complication> = أي أن 16:58 <+Complication> لا أستطيع تأكيد إن كان Phex الرئيسي لديه المشكلة أم لا حاليًا — لم أرها شخصيًا هناك 16:59 <jrandom> (علل متقطعة)-- 16:59 <+Complication> من الصعب التسبب بها بطريقة مضبوطة، وبالتالي يصعب العثور عليها 17:00 <+Complication> وعلى جانبي، هذا تقريبًا كل شيء حاليًا 17:00 <+Complication> لاحقًا، كنت أتساءل إن كان من المجدي تحديد عدد محاولات الاتصال بالنظراء المتوازية التي يُطلقها I2Phex في وقت واحد 17:01 <jrandom> نعم، على الأرجح 17:01 <+Complication> لأنها ستنشئ عددًا كبيرًا من استعلامات NetDB في وقت قصير، وقد لا يكون ذلك لطيفًا من منظور I2P router 17:02 <jrandom> كما أن جهات الاتصال الوجهة الجديدة تتطلب elG بدلًا من aes 17:02 <+Complication> لكنني لم أقرأ أو أكتب أي شيفرة فعلية نحو ذلك الهدف بعد 17:04 <jrandom> حسنًا لا بأس. ربما يُضمّن الدمج الأسطوري بين i2phex/phex حلًا :) 17:04 <+Complication> وعلى صعيدي، هذا كل ما في جعبة أخبار I2Phex تقريبًا... 17:04 <jrandom> جميل، شكرًا على التحديث وعلى الجهد في البحث في الأمور! 17:05 <jrandom> حسنًا، دعونا ننتقل إلى 3) ??? 17:05 <jrandom> هل لدى أحد أي شيء آخر لطرحه في الاجتماع؟ 17:05 <lsmith> مرحبًا! أود فقط أن أشيد بالمطورين على التحسينات الرائعة في الإصدار الأخير، إجمالي عرض الحزمة لدي يقرأ 0.9/1.4 KBps وما زلت متصلًا بـ irc... هذا... رائع بجنون :) 17:05 <+Complication> :D 17:06 <jrandom> شكرًا على صبركم طوال الطريق — دعم مستخدمي عرض الحزمة المنخفض أمر حاسم 17:06 <@cervantes> lsmith: هذا جيد حقًا أن 17:06 <@cervantes> * تم إعادة ضبط الاتصال 17:06 <jrandom> هه 17:07 <lsmith> :) 17:09 <jrandom> أوه، أمر آخر جدير بالذكر هو أن zzz عاد، ومعه يأتي stats.i2p :) 17:09 <jrandom> [wewt] 17:11 <+Complication> مصدر مفيد جدًا لبيانات المقارنة :) 17:11 <jrandom> أكيد تمامًا 17:11 <jrandom> حسنًا، هل لدى أحد أي شيء آخر للاجتماع؟ 17:13 <jrandom> إن لم يكن... 17:13 <jdot> لدي سؤال أو اثنان بعد الـ baf 17:13 <jrandom> هه حسنًا، إذن لنُشغّل الـ baffer :) 17:13 * jrandom يستعد... 17:13 * jrandom يُنهي الاجتماع بـ *baf*