اجتماع مطوري I2P - 22 مارس 2005

13:01 <@jrandom> 0) مرحبًا 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) التجميع 13:01 <@jrandom> 3) التحديث 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) مرحبًا 13:01 * jrandom يلوّح 13:01 <@jrandom> ملاحظات الحالة الأسبوعية التي نُشرت للتو متاحة على @ http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> مرحبًا 13:02 <+cervantes> أهلًا 13:02 <@jrandom> سنقفز مباشرةً إلى 1) 0.5.0.3 13:02 <@jrandom> الإصدار صدر قبل بضعة أيام، والتقارير كانت إيجابية 13:02 <+cervantes> jrandom: أبلغنا عندما يتسلق الأقزام الزرق الراقصون شاشة حاسوبك وسنُنهي الاجتماع مبكرًا 13:03 <@jrandom> هه يا cervantes 13:03 <@jrandom> (شكرًا لبوب على سجلات الاجتماع القابلة للتحرير ;) 13:04 <@jrandom> ليس لدي الكثير لأضيفه بخصوص 0.5.0.3 أكثر مما ورد في تلك الرسالة 13:04 <@jrandom> هل لدى أحد أي تعليقات/أسئلة/مخاوف بشأنه؟ 13:04 <bla> jrandom: هل هناك أي قياسات جديدة لشفرة اختيار الأقران السريعين؟ 13:05 <@jrandom> آه، كنت أعلم أن هناك شيئًا آخر في 0.5.0.3 أهملته ;) 13:06 <@jrandom> لا أملك مقاييس صارمة بعد، لكن بالتجربة اختيار الأقران السريع عثر على الأقران الذين أعلم صراحةً أنهم 'سريعون' (مثل routers على نفس الجهاز، إلخ) 13:07 <bla> jrandom: أحيانًا، لا تزال eepsites تتطلب عدة محاولات للعثور على tunnel جيد للاستخدام 13:07 <@jrandom> وصلت تقارير عن معدلات إنتاجية معقولة إلى حد ما أيضًا (في حدود 10-20KBps)، لكن ذلك لا يزال غير متكرر (ما زلنا نضبط المعلمات على مستويات منخفضة) 13:08 <+ant> <Connelly> أوبس هناك اجتماع 13:09 <@jrandom> همم، نعم، وجدت أن الاعتمادية لا تزال ليست بالمستوى المطلوب. إعادة المحاولة أكثر من مرة ليست حلاً حقًا — إذا لم يتحمّل الموقع بعد محاولة واحدة، امنحه 5-10 دقائق قبل أن تعاود المحاولة 13:09 <@jrandom> ما رأيته على الشبكة هو بعض طفرات التأخير في طبقة النقل تحدث بوتيرة غير نادرة بما يكفي 13:10 <@jrandom> مثلًا: يستغرق الأمر 5-20+ ثانية فقط لتفريغ رسالة بحجم 1-2KB عبر مقبس 13:10 <@jrandom> اربط ذلك بمسار من 5 قفزات (tunnels من قفزتين) وقد تواجه مشكلات 13:11 <@jrandom> هذا في الواقع جزء مما يدفع إلى شفرة التجميع — تقليل عدد الرسائل المطلوب إرسالها 13:13 <@jrandom> حسنًا، هل لدى أي شخص أسئلة/تعليقات/مخاوف بشأن 0.5.0.3؟ 13:13 <bla> jrandom: يبدو جيدًا. سأسأل المزيد عنه في "القسم" التالي 13:14 <@jrandom> تمام، حسنًا، ربما يمكننا الانتقال إذًا إلى - 2) التجميع 13:15 <@jrandom> رسالة البريد ومدونتي (jrandom.dev.i2p</spam>) ينبغي أن تصفا أساسيات ما هو مخطط له 13:15 <@jrandom> وعلى كل، إنها أشياء أساسية جدًا 13:15 <@jrandom> مسبّق المعالجة الحالي لدينا كان أبسط ما يمكن تطبيقه (اسم الصنف: TrivialPreprocessor) ;) 13:16 <@jrandom> الجديد يحتوي على بعض المعلمات القابلة للضبط لتواتر التجميع، بالإضافة إلى قدر من التآلف مع outbound tunnel ضمن مجموعات tunnel الفردية (حيث نحاول اختيار نفس outbound tunnel للطلبات اللاحقة لمدة تصل مثلًا إلى 500ms، حتى نتمكن من تحسين التجميع) 13:17 <@jrandom> هذا كل ما لدي لأضيفه حول ذلك — أي أسئلة/تعليقات/مخاوف؟ 13:18 <bla> هل يتطلب هذا من جميع العقد المشاركة تشغيل مسبّق المعالجة الجديد، أم يمكن لتشكيلة من Trivial/NewOne أن تتعايش؟ 13:18 <+Ragnarok> هذا سيضيف 0.5 ثانية إلى الكمون، صحيح؟ 13:19 <@jrandom> bla: لا، هذا المسبّق يُستخدم فقط على بوابة tunnel، ويعود لتلك البوابة تقرير كيفية التجميع أو ما إذا كان سيُجمع أصلًا 13:20 <@jrandom> Ragnarok: ليس عادةً — قد تُؤجَّل الرسالة 1 لمدة تصل إلى 0.5 ثانية، لكن الرسائل 2-15 تُنقل أسرع بكثير مما كانت ستنقل بدونه. كما أنه حد بسيط — بمجرد توفّر بيانات تكفي رسالة tunnel كاملة، تُصرَّف 13:20 <+Ragnarok> رائع 13:20 <+Ragnarok> كم مقدار الحمولة الزائدة التي يوفرها؟ 13:21 <@jrandom> كبير ;) 13:21 <+Ragnarok> كبير أمر جيد، وإن كان مبهمًا :P 13:21 <@jrandom> انظر إلى http://localhost:7657/oldstats.jsp#tunnel.smallFragments لديك 13:21 <@jrandom> وقارنه مع #tunnel.fullFragments 13:22 <bla> jrandom: هل يخص هذا الاتصال بين endpoint->IB-gateway فقط؟ 13:22 <@jrandom> مع التجميع، سترتفع نسبة الكامل إلى الصغير، وسيَنخفض عدد بايتات الحشو في الصغير 13:23 <@jrandom> bla: همم، إنه يخص جميع بوابات tunnel، سواء الوارِدة أو الصادرة 13:24 <mihi> الشظايا الكاملة: قيمة المتوسط على مدى العمر: 1,00 عبر 1.621,00 حدثًا 13:24 <bla> jrandom: ok 13:24 <mihi> هل يمكن أن يكون هناك عدد كسري من الشظايا؟ 13:24 <@jrandom> كامل: 1.00 عبر 807,077.00 حدثًا صغير: 746.80 عبر 692,682.00 حدثًا 13:25 <@jrandom> هه mihi 13:25 <@jrandom> (هذا small: 746 يعني أنه من أصل تلك الرسائل البالغ عددها 692k، كان 746 من أصل 996 بايتًا عبارة عن بايتات حشو مهدورة!) 13:26 <@jrandom> حسنًا، ليست مهدورة تمامًا — فقد أدّت غرضها 13:26 <+detonate> على أي حال، حمولة زائدة غير ضرورية 13:27 <@jrandom> نعم، ويمكننا التخلّص من الكثير منها عبر مسبّق التجميع 13:28 <@jrandom> لسوء الحظ، لن يُضمّن ذلك في الإصدار التالي 13:28 <@jrandom> ولكنه سيُضمّن في إصدار 0.5.0.6 (أو ربما 0.5.1) 13:28 <@jrandom> مم، 0.5.0.5، أو 0.5.1 13:28 * jrandom يختلط عليه أمر الأرقام 13:29 <bla> jrandom: لماذا لا؟ 13:29 <+cervantes> حشيش وحبوب... تبا 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: هناك علّة في 0.5.0.3 (وقبله) حيث يتسبب معالج الرسائل المجزأة في تجاهل الشظايا اللاحقة داخل نفس رسالة tunnel 13:31 <@jrandom> لو نشرنا مسبّق التجميع مباشرةً، لكان لدينا عدد كبير من الرسائل المفقودة 13:31 <@jrandom> لا داعي للقلق، لدينا أشياء لطيفة أخرى في جعبتنا، لذا 0.5.0.4 القادم لن يكون مملًا تمامًا ;) 13:31 <bla> jrandom: آه، إذًا ذلك 13:32 <bla> jrandom: آه، إذًا لهذا علينا فعل ذلك بعد أن يصبح 0.5.0.4 سائدًا.. فهمت. شكرًا. 13:33 <@jrandom> نعم، سيكون جميلًا لو كان معالج الشظايا قادرًا على التعامل معه، وهو يفعل ذلك عمومًا، لكنه فقط يحرّر مخزن البايتات مبكرًا جدًا، فيصفّر الشظايا اللاحقة (أوبس) 13:33 <@jrandom> حسنًا، أي شيء آخر حول 2)، أم ننتقل إلى 3) التحديث؟ 13:35 <@jrandom> حسنًا، كما ذُكر في ملاحظات الحالة (ونوقش لبعض الوقت في مواقع مختلفة)، سنضيف بعض الوظائف للتحديث البسيط والآمن الذي لا يتطلب من المستخدم النهائي زيارة الموقع، أو قراءة القائمة البريدية، أو قراءة الموضوع في القناة :) 13:36 <+detonate> رائع 13:36 <@jrandom> smeghead جمع بعض الشفرة للمساعدة في أتمتة العملية وتأمينها، بالتعاون مع cervantes للربط مع fire2pe بالإضافة إلى routerconsole العادي 13:37 <@jrandom> رسالة البريد تسرد الوصف العام لما سيكون متاحًا، ومع أن معظمها عملي، لا تزال هناك بعض الأجزاء التي لم تُحسَم بالكامل بعد 13:37 <@jrandom> وعلى خلاف التجميع، فهذا /سيكون/ متاحًا في الإصدار التالي، رغم أن الناس لن يتمكنوا من الاستفادة منه كثيرًا حتى 0.5.0.5 (عندما يحين وقت التحديث) 13:39 <+Ragnarok> إذًا... ما الأشياء الرائعة في 5.0.4 إذن؟ 13:42 <@jrandom> مع شفرة التحديث تأتي إمكانية جلب بيانات الإعلانات، وعرض مثلًا مقتطف من الأخبار أعلى واجهة router. إضافةً إلى ذلك، كجزء من شفرة التحديث لدينا مكوّن جديد للتنزيل الموثوق يعمل إمّا مباشرةً أو عبر eepproxy، مع إعادة المحاولة والمتابعة أثناء العملية. ربما ستكون هناك ميزات ذات صلة مبنية على ذلك، لكن دون وعود 13:42 <+Ragnarok> جميل 13:43 <@jrandom> حسنًا، هل لدى أي شخص أسئلة/تعليقات/مخاوف حول 3) التحديث؟ 13:45 <@jrandom> إن لم يكن، ننتقل إلى 4) ??? 13:45 <@jrandom> أي شيء آخر يريد أحد طرحه؟ أنا متأكد أنني فاتتني بعض الأشياء 13:45 <+detonate> من المعروف أن I2P يعمل مع Sun JVM على OpenBSD 3.7 :) 13:45 <@jrandom> جميل! 13:47 <bla> ما حالة نقل UDP؟ 13:48 <+detonate> سيكون UDP فوضويًا، أظن أنه سيكون من الأفضل سرقة كود pipelining من bt وتكييفه ;) 13:48 <@jrandom> *سعال* 13:49 <@jrandom> لا أتوقع مشاكل كثيرة، لكن هناك بالتأكيد عمل ينبغي إنجازه 13:49 <@jrandom> سيكون من المثير كيفية عمل سياسة الاصطفاف، وكذلك تقييد عرض الحزمة لقبول الإدخال إلى الصف 13:50 <bla> من كان يقوم بذلك العمل الأولي؟ 13:50 <@jrandom> bla: detonate و mule 13:50 <+detonate> نعم.. لقد تهاونت خلال الشهر الماضي أو نحوه 13:50 <bla> detonate: أفترض أنك تمزح، بشأن تعليقك عن BT؟ 13:51 <+detonate> أنا جادّ نصف الجد 13:51 <+detonate> يمكنك على الأقل خفض عدد الخيوط لطبقة النقل إلى النصف إذا فعلت ذلك 13:51 * jrandom يرشق detonate بدلو من الطين 13:51 <jdot> واو. يعمل router الخاص بي الآن على الخادم المخصص بدلًا من اتصال الكابل السيئ لدي. 13:51 <@jrandom> جميل يا jdot 13:52 <@jrandom> سنستطيع الاكتفاء بـ3-5 خيوط في طبقة النقل لكل الاتصالات مع جميع الأقران 13:52 <bla> detonate: لكن النصف لن يكفي عندما تصبح الشبكة كبيرة (> بضع مئات من العقد) 13:52 <jdot> مع 1000GB من عرض الحزمة تحت تصرّفه 13:53 <jdot> لسوء الحظ j.i2p و chat.i2p سيكونان متوقفين لبضع ساعات أخرى بينما أنقل الأشياء 13:53 <duck> detonate: دفتر العناوين متوقف أيضًا؟ 13:53 <+detonate> نعم، متوقف أيضًا 13:54 <+detonate> الشيء الوحيد غير المتوقف هو تخزين الملفات الشخصية الأحادي، كنت أنوي تشغيله لاحقًا اليوم 13:54 <@jrandom> تمام 13:54 <+detonate> عندها لن يسبب I2P تجزئة كبيرة للقرص 13:54 <jdot> jrandom: بالنسبة لحدود عرض الحزمة، هل هي متوسطات؟ 13:54 <+frosk> أنظمة الملفات الحديثة لا تتجزأ، يا ساذج 13:55 <+detonate> لكن NTFS تتجزأ 13:55 <@jrandom> jdot: حدود عرض الحزمة عبارة عن token buckets (دلُو الرموز) صارمة 13:55 <@jrandom> jdot: إذا عيّنت مدة الانفجار، فذلك هو طول الفترة التي يُحتسب متوسطها خلالها 13:56 <@jrandom> (حسنًا، 2x burst == period) 13:56 <@jrandom> ((تقريبًا)) 13:56 <jdot> هممم... لدي 1000GB وأريد أن يتمكن I2P من استخدام ما يصل إلى 800GB/شهر.... 13:56 <+ant> <mihi> detonate: ntfs تخزّن الملفات الصغيرة جدًا في mft مما يعني تقريبًا عدم وجود تجزئة 13:57 <jdot> ولا يهمني إلى أي حدّ ينفجر المعدل 13:57 <+detonate> حسنًا، عندما تشغّل أداة إلغاء التجزئة، تقضي 10 دقائق في نقل كل 6000 ملف شخصي... لذا فلا بد أنها تتجزأ 13:58 <@jrandom> jdot: مم، حسنًا، 800GB ربما أكثر مما سيرغب في دفعه على أي حال، لذا يمكنك على الأرجح تركه دون حدود ;) 13:58 <@jrandom> ومن جهة أخرى، إن استطعت وصف سياسة تريد تنفيذها، فقد نتمكن من التعامل معها 13:58 <jdot> jrandom: سأفعل ذلك الآن وأرى كيف يعمل 13:58 <bla> detonate: NTFS، إذا لم تخني الذاكرة (IIRC)، هو نظام ملفات يسجّل المعاملات. لذا حتى الملف الأحادي سيتجزأ إذا كتبت إليه أجزاء صغيرة 13:58 <+detonate> كل شيء يُكتَب دفعة واحدة 13:59 <+detonate> ويُقرأ دفعة واحدة 13:59 <bla> detonate: حسنًا. فهمت. 13:59 <jdot> jrandom: حسنًا، دعنا ننتظر حتى نعرف ما إذا كان سيكون مشكلة أصلًا. 13:59 <bla> detonate: عمل جيد في هذه الحالة! 13:59 <+detonate> سأكون مهتمًا بمعرفة حجم الاستخدام الفعلي إذا تركته غير مقيّد 14:00 <+detonate> على اتصال جيد 14:00 <jdot> أنا مهتم أيضًا! 14:00 <@jrandom> routers المستضافة في مركز بيانات لدي تعمل دون تقييد، رغم أنها مقيّدة بالمعالج 14:00 <+Ragnarok> هل يمكنك استخدام bitbucket لحساب المتوسط على مدى شهر؟ 14:00 <jdot> jrandom: مقيّدة بالمعالج؟ ما نوع المعالج؟ 14:01 <@jrandom> نقل 4d 3.04GB/2.73GB 14:01 <+detonate> همم، كنت أتوقع أقل 14:01 <@jrandom> jdot: مقيّدة بالمعالج لأني أشغّل عليها 3 routers، إضافةً إلى بعض JVMs أخرى، وأحيانًا أقوم بتحليل الأداء 14:01 <+detonate> لا بد أنهم ناس bt 14:01 <+detonate> بمجرد أن تصبح أمور التجميع متاحة، سيكون من المثير رؤية كيف يتغير ذلك 14:02 <@jrandom> detonate: بعض ذلك النقل هو أيضًا قيامي بدفع ملفات 50MB بينه وبين نفسه ;) 14:02 <+detonate> هه 14:02 <jdot> آه. حسنًا. سنرى كيف يعمل هذا النظام. إنه AMD XP 2400 بذاكرة 512MB واتصال 10Mbit 14:02 <@jrandom> Ragnarok: token buckets لا تعمل حقًا بهذه الطريقة 14:02 <@jrandom> jdot: صحيح، نعم، هذا P4 1.6 إذا لم تخني الذاكرة 14:03 <@jrandom> Ragnarok: في token bucket، في كل ثانية (مثلًا) تضيف بعض الرموز وفقًا للمعدل. إذا كان الدلو ممتلئًا (الحجم = فترة الانفجار)، تُهمَل الرموز 14:04 <@jrandom> عندما تريد نقل بيانات، تحتاج إلى الحصول على كمية كافية من الرموز 14:04 <@jrandom> (1 رمز = 1 بايت) 14:04 <+Ragnarok> أعرف كيف تعمل... ماذا يحدث لو جعلت الدلو كبيرًا جدًا؟ 14:05 <+detonate> عندها لن تتوقف أبدًا عن إرسال البيانات 14:05 <+detonate> إذا كان غير محدود الحجم 14:05 <+detonate> آه، وممتلئ بالرموز 14:05 <@jrandom> إذا كان كبيرًا حقًا، فقد ينطلق ويفرغ إلى معدلات غير محدودة بعد استخدام منخفض 14:06 <@jrandom> مع أنه ربما يكون مرغوبًا في بعض الحالات 14:07 <@jrandom> المسألة أنك لا تستطيع فقط ضبط token bucket على 800GB، لأن ذلك لن يقيّد إجمالي الكمية المنقولة 14:08 <+detonate> تحتاج إلى حقل هناك لضبط عدد الرموز في الثانية، ثم يمكنك ببساطة قسمة استخدام عرض الحزمة شهريًا على عدد الثواني 14:08 <+detonate> :) 14:10 <@jrandom> هذا يماثل مجرد ضبط المعدل كمتوسط على مدى الشهر، مما سيكون غير متوازن. على أي حال، توجد الكثير من السيناريوهات — إن كان لدى أحد ما يلبي احتياجاته ولا يمكن تحقيقه بما هو متاح، فاليراسلنا 14:10 <+Ragnarok> لكن إن ضبطت المعدل على المتوسط الذي تريده... أظن 308 kB/s هنا، ثم ضبطت bitbucket على شيء كبير جدًا... لماذا لا ينجح ذلك؟ 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> حسنًا، يمكنك ضبطه بحيث لا يرسل أكثر من 800GB/44000 ضمن فترة انفجار قدرها 60 ثانية 14:12 <+detonate> و44000 هو تقريبًا عدد الدقائق في الشهر 14:13 <@jrandom> حجم الدلو/مدة الانفجار يصفان مقدار ما سنرسله دون قيود، ومعظم الناس /يريدون/ قيودًا، حتى لا يلتهم router سرعة 10mbps لمدة 5 دقائق أثناء تفريغ الدلو (أو أيًا كان) 14:14 <@jrandom> من الممكن أيضًا إضافة مقيِّد إضافي للرموز الخارجة من الدلو (وهل ينبغي لذلك المقيِّد أن يكون له token bucket خاص به، ولهذا الدلو مقيِّده الخاص، إلخ) 14:16 <+Ragnarok> كنت أظن أن الدلو لا يُضاف إليه إلا عندما لا يكون هناك عرض حزمة مستخدم 14:16 <@jrandom> تُضاف الرموز إلى الدلو بمعدل ثابت (مثلًا 64k رمزًا في الثانية) 14:17 <@jrandom> أي شيء يريد عرض حزمة يطلب من الدلو دائمًا 14:18 <+Ragnarok> آه.. حسنًا 14:19 <@jrandom> حسنًا رائع، هل لدى أحد شيئًا آخر يريد طرحه للاجتماع؟ 14:21 <@jrandom> حسنًا إن لم يكن 14:21 * jrandom يستعد 14:21 * jrandom يُغلق الاجتماع بـ*baf*