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

16:09 <jrandom> 0) مرحباً 16:09 <jrandom> 1) حالة الشبكة والإصدار 0.6.1.16 16:09 <jrandom> 2) إنشاء tunnel والازدحام 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) مرحباً 16:10 * jrandom يلوّح 16:10 <jrandom> ملاحظات الحالة الأسبوعية منشورة على http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk أيضاً 16:10 <jrandom> (قبل الاجتماع بساعتين تقريباً *قبل* الاجتماع أيضاً :) 16:11 <jrandom> حسناً، بما أنني متأكد من أنكم قد غصتم في الملاحظات، فلنبدأ بـ 1) حالة الشبكة 16:12 <+Complication> مرحباً :) 16:12 * Complication يلتقط الملاحظات بسرعة 16:12 <jrandom> إصدار 0.6.1.16 أصلح عِلّة قديمة جداً في الـ prng (مولِّد أعداد عشوائية زائف) لدينا، والتي تسببت في عدد كبير من عمليات رفض tunnel العشوائية 16:13 <jrandom> (السبب الجذري أُدخل في أكتوبر الماضي، ولكنه أُصلح الآن) 16:13 <+Complication> الحالة عندي: يعمل بشكل مقبول مع أنفاق tunnel بعدد قفزات 1 + 0..1، ولا يتصرف جيداً مع 2 + 0..1 أو 2 +/- 0..1 16:14 <jrandom> أجل، هذا مفهوم أيضاً، خصوصاً على الروابط الأبطأ 16:14 <jrandom> (للأسف، «الأبطأ» ليست بطيئة جداً أيضاً) 16:15 <jrandom> ما يزال هناك الكثير لنفعله، و0.6.1.16 ليس حيث نريد أن نكون، لكنه تقدم 16:17 <+Complication> هناك أمر كنت أفكر فيه، بخصوص ما سمّيته «انهيار الازدحام» 16:18 <+Complication> إحدى الطرق للحد من أثره قد تكون بأن نُلزِم فعلياً router بقبول حصة معيّنة من طلبات المشاركة 16:19 <+Complication> (شيء يحدده المستخدم بشكل مباشر أو غير مباشر؟) 16:19 <jrandom> يحدده أي مستخدم؟ 16:19 <+Complication> (مثلاً كجزء من نسبة المشاركة أو معلمة إضافية) 16:19 <jrandom> المستخدم المحلي، أم نحن كمستخدمين بعيدين؟ 16:19 <+Complication> يحدده كل شخص لنفسه 16:19 <@frosk> هل ننتقل إلى 2) إذن؟ :) 16:20 <jrandom> أجل، لنفترض أننا على 2) :) 16:20 <+Complication> حتى أستطيع، على سبيل المثال، أن أقول لـ router الخاص بي: «حتى لو كنتَ مزدحماً، استمر في التوجيه بحد أدنى 4 KB/s» 16:21 <jrandom> Complication: هذا غير ممكن فعلاً — إذا كان router مزدحماً جداً، فسيتوقف الآخرون (نأمل ;) عن طلب مشاركته في tunnels. 16:21 <+Complication> (هذا سيعني بالطبع أن بعض الوجهات المحلية قد تبقى غير متصلة مدة أطول) 16:21 <jrandom> وإن لم يُطلب منهم ذلك، فلن /يستطيعوا/ دفع بيانات الآخرين 16:22 <+Complication> آه، ربما كان ينبغي أن أصوغها بوضوح أكبر بكثير 16:24 <+Complication> تخيلت أنه يمكن، ضمن حصة معيّنة من حركة المرور المشاركة، أن يقيّد رسائل إنشاء tunnel الخاصة به بدلاً من تقييد tunnels المشاركة 16:24 <+Complication> مثلاً: «لن أخنق tunnels المشاركة عندي لأقل من 4 KB/s. إذا لزم الأمر، سأقيّد بدلاً من ذلك حركة المرور الخاصة بي.» 16:26 <jrandom> همم، هناك مخاطر على الخصوصية في ذلك (وإن كانت على نفس نمط هجمات الحرمان من الخدمة الانتقائية DoS، والتي لا ندافع ضدها على أي حال) 16:27 <jrandom> لكن تقييد عمليات بناء tunnel المحلية لدينا عند مواجهة الازدحام هو شيء أعمل على اختباره الآن — إضافة دعم لتجاهل حد 4KBps اختيارياً يجب أن تكون بسيطة بما يكفي 16:28 <spinky> حالياً، لا تحصل على أي حركة غطاء (cover traffic) إطلاقاً عند نقل الكثير من البيانات. 16:29 <spinky> وجود حد أدنى لعرض النطاق الخاص بالمشاركة يبدو جيداً. 16:30 <jrandom> حسناً، لدينا حد أدنى (كِلاهما عبر نسبة المشاركة واحتياطي داخلي قدره 4KBps بعد تخصيص كل عرض النطاق) 16:30 <+Complication> تباً، انقطاعات... آمل ألا يكون قد فُقد الكثير مما قلتُه، لكنني سأقرأ أي ردود من السجل :) 16:32 <@frosk> هل هناك شيء ذو دلالة بشأن 4KBps؟ 16:33 <jrandom> بضعة أمور — 4KB ~= sizeof(tunnel create message)، ومن الناحية التجريبية لم أسمع قط عن router يعمل بنجاح على أقل من ذلك 16:33 <spinky> ربما هي العِلل التي تمنع نسبة المشاركة من العمل إذن؟ 16:34 <jrandom> ما الذي يجعلك تقول إن نسبة المشاركة لا تعمل؟ 16:34 <@frosk> أفهم 16:34 <+Complication> frosk: لا، إنه مجرد رقم في الشيفرة الحالية، وقد أشرتُ إليه وأنا أحاول شرح ما تخيلته أيضاً 16:35 <+Complication> (ليس لأسباب ذات معنى، فقط لأن ما تخيلته كان، بطريقة ما، المعكوس المكافئ له) 16:35 <spinky> إنها مضبوطة على 80% وتنخفض المشاركة إلى 0 عند توليد بيانات محلياً. ربما أسأتُ الفهم. 16:36 <jrandom> آه، نعم، هذه ليست وظيفة نسبة المشاركة 16:36 <+Complication> spinky: إنها حد أقصى لما يمكن مشاركته، رهناً بعرض النطاق المتاح فعلياً للمشاركة 16:37 <+Complication> إذا استهلكت الحركة المحلية 70%، فسيبقى لديك 10% فقط للمشاركة 16:37 <+Complication> إذا كانت الحركة المحلية كثيفة، سيبقى لديك 0%، ولن يُلامس الحد الأعلى 80% مطلقاً 16:37 <spinky> حسناً. أرى أنها تقول 'up to'... 16:38 <+Complication> وهناك أيضاً الاحتياطي 4 KB/s 16:38 <jrandom> آه، إنها نسبة مشاركة من المتاح لديك 16:38 <spinky> ربما إعداد آخر للحد الأدنى لعرض النطاق الخاص بالمشاركة، بحيث يقبل router مزيداً من tunnels دونه؟ 16:38 <jrandom> إذا كنتَ تستخدم 95% من عرض النطاق لديك، فسيُشارك بما يصل إلى 80% من الـ 5% المتبقية 16:39 <+Complication> أوه، إذن لقد أسأتُ فهمه جزئياً أنا أيضاً 16:40 <fox> <zorglu1> كيف يقيس i2p مقدار عرض النطاق الذي تستخدمه التطبيقات المحلية الأخرى ؟ 16:40 <spinky> (أقول فقط: إذا كنت تعتبر cover traffic أمراً جيداً فربما جعلها قابلة للضبط حتى أثناء الاستخدام المحلي الكثيف لعرض النطاق يكون أمراً جيداً) 16:40 <+Complication> ظننتُ أنها تُطبَّق مقابل الحد المستدام 16:40 <jrandom> zorglu1: يقيس i2p استخدامه لعرض النطاق، ويعرف حدود عرض النطاق الخاصة بـ i2p 16:41 <jrandom> أوه، همم، بالنظر إلى الشيفرة: int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> إذن أنتَ محق يا Complication 16:42 <jrandom> spinky: إن cover traffic مفيد إلى حدٍّ ما فقط على شبكة خلط منخفضة الكمون (mixnet) 16:42 <jrandom> إنه يضيف بعض الحوافز لـ routers ذات عرض النطاق الأعلى، لكن الذين ليست لديهم سعة فائضة من عرض النطاق فخياراتهم محدودة 16:49 <jrandom> على أي حال، مشكلة ازدحام tunnel موجودة منذ فترة، لكنها تفاقمت مؤخراً فقط بسبب معدلات رفض tunnel الجنونية 16:49 <jrandom> نأمل أن تُصلح المراجعة القادمة ذلك لنا 16:49 <jrandom> حسناً، هل لدى أي شخص شيء آخر حول 2) إنشاء tunnel والازدحام؟ 16:50 <@frosk> يبدو أنه سيتطلب بعض التغييرات في مخطّط بناء tunnel 16:50 <+Complication> آمل أن يساعد على تحسين الأمور :) 16:51 <+Complication> أوه، بالمناسبة... 16:52 <jrandom> حسناً، لدينا بعض الإصلاحات الرخيصة، مثل تقليل الحد الأقصى للتوازي، وتقييد محاولات البناء عند الازدحام، وتقليل معدل الإسقاط (بدلاً من الرفض الصريح)، وضبط التوصيف لتحفيز الرفض الصريح بدلاً من الإسقاط 16:52 <+Complication> ...هل صادف أن وجدتَ أي شيء يمكن أن يفسّر التفاوت الكبير بين مؤشرات عرض النطاق الخام ومؤشرات حمولة tunnel؟ 16:52 <+Complication> (مثلاً: إجمالي bandwidth 1 GB، مجموع حمولة tunnel 300 MB) 16:52 <jrandom> لكن صحيح أن تلك لا تؤثر إلا على الحجم 16:52 <+Complication> (لأنني لم أكن على IRC مؤخراً، لست متأكداً إن كنتم نظرتم في ذلك مؤخراً) 16:54 <jrandom> لم أتعمق في ذلك كثيراً، لكن تذكّر أن طلبات بناء tunnel للـ tunnels الصادرة ليست رسائل tunnel (وهي كثيرة إذا كانت نسبة النجاح 0.1% فقط. وكل واحدة بحجم 4KB...) 16:54 * Complication غير متأكد إن كان الأمر يتعلق بالمؤشرات، أم تأثير حقيقي 16:55 <+Complication> أوه... طلبات بناء صادرة... بالفعل 16:55 <jrandom> البناء القادم -1 يضيف كماً من الإحصاءات لمراقبة الحزم لكل نوع رسالة 16:55 <+Complication> قد يكون هذا بالتحديد هو السبب 16:55 <jrandom> (كما تتضمن طلبات البناء الصادرة تلك طلبات بناء مشاركة — تمرير رد) 16:56 <jrandom> ((لذا فالأمر ليس محلياً فحسب)) 17:00 <+Complication>> شكراً، هذا يفسّر الأمر كثيراً :) 17:00 <+Complication>> إذاً ليس سحراً أسود، بل حركة مرور حقيقية تماماً نسيتُها فحسب، لأنها لم تُحصَ على نحو محدد في الأماكن التي تحققتُ منها 17:00 <+Complication> سيتعيّن حدوثها فعلاً، وستكلّف الكثير من البايتات فعلاً 17:00 <+Complication> خاصة مع معدلات نجاح منخفضة 17:01 <jrandom> أجل، رغم أنه لا ينبغي أن يكلّف بقدر ما يفعل، إذ ينبغي أن تكون لدينا معدلات نجاح أعلى مما هي عليه الآن :) 17:01 <jrandom> حسناً، أي شيء آخر بخصوص 2)؟ 17:02 <jrandom> إن لم يكن، فلننتقل إلى 3) Feedspace 17:02 <jrandom> frosk: هل تود أن تعطينا تحديثاً؟ 17:03 <jrandom> (أو تطلب منا أن fsck off وأن نقرأ الـ eepsite؟ ;) 17:04 <@frosk> حسناً، لمن لم ينتبه إلى frosk.i2p أو feedspace.i2p، فإن Feedspace يعمل الآن «بشكل أساسي» (بحسب تعريفي الخاص لـ«أساسي) 17:04 <jrandom> (w00t) 17:05 <@frosk> كان هناك بعض الإضافات اللطيفة مؤخراً، مثل دعم بنيوي لوسائط نقل غير i2p (يخطر بالبال tor وtcp/ip غير المجهَّل) 17:06 <@frosk> لذا مع الوقت، نخطط للسماح لـ syndie (في إعادة كتابة قادمة وعلى الأرجح لطيفة جداً) باستخدام Feedspace كأحد أساليب التوزيع لديها 17:06 <@frosk> حالياً، لا توجد أي تطبيقات عميل لتقوم فعلياً بـ*استخدام* Feedspace لأي شيء :) لقد كنتُ أختبر بتطبيق servlet بدائي للغاية 17:07 <jrandom> (بدائي + وظيفي)++ 17:07 <@frosk> إذن هناك بالطبع وظيفة شاغرة لمخترق تطبيقات عميل ;) 17:08 <@frosk> ما زال هناك بعض الأشياء الضرورية التي يحتاجها Feedspace قبل أي اختبار عام، لكن الأمر لن يطول الآن :) 17:08 <jrandom> nice1 17:08 <jrandom> أي شيء يمكننا فعله للمساعدة؟ 17:08 <@frosk> وأيضاً كنتُ أعمل قليلاً على التوثيق، الذي كان ناقصاً 17:09 <spinky> هل ترى أن Feedspace سيكون قابلاً للاستخدام للملفات الكبيرة؟ 17:10 <@frosk> 1) تطبيقات عميل تستخدم الـ xmlrpc api (التي لا تزال غير موثَّقة)، 2) http://feedspace.i2p/wiki/Tasks، 3) المشاركة في الاختبار عندما يحين الوقت 17:10 <@frosk> دعم الملفات الكبيرة ليس أولوية حالياً، لكن ربما لاحقاً 17:10 <@frosk> التركيز في «1.0» هو الرسائل الأصغر مثل تدوينات المدونات ومشاركات النقاش، والأحداث بأي نوع 17:11 <jrandom> مع ذلك، تمرير ملفات .torrent إلى عميل bt مُمكَّن بـ rss/feedspace لن يكون مشكلة 17:11 <@frosk> قد تعمل الملفات الكبيرة وقد لا تعمل :) 17:11 <@frosk> سيكون ذلك شيئاً رائعاً للغاية 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> آمل أن نرى كل أنواع تطبيقات «adapter» كهذه :) 17:12 <+Complication> حسناً، أنا متأكد أن الناس سيجدون طرقاً لنقل الملفات الكبيرة باستخدام قنوات جانبية... أمم، جانبية :) 17:15 <@frosk> أشعر ببعض الذنب لأن شيفرة Feedspace تستخدم كل أنواع ميزات java1.5. ربما سيكون من الصعب ترجمتها/استخدامها على Java الحرة حالياً، لكنها ستلحق بالتطور، أنا متأكد :) 17:15 <jrandom> يا للهول 17:16 <jrandom> حسناً، هناك شائعات عن أن gcj ستعتمد ecj لدعم 1.5-isms 17:16 <spinky> Complication: خيول بسرج يحمل حقائب مليئة بأقراص hdds؟ 17:16 <@frosk> نعم 17:17 <+Complication> spinky: طائرات مُسيّرة، في حالتي المفضلة :P 17:17 * jrandom لا يزال بالكاد ينتقل إلى 1.4-isms 17:17 <+Complication> لكن أظن أن الخيول تنجح أيضاً :P 17:17 <jrandom> مع أن 1.6 جميل بالتأكيد ;) 17:17 <@frosk> للبقاء متوافقاً مع gcj؟ 17:18 <@frosk> حسناً، أظن أن 1.6 ليس لديه الكثير من «-isms» لمعظم الأشياء على أي حال :) 17:18 <+Complication> (أو قنافذ طائرة تُسقِط بطاقات ذاكرة جواً) 17:18 <jrandom> gcj/classpath/etc، ولكن أيضاً من أجل الأداء (وجدتُ 1.5 أثقل قليلاً من 1.4) 17:19 <jrandom> صحيح، تحسينات 1.6 تتعلق إلى حد كبير بـ vm/bytecode 17:19 <@frosk> همم، حسناً 17:20 * jrandom لا يحاول إقناعك بعدم استخدام 1.5isms. أنا متأكد أن لديك أسبابك، وعلى سبيل المثال azureus يتطلب 1.5 بالفعل 17:21 <@frosk> حسناً، لا عودة للوراء :) نأمل ألا تكون الطريق وعرة جداً 17:24 <jrandom> أجل، أنا متأكّد أنه سيسير على ما يرام :) 17:25 <jrandom> حسناً، رائع، هل لدى أي شخص شيء آخر حول 3) Feedspace؟ 17:25 * frosk يعانق generics وjava.util.concurrent ;) 17:25 <jrandom> ههه 17:27 <jrandom> حسناً، إذا لم يكن هناك شيء آخر حول 3، فلننتقل إلى 4) ??? 17:27 <jrandom> هل لدى أحد أي شيء آخر للاجتماع؟ 17:27 <+Complication> سؤال صغير كان ينبغي أن أسأله تحت 2) 17:28 <+Complication> هل تعرفون كيف تتكون عادة tunnels المشاركة الخاملة؟ 17:28 <+Complication> هل هي غالباً علامة على فشل بناء tunnel، حيث لا يعرف بالفشل فعلياً إلا المُنشئ؟ 17:28 <+Complication> أم أن لها أسباباً إضافية؟ 17:28 <+Complication> (بالإضافة، بالطبع، إلى الواضح — أي تطبيق جالس بلا نشاط) 17:29 <jrandom> التطبيق الخامل لن يكون لديه tunnels خاملة (سيتم اختبارها) 17:29 <jrandom> tunnels الخاملة فشلت لسببٍ ما 17:29 <jrandom> (إما فشلت في أن تُنشأ بالكامل، أو فشلت أثناء التشغيل) 17:30 <+Complication> صحيح، إذاً كل tunnels تُختبر على أي حال، واختبار tunnel يجب أن يسبب حركة... بالفعل 17:30 <+Complication> هذا يقودني في الواقع إلى الجزء الثاني من سؤالي: هل سيقدم فائدة أن نلاحظ أن tunnel خاملة ونقوم بالتخلّص منها مبكراً؟ 17:31 <+Complication> هل هناك موارد ثمينة يمكن حفظها هناك؟ 17:32 <jrandom> لا — الـ tunnel التي لا تدفع بيانات لا تستهلك موارد 17:32 <jrandom> (حسناً، إنها تستخدم بعض الذاكرة ram، ربما 32 بايت) 17:32 <+Complication> أو ربما، قد يساعد ذلك router على الإبقاء على صورة أفضل عن حمله ومعلمات مشابهة... 17:33 <jrandom> التنبؤات باستخدام عرض النطاق بناءً على تاريخ tunnel هو بالتأكيد سؤال مفتوح 17:33 <+Complication> أم أنه سيكون عملاً بلا طائل، ومن الأفضل الانتظار حتى تنتهي صلاحيتها طبيعياً؟ 17:33 <+Complication> (كما يحدث الآن) 17:34 <jrandom> اعتدنا إجراء بعض التنبؤات، لكنها لم تعطِ فوائد واضحة، لذا نستخدم خوارزمية أبسط الآن 17:34 <+Complication> آها، إذن لا مكسب... 17:34 <+Complication> شكراً، كان هذا أساساً كل ما أردتُ أن أسأل عنه :) 17:34 <jrandom> على الرحب، قلق مفهوم 17:34 <jrandom> حسناً، هل لدى أحد أي شيء آخر للاجتماع؟ 17:35 <+Complication> نعم، إذا أجرى أحدٌ تنبؤات، فقد تُميل نسبة tunnels الخاملة التقديرات 17:35 <+Complication> (إذا تغيّرت بشكل ملحوظ) 17:36 <jrandom> أجل، سنرغب في إبقاء نسبة الخمول جزءاً من التقدير 17:36 <jrandom> (اعتدنا ذلك — انظر طريقة RouterThrottleImpl.allowTunnel) 17:37 <+Complication> أوه، لم أكن أعلم ذلك :) 17:37 <jrandom> ولاحظ التعليق الجديد: 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication لا يزال يتصفح باتجاه الملف، لكن شكراً :) 17:39 <jrandom> w3rd 17:40 <jrandom> حسناً، إذا لم يكن هناك شيء آخر للاجتماع... 17:40 * jrandom يختتم 17:41 * jrandom يُغلق الاجتماع بـ*baf*