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

16:10 <jrandom> 0) مرحباً 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet و I2P و الشبكات المظلمة (يا إلهي) 16:10 <jrandom> 3) هجمات الإقلاع (bootstrap) لـ Tunnel 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) مرحباً 16:10 * jrandom يلوّح 16:10 <jrandom> ملاحظات الحالة الأسبوعية منشورة على http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 16:10 <dust> رائع، يعمل الآن. شكراً Gregor 16:10 <cervantes> مرحباً 16:11 <+fox> <blx> أهلاً 16:11 <jrandom> حسناً، ننتقل إلى 1) 0.6.1.3 16:11 <jrandom> لقد حدثتم جميعاً بوتيرة جيدة، شكراً! 16:12 <jrandom> يبدو أن الأمور بحالة معقولة، وليس لدي الكثير لأضيفه إلى ما ورد في ملاحظات الحالة 16:12 <jrandom> هل لدى أحد أي أسئلة/تعليقات/مخاوف بخصوص 0.6.1.3؟ 16:13 <jrandom> حسناً إن لم يكن، فلننتقل سريعاً إلى 2) Freenet و I2P و الشبكات المظلمة (يا إلهي) 16:13 <cervantes> 609 أقراناً معروفين! 16:14 <cervantes> (w00t) 16:14 <jrandom> نعم، الشبكة تكبر 16:14 <+fox> <blx> يا إلهي! 16:14 * cervantes يجري مسابقة رهان حول كم من الوقت حتى نبلغ الألف الكبير 16:14 <jrandom> هه 16:14 <tethra> هههه 16:15 <tethra> هل نراهن بنقود رقمية؟ ;) 16:15 <cervantes> لكنه يُظهر مدى صلابة نواة i2p مؤخراً إذ تسارعت وتيرة انضمام المستخدمين 16:16 <cervantes> لا... jrandom قد تبرع بالفعل دون أن يدري بكل مال البيرة لهذا العام 16:16 <jrandom> ههه 16:16 <jrandom> حسناً، بخصوص 2)، لست متأكداً إن كان لدي شيء آخر لأضيفه للموضوع (أظننا قتلناه نقاشاً). هل لدى أحد أي أسئلة/تعليقات/مخاوف حوله؟ 16:18 <cervantes> كما قلت، إن لم يكن شيئاً آخر فقد حفّز بعض النقاشات الأمنية شبه المرتبطة أي 3) 16:18 <jrandom> إن لم يكن، يمكننا التقدم سريعاً إلى 3) هجمات الإقلاع (bootstrap) لـ Tunnel 16:18 <jrandom> نعم، هذا ما حدث 16:19 <jrandom> القضية التي طرحها Michael تُكمّي رؤية عامة كانت لدي، لكن من الجيد جعلها صريحة 16:20 <jrandom> ستكون هناك مناقشة إضافية حول الهجوم الأحدث في وقت لاحق هذا المساء (حالما أستطيع كتابة رد)، أما السابق فلا يبدو مشكلة كبيرة 16:21 <jrandom> هل هذا مفهوم للجميع، أم لدى الناس أي أسئلة أو مخاوف بشأنه؟ 16:22 <cervantes> هه... هذا يعني إما أن الجميع متقبل للوضع أو أنهم لا يفقهون كنه المشكلة 16:23 <cervantes> سأضع نفسي في فئة "الجهل نعمة" 16:23 <jrandom> هه إنه أساساً هجوم يكون فيه الأشرار هم نقطة النهاية الصادرة لكل Tunnel قمت ببنائه 16:23 <jrandom> الآن، عند بدء التشغيل، يكون "كل Tunnel قمت ببنائه" عدداً صغيراً جداً (مثلاً 0 أو 1 أو 2) 16:24 <jrandom> لكن بعد بضع ثوانٍ، يصبح العدد كبيراً بما يكفي ليحوّل (c/n)^t إلى رقم صغير جداً جداً 16:25 <tethra> (c/n)^t هي... 16:25 <jrandom> (هذا أحد الأسباب التي تجعلنا لا نُشغّل i2cp listener - وبالتالي، i2ptunnel/إلخ - إلا بعد فترة قصيرة من بدء التشغيل) 16:25 <jrandom> c == عدد الأقران المتواطئين (الأشرار)، n == عدد الأقران في الشبكة، t == عدد tunnels التي أنشأتها. 16:25 <cervantes> صحيح... 16:25 <tethra> آه 16:26 <jrandom> فمع ازدياد t، تصبح احتمالية نجاح الهجوم صغيرة جداً 16:26 <cervantes> إذاً لكي يكون قابلاً للتطبيق ينبغي أن تبدأ استخدام router لديك لمهام حساسة خلال دقائق قليلة من بدء تشغيله؟ 16:26 <jrandom> (أو، على أي حال، أصغر من احتمال الاستحواذ على كل القفزات في Tunnel) 16:26 <tethra> آه، فهمت 16:27 <jrandom> cervantes: فوراً، قبل بناء الـ Tunnel الثالث 16:27 <jrandom> (على افتراض أنك تستخدم tunnels من 3 قفزات) 16:27 <cervantes> هذا غير مرجح إلى حد كبير 16:28 <cervantes> فقط من منظور حالات الاستخدام 16:28 <jrandom> بالضبط. 16:28 <jrandom> وبما أننا نبني أكثر من 3 tunnels عند بدء التشغيل قبل السماح لأي عميل بالعمل، فالأمر ليس مجرد مسألة احتمالات 16:28 <jrandom> لكنه من الجيد تحديد الهجوم كمياً على أي حال 16:29 <cervantes> هل يجدر ترك router يعمل لفترة أطول للحماية من أي احتمال؟ 16:30 <cervantes> أو يعمل بجهد أكبر... 16:30 <jrandom> ربما. إذا تجاهلنا وقت إنشاء الاتصال وكذلك اختيار الأقران غير العشوائي، فلا احتمال له 16:31 <tethra> أهذا يستدعي "ووت!" كما أفهم؟ 16:32 <jrandom> نعم، مع أنه من منظور هندسي، لا ينبغي أن نتجاهل تلك الخصائص ;) 16:32 <jrandom> لذا، في 0.6.2 قد نرغب في النظر إليه أثناء إعادة تصميم اختيار أقران الـ Tunnel/ترتيبهم، للتأكد من أنه يتصرف بشكل معقول 16:34 <jrandom> حسناً، إن لم يكن هناك شيء آخر حول 3)، فلننتقل إلى 4) I2Phex 16:34 <jrandom> sirup ليس هنا، ولم أر striker على IRC - redzara، هل أنت موجود؟ 16:36 <+redzara> نعم 16:36 <+redzara> الاقتراب الأول شبه مكتمل: نقل تعديل Sirup إلى أحدث phex cvs. 16:36 <jrandom> جميل! 16:36 <+redzara> التالي: اقتراب ثانٍ: مقارنة كود Sirup مع كود phex الأساسي المستخدم في الإطلاق الأولي، للتأكد من أنني لم أنسَ شيئاً :) 16:37 <+redzara> ربما يكتمل هذا في عطلة نهاية الأسبوع 16:37 <jrandom> واو، سيكون ذلك رائعاً 16:37 <+redzara> الاقتراب الثالث: إعادة هيكلة طبقة الاتصالات مع GregorK 16:37 <+fox> <GregorK> آمل أنك على علم بأن كود التحميل الأخير في Phex CVS غير مستقر وملف التحميل غير متوافق مع الإصدارات السابقة 16:38 <jrandom> هذه I2P، نحن معتادون على عدم الاستقرار :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> بالنسبة للمرحلة الأخيرة، وبما أنه لا يوجد لدي تواصل حالياً مع GregorK، فسيكون هذا صعباً :( 16:38 <jrandom> GregorK: ما الذي توصي به للتكامل؟ 16:39 <+fox> <GregorK> حسناً لديك اتصال بي الآن ;) 16:39 <jrandom> آه، حسناً redzara، الأوليان كبيران بما يكفي على أي حال :) 16:39 <+redzara> GregorK: أهلاً يا رجل 16:40 <+redzara> GregorK: قرأت الشيفرة كلها بعناية 16:40 <+fox> <GregorK> لدي فكرة حول كيفية بناء طبقة... يمكنني محاولة تجهيزها بأفضل شكل ثم نرى مدى ملاءمتها وما الذي يحتاج للتغيير 16:40 <+fox> <GregorK> كلها؟؟ واو... 16:40 <+redzara> Gregork: نعم، كلها!! 16:41 <cervantes> حتى أنه يعرف مقاس ملابسك الداخلية 16:41 <Rawn> :D 16:41 <+fox> <GregorK> رائع... في المرة القادمة حين أتسوق سأحتاج فقط أن أسألك... 16:43 <+fox> <GregorK> سيكون من الجيد لو أمكن أن ينضم شخص من فريق i2phex إلى فريق phex أيضاً.. 16:43 <jrandom> redzara: إذاً، هل تظن أننا سنحصل على إصدار I2Phex 0.1.2 بنتائج الاقتراب الثاني قبل دمج كل شيء في طبقة Plugin ضمن Phex الرئيسي؟ أم سيكون ذلك دفعة واحدة؟ 16:43 <+redzara> آسف، لكنني لا أفهم/أتحدث/أقرأ/أكتب الإنجليزية بشكل جيد بما يكفي لأضحك مما كتبت 16:43 <+fox> <GregorK> هذا سيساعد أيضاً في حل العلل المشتركة على الجانبين 16:44 <jrandom> GregorK: نأمل أن نجد طريقة بحيث يكون جانب I2P مجرد Plugin خفيف في Phex، أليس كذلك؟ 16:44 <jrandom> أم تعتقد أنه ينبغي أن يبقيا منفصلين؟ 16:44 <+redzara> jrandom: أظن أنه يمكننا الحصول على Phex 2.6.4 فوق I2P، بالنسبة لي I2Phex انتهى 16:45 <jrandom> انتهى؟ 16:45 <+fox> <GregorK> لست متأكداً إن كنا قادرين على فعل ذلك من البداية، لكن أظن أن الجزء الأكبر يمكن فصله في Plugin. 16:45 <jrandom> رائع، نعم، إنها الكثير من العمل بلا شك 16:46 <jrandom> خاصة عندما تنظر إلى أشياء مثل java.net.URL (التي تُسرّب طلبات DNS عند الإنشاء، إلخ) 16:46 <+redzara> jrandom: انتهى، انتهى 16:46 <+Ragnarok> غrr 16:47 <jrandom> حسناً صحيح redzara، بمجرد أن نجعل كل شيء يعمل في Phex 2.6.4 فوق I2P، أتفق بأنه لن تكون هناك حاجة كبيرة لـ I2Phex 16:47 <+fox> <GregorK> صحيح... أظن أن Phex يستخدم فئة apache URI في بعض المواضع للتحايل على ذلك.. لكن فقط عند الضرورة 16:48 <jrandom> آه صحيح، أتذكر أنني لعبت مع تلك المكتبة، تبدو جيدة 16:49 <jrandom> بالتأكيد سنساعد في تدقيق الأمور قليلاً للسرية/الأمان قبل دفعها للمستخدمين النهائيين عبر i2p 16:49 <jrandom> (لا أقصد أن هناك مشاكل في Phex، فقط هناك مشاكل في كل تطبيق، ونأمل أن نساعد في حلها) 16:50 <+fox> <GregorK> لبعض الأمور مثل استخدام Socket وما شابه لدي فكرة حول كيفية دمجها بسلاسة... لكن أماكن أخرى مثل ميزات UDP وما شابه... لست متأكداً بعد من أفضل طريقة لحلها 16:50 <+fox> <GregorK> أوه أنا متأكد من أن هناك كثيراً من المشاكل في phex. :) 16:50 <jrandom> آه، نعم الـ sockets ستكون سهلة، لكن قد نحتاج لتعطيل أمور أخرى. بمَ يُستخدم udp - للاستعلامات السريعة؟ 16:51 <+fox> <GregorK> حالياً فقط لبدء الاتصال 16:51 <+fox> <GregorK> UDP Host Cache.. بديل لـ GWebCache 16:52 <jrandom> آه، حسناً. 16:52 <+redzara> إذاً لا نحتاجه إن كان لدينا GwebCache لائق؟ 16:53 <+fox> <GregorK> نعم... لكن GWebCache القياسي لديه مشاكله الأمنية أيضاً... 16:53 <+redzara> GregorK: ليس داخل I2P أظن 16:54 <jrandom> يمكن تجاوز ذلك - I2PSocket مُوثّق - أنت تعرف 'destination' للنظير في الطرف الآخر، لذا لا يمكنه القول "أنا، آه... whitehouse.gov.. نعم!" 16:54 <jrandom> لكنك محق، هذا شيء يحتاج للتحقق 16:54 <+fox> <GregorK> أيضاً نقلات firewall إلى firewall ستكون موضوع UDP نود تنفيذه بمجرد العثور على متطوع :) 16:54 <jrandom> آه، حسناً، I2P لا يحتاج نقلات firewall إلى firewall - I2P يوفّر فضاء عناوين مفتوحاً تماماً من طرف إلى طرف :) 16:55 <jrandom> لكن... أوه، هذا شيء قد يكون مفيداً 16:55 <jrandom> إذا كان لدى مستخدمي Phex "0 hop tunnels"، فسيحصلون على تجاوز NAT مجاناً/نقلات firewall إلى firewall بسرعة لا بأس بها 16:55 <+fox> <GregorK> أمر آخر هو بث LAN للاستعلامات وما شابه... لتسهيل مشاركة المحتوى في الشبكات الخاصة 16:56 <jrandom> (tunnels بدون قفزات (0 hop) تقدم مستوى من الإنكار المعقول دون أن تتطلب من أقران وسطاء حمل الحركة) 16:57 <jrandom> هممم، بث LAN جيد، لكن لست متأكداً أن i2p سيحتاج ذلك حقاً (إذ يمثل مخاطرة على اللاهوية معرفة مكان النظير :)، لذا ربما يمكن تعطيل تلك الميزة عند استخدام Plugin لـ I2P؟ 16:58 <cervantes> معطّلة افتراضياً* 16:58 <+fox> <GregorK> حسناً ليست متاحة بعد.. لكن في هذه الحالة المستخدمون عادة يعرف بعضهم بعضاً أصلاً لبناء تلك الشبكة الخاصة.. 16:58 <jrandom> صحيح cervantes 16:58 <jrandom> صحيح صحيح GregorK 16:59 <+fox> <GregorK> هل هناك أي تغييرات تتعلق بواجهة المستخدم؟؟ 17:00 <+bar> حسناً، لن نحتاج أعلاماً :) 17:00 <jrandom> على الأقل، ستكون القدرة على وجود بعض خيارات الضبط المتعلقة بـ I2P مفيدة. 17:01 <jrandom> أظن أن sirup تمكن من تبديل بعض العرض لاستخدام 'destinations' الخاصة بـ I2P بدلاً من إظهار IP + أرقام المنافذ، لذا أظن أن الأمر كان جيداً 17:01 <+redzara> وماذا عن bitzyNot حالياً، ولكن الأعلام والبلدان غير مستخدمة 17:01 <jrandom> bitzy؟ 17:01 <+redzara> آسف، نسخ/لصق خاطئ :( 17:02 <+fox> <GregorK> هل يمكنك تزويدنا بقائمة خيارات الضبط والميزات الاختيارية التي تحتاجونها؟ 17:03 <jrandom> بالتأكيد يمكننا ذلك. مضيف+منفذ يعمل عليه I2P وبعض القوائم المنسدلة المتعلقة بتحسينات الأداء/اللاهوية ينبغي أن تفي بالغرض 17:03 <jrandom> سنتولى تزويدكم بالتفاصيل 17:02 <cervantes> [x] وضع سرعة نقل فائقة 17:02 <+fox> <GregorK> حسناً bitzi تُستخدم للتعرّف على الملفات.. هل هذا يمثل مشكلة لللاهوية؟ 17:03 <vulpine> <redzara> GregorK: أنا أحضّرها، لكن أساساً لا تغييرات 17:03 <+fox> <GregorK> :) اسأل مزودك cervantes... 17:03 <redzara> GregorK: ربما، أنا أعمل على ذلك 17:04 <cervantes> GregorK: هه مقيم في المملكة المتحدة.... لا فرصة ;-) 17:04 <+fox> <GregorK> إذا نقلت ملفات بين مثيلي Phex على نفس الحاسوب.. فالنقلات سريعة كالبرق ;) 17:05 <cervantes> رائع... لدي الكثير من الأفلام الرائعة التي يمكنني مشاركتها مع نفسي :) 17:05 <cervantes> * احذف ذلك من محضر الاجتماع * 17:06 <bar> تطرق jrandom للموضوع سابقاً، لكن ها هي الفكرة المجنونة مجدداً: 17:06 <+bar> ما رأيكم بدمج i2p داخل Phex، بحيث يحصل المستخدمون العاديون على 0-hop tunnels؟ 17:07 <+fox> <GregorK> أظن أن عرض الأعلام و IP+المنفذ يأتي من كائن HostAddress.. والذي سيُخفى من الطبقة الجديدة.. لذلك يمكنك عرض شيء آخر 17:07 <+bar> (لأجل الإنكار المعقول وثقب الجدار عبر UDP خلف الجدران النارية) 17:08 <+fox> <GregorK> لست متأكداً إن كنت أفهم حقاً ما يعنيه ذلك ;) 17:08 <+bar> ربما أنا أيضاً ;) 17:09 <jrandom> GregorK: يعني ذلك أساساً أن مستخدمي Phex سيتحدثون مباشرةً مع بعضهم، لكن سيحصلون على إنكار معقول، إذ قد يكونون يتحدثون بشكل غير مباشر 17:09 <+bar> jrandom، أنا متأكد أنك فهمت قصدي هنا، هل يمكنك الإيضاح؟ 17:09 <jrandom> وسيحصلون أيضاً على تجاوز NAT في I2P مجاناً، بالإضافة إلى أمان البيانات والحماية من التنصت من قبل مزودي الخدمة/وغيرهم 17:09 <+redzara> GregorK: لذا عليك إزالة كل الكود المتعلق بـ host+port + IsLocalIP + Is PrivateIP + ... 17:10 <jrandom> من ناحية أخرى (ومهمة جداً)، لن يكون بالإمكان التحدث إلى عملاء gnutella الذين لا يعملون فوق I2P 17:10 <jrandom> (مع أنه في النهاية، سيعملون جميعاً ;) 17:10 <+fox> <GregorK> أظن أن الخطوة الأولى - وهي كبيرة بما يكفي - هي تقريب i2p و phex من بعضهما. 17:10 <jrandom> متفق 17:10 <+bar> (اللعنة، لم أفكر في ذلك) 17:11 <+bar> نعم، بالتأكيد. 17:11 <jrandom> هذا من قبيل أحصنة طائرة. دعونا ننجز الأمور العملية أولاً 17:11 <+fox> <GregorK> وبعد أن نرى مدى نجاح ذلك يمكننا تقرير كيف نمضي قدماً.. 17:11 <jrandom> بالضبط 17:12 <+fox> <GregorK> redzara: أود وجود تنفيذين لـ HostAddress أحدهما لـ i2p والآخر كالحالي. 17:14 <+redzara> Gregork: لا مشكلة، لقد علّقت كل الكود في تعديلي ويمكنك بناء تنفيذين بسهولة. فقط دعني أنهي العمل الأولي من فضلك 17:14 <+fox> <GregorK> بالتأكيد.. لا مشكلة.. 17:14 <jrandom> :) حسناً، إذاً redzara، هل تظن أننا قد نحصل على اختبار ألفا للإصدار الجديد المبني على Phex-2.4.2 في وقت ما الأسبوع القادم؟ 17:15 <jrandom> (لجزء المرحلة 2. أما المرحلة 3 لديك فستحتاج عملاً أكثر للدمج مع الفرع الرئيسي) 17:15 <+redzara> jrandom: التالي يبدو مناسباً لي 17:16 <jrandom> حسناً رائع 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> حسناً، هذا أمر مشوق فعلاً، سيكون رائعاً أن يسير بسلاسة 17:17 <jrandom> هل لدى أحد شيء آخر يطرحه بخصوص 4) I2Phex، أم ننتقل سريعاً إلى 5) Syndie/Sucker؟ 17:17 <cervantes> ستستفيد I2P بالتأكيد من مثل هذه التطبيقات القاتلة 17:18 <+fox> <GregorK> بالمناسبة هناك قائمة بريدية لـ Phex CVS لكل تغييرات CVS في Phex... إن كان ذلك مفيداً 17:18 <jnymo> أحم.. بالتأكيد 17:18 <jrandom> حسناً رائع، شكراً GregorK 17:18 <jrandom> بالتأكيد cervantes 17:19 <jrandom> حسناً، بخصوص 5)، لا أملك الكثير لأضيفه لما هو موجود 17:19 <jrandom> dust: هل أنت هنا؟ 17:19 <+redzara> GregorK: شكراً لكن التعامل مع نسخة واحدة كافٍ بالنسبة لي :) 17:19 <jrandom> ههه redzara 17:19 <dust> لم يكن لدي وقت فراغ كثير مؤخراً، لكن إن توفر فسأحاول فهم موضوع addresses.jsp هذا، إضافة 'RSS' في قائمة البروتوكول المنسدلة هناك ثم بناء مسار عبر Updater و Sucker إلى BlogManager. 17:20 <dust> إلا إن كان لدى أحد فكرة أفضل 17:20 <jrandom> رائع جداً 17:20 <jrandom> هذا يبدو مثالياً. 17:21 <jrandom> مع أن، هممم، قد يحتاج لحقل إضافي ("أي مدونة يُنشر فيها" و"ما بادئة الوسم")... 17:21 <jrandom> ربما نموذج/جدول منفصل سيكون منطقياً، وربما لا 17:22 <dust> أوه، ظننت أن addresses.jsp خاص بمدونة واحدة فقط (بما أنك تحتاج لتسجيل الدخول للوصول إليه؟) 17:22 <jrandom> آه، صحيح، نقطة جيدة 17:23 <jrandom> جزء المُحدّث غامض قليلاً، لكنك محق 17:23 <dust> (سنعرف ذلك عندما نصل إليه) 17:23 <jrandom> نعم 17:24 * jnymo يعتقد أن www.i2p.net يمكنه إطلاق شيء من نوع "مقهى منتجات" 17:24 <jnymo> بقمصان eyetoopie تقول "أنا Jrandom" ;) 17:24 * mrflibble ما يزال يلحق بـ "flamewar"، التي يبدو أنها تتحول إلى مشادة حقيقية :) 17:24 <jrandom> هه، jnymo 17:25 <jrandom> نعم، هناك الكثير من المحتوى في ذلك الخيط 17:25 <jrandom> حسناً، ربما هذا يأخذنا إلى 6) ??? 17:25 <jrandom> هل لدى أحد أي شيء آخر لطرحه في الاجتماع؟ 17:25 <+bar> نعم، ملاحظة سريعة حول مسألة NAT المتماثل (كنت أتقصّى قليلاً): 17:25 <+nickless_head> jrandom: أنا أعرف الحقيقة! 17:25 <+fox> <blx> kaffe؟ 17:25 <mrflibble> عذراً، آسف jr 17:26 <jnymo> لكن بجدية.. كل مشروع مفتوح المصدر بحجم ما لديه قسم منتجات خاص به 17:26 <+nickless_head> jrandom: لدي دليل قاطع أنك اخترقت الصفحة الرئيسية لـ last.fm! 17:26 <+nickless_head> (قسم "ما الذي تحصل عليه عند التسجيل" ذكر 'a pony') 17:26 <jrandom> jnymo: أظن أنك محق، سنرغب في استكشاف هذا المسار، قد يكون وسيلة جيدة لجمع التبرعات أيضاً 17:27 <jnymo> jrandom: بالضبط 17:27 * mrflibble سيشتري القميص 17:27 <+bar> حسناً، بخصوص NATs المتماثلة، 17:27 <+bar> حسب ما يستحق، أظن أنه بخلاف NATs المدعومة بالفعل، لا توجد خدعة سحرية. الطريقة الوحيدة لفعلها بشكل صحيح هي دراسة وفحص سلوك كل NAT متماثل على حدة واستخدام مُعرّفات (introducers) للاختبار. 17:28 <jrandom> blx: أحدث Kaffe CVS معطوب تماماً. حِزم التشفير غير موجودة في المصدر، و prng يفشل في التهيئة، ومعالجات URL لا تتعامل مع file:// :( 17:28 <jnymo> ربما لا ترغب بارتدائه علناً حتى يكون لدى i2p بضعة آلاف من المستخدمين ;) 17:28 <+bar> (أعتقد أن Hamachi و Skype يقومان بثقب الجدار عبر UDP من خلف NATs متماثلة بهذه الطريقة) 17:28 <+nickless_head> jnymo: الأكواب ستكون رائعة :) 17:28 <+bar> استناداً لما قرأته على الشبكة حتى الآن، خوارزميات توقع NAT المتماثل سيئة جداً. 17:28 <jrandom> هممم bar 17:28 <mrflibble> ههه، لن أضع لقبي عليها. أوه، وما زلت على قيد الحياة/غير معتقل رغم أن لدي قميص IIP 17:28 <jrandom> نعم، هذا ما قرأته أيضاً 17:29 <+bar> سأحاول جمع مزيد من المواد الجيدة والمرتبطة حول هذا. 17:29 <+redzara> سؤال صغير: ما كانت نسبة المتوسط الشائع للبايتات المُعادة الإرسال في 0.6.1.3؟ 17:29 <jrandom> شكراً bar 17:29 <+fox> <jme___> bar، هل تكون التوقعات التي يحصلون عليها متسقة؟ 17:29 <+fox> <jme___> bar، دعني أعيد الصياغة :) 17:29 <+fox> <blx> jrandom، هذا يحزنني سماعه 17:30 <jrandom> redzara: لسوء الحظ نسيت وضع ذلك في netDb. أرى 2.6 و 3.8 الآن بالمناسبة 17:30 <jrandom> blx: وأنا أيضاً :( 17:30 <+fox> <jme___> bar، عندما تحلل سلوك صندوق الـ NAT وتجد صيغة لتوقعه. هل تعمل دائماً لهذا الصندوق؟ أم أحياناً تعمل وأحياناً لا؟ 17:30 <jrandom> blx: أعلم أنهم يقومون ببعض الدمج مع classpath الآن، لذا نأمل بعد ترتيب ذلك 17:30 <+fox> <blx> ربما يعني أنني لن أنضم للحفلة 17:30 <jrandom> blx: هل أنت محدّد بـ kaffe، أم محدد بـ OSS/DFSG؟ 17:31 <+fox> <blx> برمجيات حرة 17:31 <+fox> <blx> DFSG يمكنك القول 17:31 <jnymo> في حال أراد مستخدم i2p استخدام خادم مستضاف لـ i2p، ما شركة الاستضافة المتساهلة والرخيصة التي يمكن اختيارها؟ 17:31 <+bar> jme___: يُقال إن hamachi قادر على التوسّط في 97% من كل محاولات الاتصال. أظن أن هناك NATs تُظهر سلوكاً شبه عشوائي عند إسناد المنافذ 17:32 <jrandom> حسناً، أنا متأكد أننا سنجعل شيئاً يعمل يا blx. كان kaffe يعمل سابقاً، ونحن لا نعتمد على أي شيء محدد بـ sun 17:32 <jrandom> jnymo: أستخدم sagonet.net، لكنهم رفعوا أسعارهم من 65/شهر إلى 99/شهر (لكن على وصلة سريعة مع 1250GB/mo) 17:32 <jrandom> أعلم أن هناك بعض المزودين الرخيصين في ألمانيا أيضاً 17:33 <+fox> <jme___> bar، 97% ستكون رائعة 17:33 <jrandom> redzara: ماذا ترى لنسبة إعادة الإرسال؟ 17:33 <+bar> jme___: نعم، لذا أظن أن معظم NATs المتماثلة قابلة للتوقع 17:33 <+fox> <blx> jrandom، آمل ذلك بالفعل. أنا مهتم حقاً بهذا الشيء :) 17:33 <+fox> <jme___> bar، ماذا ستفعل؟ ترحيل، ثقب الجدار عبر udp، عكس الاتصال.. هل هناك تقنيات أخرى؟ 17:33 <jnymo> هل 99 غالٍ، بالمعدل؟ 17:34 <+redzara> jrandom بين 3.8 و 4.2 17:34 <jrandom> jme___: نحن udp، لا حاجة لعكس الاتصال :) 17:35 <+bar> jme___: لست خبيراً، ربما سأحصل على مزيد من المعلومات لاجتماع الأسبوع القادم (لكن الأمر يبدو وكأنه نمذجة سلوك + ثقب الجدار عبر UDP ;) 17:35 <jrandom> jnymo: مقابل 1250GB، ليس حقاً. رأيت 60-120USD/mo مقابل 50-100GB/mo 17:35 <jrandom> bar: ربما يكون UPnP خياراً أفضل؟ 17:35 <+fox> <jme___> jrandom، حتى مع udp فهو مفيد :) 17:35 <+redzara> jrandom: لكن فقط بعض العُقد أحدثت أثراً كبيراً، ربما الأقدم 17:35 <+fox> <jme___> vulpine: حسناً 17:35 <jrandom> رغم أن ذلك يساعد فقط الأشخاص الذين يمكنهم التحكم في NAT لديهم 17:36 <+fox> <jme___> upnp يجب دعمه لكنه ليس بديلاً حصرياً عن الوسائل الأخرى 17:36 <jrandom> نحن نفعل كل ما نفعله الآن دون أي UPnP 17:36 <+fox> <jme___> لأن upnp غير مدعوم من كل NAT، بعيداً عن ذلك 17:36 <jrandom> صحيح، مثلاً NAT الخاص بمزود الخدمة 17:36 <+bar> jrandom: إن لم تكن هناك مشاكل أمنية مع upnp، فلا ضرر منه على ما أظن. مع ذلك، hamachi لا يستخدم upnp 17:36 <+fox> <jme___> هنا بـ'يجب' = لتوفير أقصى قدر من الاتصال 17:37 <+fox> <jme___> حسناً أعود إلى c++ :) 17:38 <jrandom> صحيح jme___، ومع أننا إن استطعنا تنفيذ ثقب الجدار لـ NATs المتماثلة بالإضافة إلى أنواع cone/restricted، فنحن في وضع ممتاز 17:38 <jrandom> لاحقاً jme___ 17:38 <jrandom> نعم، سيكون مثالياً إن لم نكن بحاجة إليه 17:39 <jrandom> حسناً، هل لدى أحد أي شيء آخر لطرحه في الاجتماع؟ 17:41 <jrandom> إن لم يكن... 17:41 * jrandom يستعد 17:41 * jrandom يعلن إغلاق الاجتماع *baf*