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

13:04 <jrandom> 0) مرحباً 13:04 <jrandom> 1) 0.5 13:04 <jrandom> 2) الخطوات التالية 13:04 <jrandom> 3) azneti2p 13:04 <jrandom> 4) ??? 13:04 <jrandom> 0) مرحباً 13:04 * jrandom يلوّح 13:05 <jrandom> ملاحظات الحالة الأسبوعية منشورة @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html 13:05 <jrandom> (نعم، قبل الاجتماع بدقيقة أو دقيقتين فقط، فلنختبر سرعة قراءتكم) 13:05 <+detonate> أظن أنني سأنتظر حتى تصبح أقل عللاً قليلاً قبل أن أضع Boondock Saints في هذه الحالة 13:06 <jrandom> لماذا... هذا... هذا... هذا انتهاك لحقوق النشر! 13:06 <+detonate> إضافات جديدة غريبة إلى نسخة Azureus التجريبية 13:06 <+detonate> تصنيفات 13:06 <+detonate> هههه 13:06 <+detonate> متعقّب DHT 13:06 <+detonate> رائع 13:07 <jrandom> أجل، يبدو رائعاً جداً، لكن لنعالج البندين 1 و2 قبل 3، ما رأيكم؟ ;) 13:07 <+detonate> مرحباً 13:07 <+detonate> بالفعل 13:07 <jrandom> نبدأ بـ 1) 0.5 13:07 <jrandom> إنه، يعني، صدر وكل شيء 13:08 <cervantes> يا للروعة! 13:08 <jrandom> ستكون هناك نسخة جديدة في وقت لاحق هذا المساء مع مجموعة تحديثات (رأس CVS الحالي هو 0.5-5، و-6 قيد الاختبار على بعض routers) 13:09 <jrandom> سارت الأمور بشكل جيد إلى حد كبير، لكن واجهنا بعض العلل الغريبة على الطريق. لكن هذه هي الحياة 13:09 <frosk> أستطيع أن أبلغ أن 0.5-5 يتصرف بشكل أكثر وُدّية بكثير من -4 (الذي كان يعطيني كثيراً أعداد tunnels المشاركة بالآلاف) 13:09 <bla> jrandom: هل ستصحح نسخة 0.5.0.1 مشكلة عدم القدرة على العثور على الوجهات؟ 13:09 <jrandom> آه، حسناً، هذا في الحقيقة يعتمد على الآخرين، فالإصدار -0 فعلياً يبني مئات tunnels 13:09 <bla> s/nor/not 13:10 <jrandom> bla: نعم، تلك علّة في netDb 13:10 <bla> jrandom: عظيم! 13:10 <jrandom> (تحديداً في نشر leaseSet) 13:11 <jrandom> ونعم، نسخة 0.5.0.1 ستتخلص من علّة اختفاء الوكيل أحياناً 13:12 <jrandom> لا تزال هناك تسريبات ذاكرة غريبة لم أحدد مصدرها بعد تؤثر على بعض المستخدمين 13:12 <bla> إذن، بشكل عام، يبدو أنه باستثناء هذه العلل، شبكة 0.5 تعمل بشكل جيد جداً. يا للروعة! 13:12 <jrandom> حسب علمي، هي تؤثر فعلياً على مثيلين أو ثلاثة من I2PTunnel فقط 13:12 <Meomia> هل هذا علامة تقدم عندما تنتقل من 0 إلى 130 من tunnels المشاركة منذ 0.5؟ 13:13 <jrandom> w3wt 13:13 <jrandom> Meomia: بح، كان لديّ أكثر من 5000 tunnels ;) 13:13 <jrandom> لكن dm ساعد فعلياً في العثور على علّة في كود مجموعة الاستكشاف، لذا سنبني tunnels بشكل أكثر تكراراً على أقران 'عشوائيين' 13:14 <jrandom> (يا للروعة) 13:14 <Meomia> حسناً 13:14 <bla> jrandom: هل يعني ذلك أيضاً أنه الآن، بخلاف 0.4، يمكن لأي قرين في وقت ما أن يصبح inbound gateway (بوابة الدخول الواردة) لديك؟ 13:14 <jrandom> نعم، بالنسبة لـ exploratory tunnels 13:15 <jrandom> client tunnels ستستخدم فقط الأقران في الفئة 'السريعة' 13:15 <bla> bla: حسنٌ. حقيقة أن client tunnels تستخدم فقط الأقران السريعِين أمر جيد: وإلا سنواجه مسألة إخفاء الهوية التي ناقشناها سابقاً 13:16 <jrandom> والأداء سيكون سيئاً جداً خلاف ذلك ;) 13:17 <jrandom> في الواقع، هذا يقودنا إلى 2) الخطوات التالية 13:18 <jrandom> الأمر الكبير المتبقي لسلسلة 0.5 هو مجموعة من الاستراتيجيات لترتيب و/أو ترشيح الأقران المستخدمين في tunnels 13:18 <godmode0> jrandom هل يمكن استخدام NNTP مع i2p؟ 13:18 <jrandom> godmode0: هناك خادمان NNTP على i2p، نعم. راجع المنتدى 13:19 <godmode0> jrandom حسناً أنا أختبر 13:19 <godmode0> هل أستطيع بناء خادمي أيضاً؟ 13:20 <jrandom> godmode0: نحن في اجتماع الآن، لكن نعم، يمكنك تشغيل خادم 13:20 <godmode0> jrandom حسناً عذراً 13:20 <jrandom> لا مشكلة 13:20 <jrandom> الاستراتيجيات المنشورة تهدف أساساً لتحسين إخفاء الهوية، لكن هناك بعض الأهداف الأخرى التي يمكننا الموازنة بينها 13:21 <jrandom> ربما نجد طريقة لدمج بعض مسارات AS (نظام مستقل) ضمن الاختيار، كما اقترح bla 13:22 <jrandom> ذلك قد يحسّن إخفاء الهوية من منظور الاختصاص القضائي، أو إذا حاولنا البقاء ضمن AS واحد (أو اثنين)، فقد يحسّن الأداء 13:22 <bla> jrandom: هذا مرتبط أساساً بورقة بحثية لمطوّري Tor: http://theland.i2p/files/routing-zones.pdf 13:22 <jrandom> أجل 13:23 <jrandom> هناك طيف كامل من الاستراتيجيات المختلفة التي يمكن للناس استخدامها، وتجربة جديدة منها يجب أن تكون سهلة إلى حد ما 13:24 <jrandom> لن نقضي شهوراً في تنفيذ كل ما يخطر ببالنا، بل سنوفّر الأساسيات لما يحتاجه معظم الناس. أي شخص يرغب في إضافة استراتيجيات جديدة نشجعه بشدة على المساهمة وربطها 13:25 <jrandom> على أي حال، بمجرد أن تكون الأساسيات في مكانها، سننتقل للتركيز على نقل UDP للإصدار 0.6 13:26 <jrandom> هذا تقريباً كل ما لدي لـ 2) الخطوات التالية، هل لدى أحد تعليقات/أسئلة/مخاوف؟ 13:26 <bla> من هم الأشخاص الذين بدأوا بالنظر في I2P، مرة أخرى؟ 13:26 <bla> يبدو أننا لم نسمع منهم الكثير مؤخراً. 13:27 <bla> s/into I2P/into UDP/ 13:27 <bla> آسف 13:27 <jrandom> آه، mule كان مريضاً، رغم أنني أظن أن detonate يحقق تقدماً 13:28 <jrandom> detonate: أي أخبار؟ 13:29 <jrandom> أو ربما لا ;) 13:30 <jrandom> حسناً، ننتقل إلى 3) azneti2p 13:30 <+detonate> عذراً 13:30 <+detonate> أنا أحرز تقدماً 13:30 <+detonate> لا زلت بحاجة لإكمال جانب إعادة التجميع 13:31 <+detonate> أما تقسيم البيانات إلى حزم وإرسالها بطريقة منظمة، فهذا يعمل 13:31 <+detonate> ننتقل إلى 3) 13:31 <jrandom> روعة 13:31 <godmode0> عذراً خطوة 2) هل لدى i2p أي مشاكل مع الهجمات؟ 13:31 <bla> detonate: رائع! هل يمكنك إبقاء الجميع على اطلاع في المنتدى؟ 13:32 <+detonate> bla: بالتأكيد 13:32 <tracker> بخصوص azneti2p، انظر هنا: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 يبدو أن التنزيل يعمل، أما النشر فلا. 13:32 <jrandom> godmode0: استراتيجيات الترتيب المختلفة يجب أن تتيح للمستخدم اختيار تأثير هجمات السلف (predecessor attacks) 13:33 <microsoft> من يدير i2p.net ينبغي أن يضيف المزيد من كلمات التسويق الرنانة لفئة Enterprise Class Solutions إلى الصفحة. 13:33 <+detonate> يحتاج أحدهم للتأكد من أن متعقّب DHT الجديد لا يتصرف بشكل سيئ أيضاً فيما يخص إضافة Azureus 13:33 <tracker> تجاربي المحلية تبدو وكأنها تؤكد ذلك، أستطيع التنزيل عبر Azureus ولكن لا أستطيع النشر. 13:34 <jrandom> هممم حسناً رائع يا tracker، شكراً — أعلم أنهم حدّثوا بعض الأشياء وأصدروا b34 الليلة الماضية، لكن يبدو أن هناك المزيد لفعله 13:34 <jrandom> detonate: نقطة وجيهة 13:35 <tracker> نقطة وجيهة يا detonate، لدي DHT معطّلاً لأن Azureus يتعطّل بعد ساعات مع استخدام 100% من CPU عندما يكون مُفعّلاً. 13:35 * jrandom يود التأكيد أن إضافة azneti2p لا تزال في مرحلة بيتا مبكرة إلى حد ما، ولم تُراجع تداعيات Azureus على إخفاء الهوية بشكل كامل 13:36 <jrandom> مع أنني متأكد أنهم يحبون أن يختبر الناس ذلك، إلا أن من يحتاجون لإخفاء الهوية قد يرغبون في التحوّط 13:36 <tracker> من جهة أخرى، i2p-bt يعمل بشكل جيد حقاً. باستثناء أنه لا يغلق tunnels، لكن هذا ليس سيئاً للغاية برأيي. 13:37 <jrandom> أوه، هل ما زال ذلك يحدث معك يا tracker؟ لم أستطع إعادة إنتاجه 13:37 <jrandom> أأنت على نسخة 0.1.7، صحيح؟ 13:37 <tracker> نعم. 13:38 <jrandom> حسناً جميل، إذا كان يحدث معك طوال الوقت فسيسرّني أن أستفيد من خبرتك بعد الاجتماع للمساعدة في تتبّع السبب 13:39 <tracker> ربما يتعلق بتشغيله على XP بدلاً من Linux أو Unix. إغلاق tunnel يعمل مع Azureus، لذا أظن أنه مرتبط بـ I2P-BT. 13:39 <jrandom> هممم صحيح، i2p-bt يستخدم SAM، بينما Azureus يستخدم i2p SDK مباشرة 13:40 <tracker> بالمناسبة. أرسلت لك تقرير علّة على المنتدى. الـ timestamper يتعطّل على أحدث إصدارات CVS من I2P. 13:40 <jrandom> آه رائع، شكراً، لم أتحقق من الرسائل الخاصة هناك اليوم 13:41 <jrandom> على -5 أم -4؟ أم أبكر؟ 13:42 <jrandom> آه، -4. حسناً ممتاز 13:42 <jrandom> شكراً، سأصلحه لـ 0.5.0.1 13:42 <jrandom> حسناً، هل لدى أحد شيء آخر لـ 3) azneti2p؟ 13:43 <tracker> يحدث ذلك أيضاً على -5 13:43 <jrandom> هل لديك خادم sntp محدداً صراحة، صحيح؟ 13:44 <tracker> نعم. الاثنان من بلدنا. 13:44 <jrandom> لقد تحققت للتو من المصدر وتحدث الاستثناء إذا كان # الخوادم المتزامنة (الافتراضي = 3) أكبر من # الخوادم المحددة (القيمة الافتراضية الجديدة هي 3) 13:44 <jrandom> حسناً ممتاز، إنها إصلاح بسيط بـ % # servers 13:45 <jrandom> حسناً، إن لم يكن هناك شيء آخر لـ azneti2p، ننتقل إلى 4) ??? القديمة الطراز 13:46 <jrandom> هل لدى أحد آخر ما يطرحه للاجتماع؟ 13:46 <tracker> جميل. لقد أرسلت لك للتو أخطاء السجل من router عند إغلاق i2p-bt في المنتدى. 13:47 <jrandom> 'ك ممتاز، شكراً 13:47 <cervantes> لا شيء لأذكره سوى: عمل جميل في طرح 0.5، يبدو أنه سيتفوّق فعلاً حالما تُزال العلل 13:48 <tracker> نعم، أحدث إصدارات CVS تؤدي أداءً جيداً هنا. 13:48 <jrandom> شكراً، بفضل مساعدتكم وكذلك بقية مختبري 0.5-pre تمكّنا من تنظيف مجموعة من المشكلات 13:49 <jrandom> كان الأداء أفضل مما توقعت، وإن لم يصل بعد إلى معدلات النقل العالية كما كان سابقاً. الكثير لا يزال لنحسّنه 13:49 <cervantes> الغريب أن النسخ الـ pre كانت أكثر استقراراً... بالنسبة لي، لكنني كنت أشغّلها على جهاز مختلف ;-) 13:49 <jrandom> (وهذه العلل المزعجة لكي نصل بالموثوقية إلى ما ينبغي) 13:50 <jrandom> هه حسناً، نعم، لكن شبكة -pre كانت 5-7 routers، جميعها موثوقة بشكل جنوني وعلى اتصالات سريعة جداً جداً 13:50 <cervantes> :) 13:51 <cervantes> سجّلني إذن لاختبار 0.6 pre :) 13:51 <jrandom> هه 13:51 <tracker> ربما ينبغي أن أشارك في شبكة الـ pre القادمة إذن. بتقديم اتصال بطيء وغير موثوق جداً ;). 13:51 <jrandom> الترحيل إلى 0.6 سيكون على الأرجح أسهل، آمل ذلك، إذ سنتمكن ببساطة من إضافة عناوين router جديدة إلى routerInfo (عناوين UDP) 13:51 <jrandom> هه بالفعل 13:51 <cervantes> أستطيع وضع مشاركة ملفات بسعة 1TB على الشبكة... 13:52 <jrandom> سنحتاج بالتأكيد إلى الكثير من المساعدة في اختبار 0.6، مع تضمين طيف كامل من إعدادات الشبكات 13:52 <hobbs> أمر ssh '~C' أنيق 13:52 <laberhorst> هل ستكون هذه خطوة أخرى غير متوافقة؟ 13:53 <Myo9> هل يعرف أحد ما هي خوادم NNTP العاملة؟ 13:53 <jrandom> laberhorst: لا، 0.6 ستكون متوافقة مع الإصدارات السابقة 13:53 <jrandom> Myo9: لا أدري، قد تكون عاملة لكنها متأثرة بعلل 0.5-0 13:54 <jrandom> ينبغي لنسخة 0.5.0.1 أن تصلح الكثير من المشكلات، وبمجرد صدورها سيكون الترقية موصى بها بشدة 13:54 <laberhorst> إذن فقط ابنِ 0.6 تجريبية وضعها للمختبرين 13:54 <cervantes> يمكننا جعل حركة BT تستخدم فقط routers القديمة... هذا سيشجّع الناس على الترقية ;-) 13:54 <laberhorst> إذن حفلة ترقية كبيرة غداً 13:54 <jrandom> سيكون هناك إعلان على المنتدى والقائمة البريدية عندما تكون جاهزة 13:54 <jrandom> صحيح يا laberhorst 13:54 <jrandom> هه يا cervantes ;) 13:55 <laberhorst> *متحمّس للاختبار من أجلكم* 13:55 <jrandom> أداء BT كان جيداً جداً على 0.5، لقد رأيت الكثير من نقل الملفات الكبيرة بنجاح على trackers 13:55 <laberhorst> معدل pload: 8.85 kB/s 13:55 <jrandom> (وirc لم يتأثر كما كان من قبل، باستثناء المشاكل التي كنا نعانيها مع tunnel الخاص بـ duck) 13:55 <tracker> يعتمد على ما تسميه كبيراً ;) 13:56 <jrandom> tracker: أفكر بملف معيّن حجمه 874MB تم تنزيله بنجاح مرات عديدة ;) 13:56 <jrandom> لكن صحيح، هذا صغير لبعضهم 13:56 <laberhorst> مجرد مواد إباحية قديمة جيدة 13:56 <laberhorst> أفترض ;-) 13:57 <laberhorst> لنأمل من الغد فصاعداً ألا يشارك router لديّ في >3000 tunnels 13:57 <tracker> حسناً، هذا كبير. 13:57 <laberhorst> أو إن حدث، فالشبكة فعلاً كبيرة 13:57 <jrandom> هه يا laberhorst 13:58 <jrandom> حسناً، هل لدى أحد أي شيء آخر للاجتماع؟ 13:58 <laberhorst> بالمناسبة، هل المشاركة في>3000 مرادف لـ router جيد وموثوق في i2p مع اتصال سريع؟ 13:58 <+detonate> سأضع Boondock Saints بعد أن أحصل على House الليلة :) 13:59 <+detonate> سيكون ذلك حوالي 4.1GB جيد :) 13:59 * laberhorst يريد فقط شكر المطوّرين على سحق العلل سريعاً 13:59 <+detonate> يبدو أن هناك طلباً كبيراً 13:59 <laberhorst> أوه، بعض صور DVD هنا أيضاً، 13:59 <hobbs> detonate: أوه، صحيح. House. :) 13:59 <tracker> cervantes، هل قمت بالترقية إلى phpBB 2.0.12 بالفعل 13:59 <laberhorst> لكن انتظر حتى تصدر 0.5.0.1 13:59 <+detonate> ينبغي أن يمنح 0.5.0.1 اختبار إجهاد جيد أيضاً 14:00 <+detonate> نعم 14:00 <+detonate> أنوي ذلك 14:00 <jrandom> بالطبع، ينبغي فقط لمن يملكون نسخاً قانونية من تلك الملفات تنزيلها. هذا لأغراض الاختبار فقط 14:00 <jrandom> *سعال* 14:00 <tracker> هههه 14:01 * jrandom يشير إلى mpaa.i2p 14:01 <+detonate> هه 14:01 <laberhorst> أوه، أستطيع إنشاء صور ISO من Debian وFedora وSUSE وصور التقطتها بنفسي,... 14:01 <laberhorst> إذن الكثير من المواد القانونية 14:01 <laberhorst> إذا كنت تريد فقط الاختبار، فإن /dev/random كبير جداً 14:01 <Ragnarok> ليس دائماً 14:02 <laberhorst> بالمناسبة، لعطلات نهاية أسبوع وحيدة: cat /dev/random | grep linux :-) 14:02 <jrandom> هه 14:02 <frosk> /dev/random يفرغ طوال الوقت، أفضل /dev/urandom :) 14:02 <frosk> أو /dev/jrandom الجديد والمحسّن 14:02 <jrandom> لا، ذاك يُسقط اللب (core dump) طوال الوقت 14:03 <jrandom> ويحتاج إلى راحته الليلية 14:03 <Ragnarok> ما أفضل طريقة لتوليد العشوائية لـ /dev/random؟ 14:03 <laberhorst> ينبغي حقاً أن نبني صندوق 'اشتروا بعض الجعة لـ jrandom' 14:03 <frosk> سمّها راحة أو جمعاً للعشوائية :) 14:03 <hobbs> Ragnarok: يعتمد على ما تعنيه حقاً. الحصول على مولّد أرقام عشوائية hardware سيكون بطريقة ما 'أفضل' طريقة :) 14:03 <jrandom> Ragnarok: يعتمد على نظام التشغيل لديك (وما إذا كان لديك hardware ;) 14:04 <tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 دائماً لطيف ;) 14:04 <jrandom> سنقوم فعلياً بدمج تطبيق fortuna في أحد هذه الإصدارات، وسنحتاج للتنقيب عن مصادر عشوائية متنوعة 14:04 <Ragnarok> بدون hardware :P 14:04 <susi23> . o O ( ظننت أن شخصاً يستخدم i2p يعرف لماذا لا ينبغي له استخدام /dev/urandom ) 14:05 <cervantes> tracker: الثغرات الأمنية التي تُغطّيها 2.0.12 يقوم mod_rocinante الخاص بي بإصلاحها دون قصد، لذا لم أكترث للترقية بعد 14:05 <hobbs> susi23: عندما يكون الأمر للعبث فحسب، أظن أنه لا بأس ;) 14:05 <ant> <Nolar> من هنا يعمل على منفذ BT بلغة Python؟ 14:05 <jrandom> Nolar: ذاك سيكون duck 14:06 * duck يصفر 14:06 <ant> <Nolar> duck: لماذا غيرتم حجم كتلة الطلب إلى 128k؟ 14:06 <susi23> . o O ( التالي سيقترح: while true; do echo $RANDOM>> largefile; done ) 14:06 <ant> <Nolar> لهذا لا يستطيع az النشر إليك 14:06 <tracker> cervantes: حسناً 14:06 <ant> <Nolar> نحن نحجب الطلبات> 64k 14:06 <laberhorst> اللعنة، أحتاج مزيداً من mp3 14:06 <frosk> susi23: للتفتيش عن linux في مساء كسلان، /dev/urandom مناسب تماماً :) 14:07 <jrandom> آه، وهل كنتم دائماً كذلك؟ إذا لم تخني الذاكرة فإن i2p-bt استخدم 128k لفترة 14:08 <ant> <Nolar> نعم، موجود منذ البداية :) 14:08 <ant> <Nolar> هل هناك سبب لاستخدام 128؟ 14:08 <ant> * duck يتصفح سجل CVS 14:08 <jrandom> يبقي الـ pipeline ممتلئاً، لدى i2p بعض التأخير ;) 14:08 <jrandom> مع 32KB، يكون ذلك عملياً حجم نافذة ثابتاً مقداره 1 14:09 <jrandom> لذا كل رسالة تنتظر ACK، بينما 128KB يسمح لأربع رسائل بأن تطير ضمن الـ RTT 14:09 <@duck> صحيح، أقصى حجم مسموح للشريحة وفق مواصفات BT 14:09 <ant> <Nolar> حسناً، هناك طريقتان للتعامل مع هذا: 1) نرفع الحد إلى 128k من جهتنا، أو 2) تقومون ببساطة بعمل pipelining لمزيد من الطلبات 14:09 <cervantes> i2pbt صار أسرع قليلاً مما كان... ربما يمكنكم تحمل تقليله... 14:10 <@duck> schni, schna, schnappi 14:10 <ant> <Nolar> لذا، بدلاً من إرسال طلب واحد 128k، أرسل مثلاً طلبين 64k 14:10 <hobbs> duck: ههه... ذلك الشيء انتشر حول العالم. 14:10 <@duck> لماذا تحجبون 128k؟ 14:11 <cervantes> *قشعريرة* بوب أوروبي 14:11 <laberhorst> duck: من فضلك اصمت وإلا أسقطك! 14:11 <tracker> أحياناً أندم أنني تعلمت الألمانية قبل سنوات... 14:11 <laberhorst> لا بوب أوروبي، حقاً ليس POP 14:11 * cervantes يأمر المملكة المتحدة بصدّ الحدود قبل أن تدخل أغنية كهذه إلى القوائم 14:11 <laberhorst> tracker: لا تهتم، لا بأس 14:12 <ant> <duck> الآن هو (2^17)-13 14:12 <ant> <Nolar> duck: حسناً، الحد موجود منذ فترة، لكن سبباً وجيهاً هو أن كتل 128K تستغرق وقتاً في الرفع..... 16KB (إعدادنا الافتراضي) يسمح بتحكم أدق في الطلبات 14:12 <ant> <duck> الـ 13 بايت هي طول أمر BitTorrent 14:12 <ant> <duck> لن تكون هناك مشكلة في (2^16)-13 14:12 <laberhorst> بعض الموسيقى سخيفة فعلاً، لكن الموسيقى الصناعية الحقيقية، به، لا 14:13 <ant> <duck> أو نعود إلى الإعداد الافتراضي؟ 14:13 <jrandom> تقليصه إلى 64KB يبدو الأبسط (هل هذه معلمة CLI حالياً؟) 14:13 <ant> <duck> --download_slice_size 14:14 <ant> <Nolar> حسناً، سؤالي: هل لديكم سبب مقنع للتمسك بكتل 128K، إذ تبدو كبيرة بعض الشيء لي، خاصةً لـ i2p 14:14 <ant> <Nolar> بدلاً من مجرد عمل pipelining لطلبات أصغر متعددة؟ 14:14 <ant> <duck> ليس لدي سبب. 14:14 <tracker> laberhorst: أحياناً ألتقط بعض القنوات الألمانية عبر الأقمار. خصوصاً Viva وذلك "Theater Kanal" مروّعان حقاً... 14:15 <ant> <Nolar> إحدى مشاكل الكتل الكبيرة أنه بمجرد أن أقوم بـ choke لك، لا يزال عليّ إكمال إرسال تلك القطعة 128k 14:15 <jrandom> لا أذكر ما إذا كان BT القياسي يعرف كيفية الـ pipelining، لكن ينبغي أن يكون بسيطاً بما يكفي (خاصة بما أنني لست من ينفذه ;) 14:15 <ant> <Nolar> ما قد يستغرق وقتاً 14:15 <laberhorst> tracker: Viva ممتعة فقط وقت 'الهارد روك'، أما بقية الأوقات 'يرجى التجاهل'، وأما القناة المسرحية فلا أعلم 14:15 <jrandom> مع i2p، 128KB ليست كبيرة فعلاً، إذ هناك تأخير متأصل بمستوى الثواني 14:15 <ant> <Nolar> ما قد يربك الـ chunk/unchoke 14:16 <@duck> jrandom: هل لا يزال من المنطقي طرح الـ 13 بايت العامة لـ BitTorrent كي تلائم رسالة SAM؟ 14:16 <jrandom> duck: لا، لأن مكتبة البث تقلّصه بالفعل أكثر إلى رسائل 16KB، لذا اجعلها فقط 64KB 14:17 <@duck> حسناً، إذن 2**16 14:17 <jrandom> (ثم تقوم tunnels بتقسيم رسائل 16KB تلك إلى شظايا بحجم 996 بايت..) 14:17 <ant> <Nolar> المشكلة مع 128k أنه إذا كنت أرفع مثلاً بسرعة 12 k/s، فسيستغرق الأمر أكثر من 10 ثوانٍ لإنهاء تلك الكتلة 14:18 <cervantes> واو هذا بطول تأخير irc تقريباً... 14:18 <jrandom> وهو 1-10 من RTTs (بينما على الشبكة العادية، 10-500) 14:18 <+detonate> كنت مستعداً تماماً لاستخدام كتل 512K 14:18 <ant> <Nolar> قد تجرّب أيضاً عمل pipelining لكتل 16KB 14:18 <jrandom> هه 14:18 <+detonate> إذن 64 مفضّل؟ 14:19 <ant> <Nolar> كل عملاء BT بحسب علمي يستخدمون كتل 16KB 14:19 <ant> <duck> تم الإصلاح في CVS؛ 14:19 <jrandom> روعة، شكراً duck! (وNolar!) 14:19 <ant> <duck> توقّع ظهوره في إصدار 0.1.8 مع بعض ضبط SAM وI2CP 14:19 <tracker> laberhorst: اسمه الكامل "ZDF Theater" أو شيء من هذا القبيل. وبحكم قولهم يقدّمون برنامجاً ثقافياً رفيع المستوى. آمل حقاً ألا يكون ما يقدّمونه أفضل ما لدى الثقافة الألمانية ;) 14:19 <jrandom> حسناً، هه، تذكرت للتو أننا لا نزال في اجتماع 14:19 <jrandom> هل لدى أحد آخر شيئاً للاجتماع؟ 14:20 <ant> <Nolar> إذن إن أردنا كتلة 128k، نصنع 8 طلبات متزامنة 14:20 <susi23> . o O ( ونتجاهل الـ 448 بايت المتبقية؟ ) 14:20 <jrandom> صحيح صحيح 14:20 <laberhorst> tracker: أوه، تلك قناة جانبية صغيرة... Arte أو 3sat أكثر إثارة للاهتمام حقاً 14:20 <laberhorst> وArte ألمانية/فرنسية :-) 14:20 <ant> <Nolar> إذا كان الرافع يستطيع تلبية مثل هذا الطلب، فينبغي دفع كامل 128k ضمن تدفق أنبوب i2p 14:20 <jrandom> جميل 14:21 <cervantes> . o O ( يتساءل لماذا يستطيع سماع كل ما تفكر فيه susi ) 14:21 <ant> <Nolar> لذا قد يستحق الأمر تجربة أحجام كتل 16KB مقابل 32KB مقابل 64KB 14:21 <jrandom> أجل 14:21 <jrandom> ما دام هناك pipelining، فـ i2p لا تكترث 14:21 <ant> <Nolar> رائع 14:22 <jrandom> لكن السرعة عند 16KB دون pipelines سيئة جداً، أو على الأقل كانت كذلك 14:22 <tracker> laberhorst: حسناً، سأحاول إن كان بإمكاني التقاط Arte في الأيام القادمة... 14:22 <ant> <duck> أقترح ترك هذا الضبط إلى 0.2 14:22 <ant> <duck> لأنه سيتضمن تحسينات BitTorrent 3.9.1 14:22 <jrandom> نعم، DTSTTCPW 14:22 <susi23> . o O ( أوه هذا سهل... الناس متوقعون جداً... ) 14:23 <ant> <duck> ما قد يعيد هيكلة كود الشبكة بالكامل 14:23 <cervantes> http://www.gavelstore.com 14:24 <jrandom> حسناً، أظن أن هذا كل شيء حالياً، على الناس تفقد القائمة والموقع بعد بضع ساعات إذ ستصدر نسخة 0.5.0.1 قريباً 14:24 <ant> <Nolar> نعم، أستطيع أن أرى كيف أن طلبات 16KB المفردة ستكون بطيئة 14:24 * jrandom ينزّل مطرقة 14:24 * jrandom *baf* يغلق الاجتماع