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

16:29 <jrandom> 0) مرحباً 16:29 <jrandom> 1) 0.6.1.2 16:29 <jrandom> 2) I2PTunnelIRCClient 16:29 <jrandom> 3) Syndie 16:29 <jrandom> 4) I2Phex 16:29 <jrandom> 5) Stego وdarknets (re: flamewar) 16:29 <jrandom> 5) ??? 16:29 <jrandom> 0) مرحباً 16:29 <@cervantes> (6) 16:29 <+postman> تقصد 6)؟ 16:29 <jrandom> نعم، لا أستطيع العدّ ;) 16:30 * postman يصطدم كفّاً بكفّ مع cervantes 16:30 <jrandom> تم نشر ملاحظات الحالة الأسبوعية على @ http://dev.i2p.net/pipermail/i2p/2005-October/000990.html 16:30 <wiht> يجب أن تكون الأسئلة البند 6. 16:30 <jrandom> بما أنني تأخرت 30 دقيقة، فأنا متأكد أنكم قرأتم تلك الملاحظات سلفاً، فلنبدأ إذن ;) 16:31 <jrandom> 1) 0.6.1.2 16:31 <@cervantes> 6) مناقشة سوء توقيت رفيق سكن jrandom 16:31 <jrandom> سعال* ;) 16:31 <jrandom> حسناً، كما ذُكر في البريد، يبدو أن إصدار 0.6.1.2 يعمل بشكل جيد 16:32 <jrandom> وجدنا العلة التي أبقت خوادم irc على بناء قديم، وهي الآن محدّثة أيضاً (w00t!) 16:32 <+postman> :) 16:32 <wiht> بالحديث عن ذلك، في netDB على وحدة تحكم الـ router، هل يمكن عرض جدول بالـ routers وإصداراتها في أعلى الصفحة؟ 16:33 <jrandom> عدد الـ routers لكل إصدار، صحيح؟ بالتأكيد، هذا ممكن بسهولة، ربما ندمجه في جدول peers.jsp (عرض الإصدار لكل نظير) وجدول جديد في الأسفل؟ 16:34 <jrandom> من اللطيف رؤية 9 إصدارات تعمل بانسجام، رغم أن الأحدث بالطبع يعمل أفضل 16:35 <jrandom> حسناً، هل لدى أحد شيء بخصوص 1) 0.6.1.2؟ 16:35 <+postman> أحد أجهزة الـ router لدي يعرض 1080 معروفاً 16:35 <jrandom> واو 16:35 <+postman> أظن أن هذا خارج المسار قليلاً؟ 16:35 <jrandom> هل ذاك على 0.6.1.2؟ 16:35 <+postman> نعم، أعتقد ذلك 16:36 <jrandom> همم، نعم، هذا... عالٍ قليلاً. أنا أرى حوالي نصف ذلك الآن 16:36 <+Complication> بثبات نحو 400 هنا 16:37 <+bar> كذلك هنا 16:37 <wiht> أرى 260 router معروفاً. 16:37 <jrandom> postman: ربما يمكننا التعمق فيما يجري على ذلك الـ router بعد الاجتماع (هل يمكنك أن ترسل لي tar.bz2 لـ netDb/routerInfo-*؟) 16:38 <+postman> jrandom: نعم، شكراً 16:38 <jrandom> gracias 16:38 <jrandom> نعم، ليس الجميع سيرى كل مرجع netDb، لذا من الطبيعي أن يكون هناك تذبذب 16:40 <jrandom> حسناً، إن لم يكن هناك شيء آخر حول 1) 0.6.1.2، فلننتقل إلى 2) I2PTunnelIRCClient 16:40 <@cervantes> عمل جميل يا dust 16:40 <jrandom> كما ذُكر في البريد، لدينا مرشّح جديد خاص ببروتوكول IRC متاح في CVS، وسيتم اعتماده كافتراضي في المراجعة القادمة 16:41 <+postman> رائع 16:41 <jrandom> نعم، هذا رائع فعلاً، الناس يطلبون شيئاً كهذا منذ زمن 16:41 <+Myo9> Jrandom، أصبحت أكثر انفتاحاً مؤخراً، عرفنا عن حبيبتك السابقة، والآن رفيق سكنك، إلخ. تذكّر: http://www.navysecurity.navy.mil/st031204.webp 16:41 <jrandom> سعال* 16:42 <dust> إذا أردت أن ترى ما يرسله عميلك يمكنك إضافة net.i2p.i2ptunnel.I2PTunnelIRCClient=INFO ثم النظر إلى السجلات لترى كل شيء 16:43 <dust> اختبرتُ بعض العملاء لكن هناك الكثير.. 16:43 <jrandom> نعم، راقبته قليلاً، لكن التصفية تبدو سليمة 16:44 <jrandom> وهناك أشياء لطيفة قد نفعلها لاحقاً أيضاً - مثلاً تنفيذ PING/PONG محلياً لتقليل نشاط الشبكة 16:44 <+Complication> dust: شكراً على "المعلومة" :) 16:44 <+bar> رائع يا dust، شكراً جزيلاً 16:44 <wiht> هل يعني هذا أننا لا نحتاج إلى إعداد tunnel IRC إضافي؟ 16:44 <jrandom> wiht: لا، ستحتاج إلى tunnel IRC، لكنه يمكن أن يحل محل الذي تستخدمه بالفعل 16:45 <+Complication> wiht: فقط أقلق أقل بشأن أن عميل IRC يفضحنا 16:45 <jrandom> postman/cervantes: أي أفكار حول زيادة أو إزالة مهلات ping/pong على الخادم؟ 16:45 <wiht> هذا يفسّر الأمر، شكراً. 16:46 <+postman> ممم، لن أزيلها، عميلِي خرج عن السيطرة تماماً عندما لعبتُ بها 16:46 <jrandom> postman: حسناً، أفكّر إن هو ردّ عليها محلياً، بحيث يحصل العميل على PING/PONG سريعين جداً جداً 16:46 <@cervantes> postman: يمكن للـ proxy أن يرد على الـ pings 16:46 <jrandom> (لكن الـ ping/pong لن يذهبا عبر الشبكة) 16:47 <jrandom> لا أعرف الأثر، لكن قد يستحق النظر. 16:47 <@cervantes> لكن لست متأكداً كيف ستتفاعل الخوادم، قد ينتهي بك الأمر بعملاء زومبي 16:47 <+postman> jrandom: حسناً 16:47 <jrandom> حسناً، آلية keepalive في مكتبة البث تتكفّل بذلك 16:47 * Complication اختبر أحياناً التحوّل إلى زومبي 16:47 <jrandom> Complication: مؤخراً؟ 16:47 <+postman> jrandom: إذا كان الـ proxy يرسل ping بالنيابة عن العميل، فيجب على الـ proxy أيضاً أن يرسل ping/pong للعميل 16:48 <+Complication> قبل أسبوع، أظن. 16:48 <jrandom> postman: الـ PING من العميل إلى الـ proxy سيجعل الـ proxy يرد مباشرةً على العميل بـ PONG دون إرسال أي شيء عبر i2p 16:48 <+Complication> لكن "نسختي" سقطت في النهاية. 16:48 <@cervantes> jrandom: سيتم إبقاء الاتصال مفتوحاً... سيتعيّن على الخوادم خفض عتبتها لتحديد متى يصبح العميل خاملاً ويحتاج للطرد 16:48 <jrandom> Complication: آه، خوادم irc لم تكن محدّثة حينها، لا ينبغي أن يحدث ذلك بعد الآن 16:49 <+Complication> دون أن أستخدم "ghost". الاستخدامات الأخيرة لأمر ghost كانت بسبب التشغيل مع العديد من العُقَد. 16:49 <+postman> jrandom: وماذا عن قياس التأخير (lag)؟ 16:49 <jrandom> cervantes: صحيح. وإن لزم، يمكن للـ proxy أن يحقن رسالة PING إضافية إلى الخادم إذا /احتاج/ واحدة. 16:49 <+postman> أجدّه مفيداً لمعرفة إن كنت متأخراً أم لا 16:49 <jrandom> postman: وأنا كذلك، لكن يمكنك دائماً /msg نفسك 16:50 <dust> ربما يمكنك تقليل عدد الـ pings 16:50 <jrandom> سيوفر ذلك قدراً كبيراً من عرض الحزمة، إذ أن رسائل الـ tunnel عبارة عن كُتل بحجم 1024byte، تُرسل عبر 2*k+1 قفزات 16:50 <jrandom> ذلك أيضاً 16:50 <jrandom> لا أعلم، مجرد فكرة. ما لدينا الآن ممتاز على أي حال 16:51 <+postman> حسناً، سأحاول ترقيع خادم اختبار 16:51 <@cervantes> ربما ننظر في تقليل العدد... لكن أرى أنه يجب أن نرسل بعض الـ pings الحقيقية لمعرفة ما إذا كان العملاء لا يزالون أحياء 16:51 <+postman> ربما ينجح 16:51 <jrandom> يبدو معقولاً يا cervantes. لا أظن أنه يحتاج أي ترقيع على الخادم، آمل ذلك؟ 16:52 <+postman> jrandom: لتعطيلها ربما - لكن خفض الفترة هو معامل إعداد 16:53 * postman يتعمّق في قراءة توثيق ircd (مرة أخرى) 16:53 <jrandom> رائع، لا عجلة. مجرد شيء يمكننا النظر فيه لاحقاً 16:53 <@cervantes> class servers 16:53 <@cervantes> { 16:53 <@cervantes> pingfreq 120; 16:54 <@cervantes> class clients { pingfreq 90 } 16:54 <@cervantes> هذا إعدادي الحالي 16:54 <+postman> cervantes: نعم، أعلم - السؤال هل يمكن تعطيلها من الأساس 16:54 <@cervantes> لن أعطّلها... فقط أنظر في تقليلها 16:55 <+postman> حسناً، لنبدأ بذلك 16:55 <+postman> cervantes: ما رأيك بـ 180 ثانية؟ 16:56 <@cervantes> نغامر من البداية بـ 240 16:56 <@cervantes> لكن ربما يجب أن نجهّز جانب ircproxy أولاً 16:57 <@cervantes> *نناقش بعد الاجتماع* 16:57 <+postman> متفق 16:57 <jrandom> w3rd. حسناً، هل هناك شيء آخر حول 2) I2PTunnelIRCClient، أم ننتقل إلى 3) Syndie؟ 16:57 <@cervantes> أي شيء يقلّل متوسط حركة مرور الـ router لدي 40kb/sec ;-) 16:58 <jrandom> هاها، لسبب ما أشك أن كل ذلك من irc ;) 16:58 <jrandom> حسناً، نتحرك قُدماً 16:59 * cervantes يخفي تنزيلات فيديوهات المهر التي ظل يشفطها من jrandom طيلة الأسبوع 16:59 <@cervantes> is=the 16:59 <+postman> LOL 16:59 <jrandom> كما ذُكر في البريد، هناك أشياء رائعة تحصل مع syndie 16:59 <jrandom> واجهة سطر الأوامر (CLI) بسيطة، لكن أداة Sucker الجديدة من dust تبدو واعدة جداً 16:59 <jrandom> dust: هل تودّ أن تعطينا لمحة؟ 17:00 <dust> أوه، 17:01 <dust> حسناً، يستخدم rome لتحليل الخلاصات ثم يحوّلها إلى sml، كما وُصف في مدوّنة jrandom 17:02 <dust> ليس بالمتانة التي قد تُسمّيها بعد، لكنه عمره يومان فقط :) 17:02 <dust> لدي بعض Dilbert في syndie الخاص بي.. 17:02 <dust> :) 17:02 <dust> . 17:02 <jrandom> جميل 17:03 <jrandom> حسناً، ما رأيك باتجاهه - هل ندمجه في مصدر syndie ونوفره كـ CLI، أم نُبقيه منفصلاً ونوزّعه مستقلاً، أم شيء آخر؟ 17:04 * dust لا يعلم، قرّر أنت 17:04 <dust> كلما قلّت الأدوات المنفصلة كان أفضل 17:04 <jrandom> نعم، ربما أسهل أن نحزمه كله معاً، هكذا يعرف الجميع أنهم يستطيعون استخدامه 17:05 <jrandom> حينها سنتمكن من دمجه في واجهة الويب، وربما في مجدول Ragnarok (التبادُل مع عُقد أخرى والسحب من rss/atom/إلخ) 17:07 <jrandom> حسناً، هل لدى أحد أسئلة/تعليقات/مخاوف حول 3) Syndie؟ 17:07 <wiht> إذا واصلتُم دمج البرمجيات في I2P، فقد يتحوّل إلى حزمة منتفخة. 17:07 <wiht> بالطبع، أستطيع إيقاف Syndie إذا لم أكن أستخدمه. 17:08 <jrandom> حزمة تطوير i2p حجمها 13 ألف سطر كود (13KLOC) 17:08 <jrandom> وـ i2p router هو فقط 22 ألف سطر كود 17:08 <jrandom> لكن نعم، هناك أثر على زمن تنزيل المُثبّت 17:09 <jrandom> إن أراد أحد، يمكنه بناء router مُقلّم بلا تطبيقات عميل، باستخدام فقط router.jar و jbigi.jar و i2p.jar 17:09 <wiht> نعم، كنت أشير إلى التنزيل. 17:09 <jrandom> (لكن يكون أكثر فائدة حين تتوفر واجهة ويب للتحكم به، وi2ptunnel، ومكتبة البث، إلخ ;) 17:11 <jrandom> smeghead كان يعمل على نظام توزيع (مثل emerge، لجافا)، وهناك أيضاً جماعة jpackage 17:11 <jrandom> إن أراد أحد أن يبحث في طريقة سلسة وموثوقة لإدارة التطبيقات بدون حزم مدمجة، فسيكون ذلك رائعاً 17:12 <jrandom> حسناً، إن لم يكن هناك شيء آخر حول ذلك، فلنقفز إلى 4) I2Phex 17:13 <jrandom> لا أملك الكثير لأضيفه بخلاف ما في ملاحظات الحالة 17:13 <jrandom> redzara: هل أنت هنا؟ 17:13 <+redzara> نعم أنا هنا 17:13 <+redzara> أنا أعمل بالفعل على الإصدار التالي، بينما أنتظر الاجتماع مع Gregor. 17:13 <jrandom> رائع 17:13 <+redzara> العمل، حالياً، يتكون بالأساس من تحديد الفروق والاحتياجات المرتبطة باستخدام I2P مثل مثلاً tcp/udp مقابل i2p، إدارة المعاملات الخاصة بـ I2P (وإدارة تحديث هذه المعاملات نفسها وقت الإصدارات القادمة، ...) نقل GWebCache إلى I2P، استخدام RSS أم لا، استخدام push أم لا... 17:14 <+redzara> لدي الكثير من التوثيق والشفرة لأقرأها 17:15 <jrandom> واو، نعم، يبدو كثيراً. أخبرني إن كان لديك أي أسئلة بخصوص تكامل i2p، أو إن أردت فقط من تتبادل معه الأفكار 17:16 <jrandom> جعل جزء I2Phex إضافة (plugin) لـ Phex الرئيسي سيكون رائعاً بحق 17:17 <jrandom> حسناً، هل لدى أحد شيء آخر حول 4) I2Phex؟ 17:18 <+redzara> سأحتاج بالتأكيد مساعدة في جزء petname 17:19 <+redzara> وربما أيضاً في الضبط الدقيق لمعاملات الـ tunnels 17:19 <jrandom> جميل، التسمية سهلة جداً - وعلى مستوى أساسي، يمكنك حتى الاستغناء عن الأسماء تماماً (هكذا يفعل I2Phex الآن) 17:20 <jrandom> إعداد الـ tunnel لا ينبغي أن يكون مشكلة أيضاً، رغم أن هذا يثير فكرة أن Phex قد يحتاج إلى قسم "إعدادات متقدمة" للإضافات 17:20 <jrandom> (سنحتاج بالطبع إلى قيم افتراضية جيدة على أي حال) 17:21 <+redzara> ربما شيء مثل ircclient، مرشّح لضمان ذلك 17:22 <@cervantes> من الأفضل تجهيز التطبيق نفسه برأيي المتواضع 17:22 <jrandom> قد ينجح ذلك، رغم أن التعامل مع تسلسلات بايت عشوائية قد يكون صعباً 17:23 <jrandom> مع ذلك، قد يتيح proxy مثل ircclient لأي عميل gnutella استخدامه. لكن سيكون عملاً كثيراً. 17:23 <+redzara> همم، مجرد فكرة ;) 17:23 * jrandom لا يعرف البروتوكول جيداً بما يكفي ليقول ما هو النهج الأفضل، لذا أقترح اتباع أبسط شيء قد ينجح :) 17:25 <jrandom> حسناً، إن لم يكن هناك شيء آخر، ربما نمر سريعاً على 5) stego وdarknets 17:26 <jrandom> لست متأكداً إن كان لدي ما أضيفه عما يُقال في القائمة (والنقاش الأساسي ربما يجب أن يستمر هناك) 17:27 <jrandom> ومع ذلك، هل هناك شيء تودون طرحه حول القضايا المثارة؟ 17:27 <wiht> ذُكر Freenet إصدار 0.5 و0.7 في النقاش. هل هناك إصدار 0.6 لـ Freenet؟ 17:27 <jrandom> 0.6 هو فرع الشبكة "غير المستقر" لديهم حالياً 16:27 <jrandom> بحسب علمي 17:27 <+postman> أوه وكنت أظن أنه اختُطف بقوى فضائية 17:28 <jrandom> رغم أن لوم الفضائيين رهان آمن عادةً، هذه إحدى الحالات القليلة التي لا يكونون فيها مذنبين 17:28 <+postman> :) 17:28 <wiht> كان Toad يتحدث عن القدرة على حصاد عناوين IP لعُقد I2P أو FreeNet، صحيح؟ 17:28 <jrandom> من بين أمور أخرى 17:29 <wiht> أردت توضيح ذلك فقط، شكراً. 17:29 <jrandom> على الرحب. حسناً، هل لدى أحد شيء حول 5)، أم ننتقل إلى 6) القديم الجيد؟ 17:30 <+postman> حسناً، لدي شيء لـ 6) 17:30 <jrandom> اعتبرنا انتقلنا. 17:30 <jrandom> ما الأمر يا postman؟ 17:30 <+postman> رأينا جميعاً أن الـ proxies القادرة على مرشّحات خاصة بالبروتوكول جيدة ومطلوبة 17:31 <+postman> هل سيكون من المجدي التفكير في proxy عام 17:31 <+postman> يمكن تزويده بوصف للبروتوكول 17:31 <+redzara> أود تطبيقاً مثل cron يستخدم beanshell لتشغيل شيفرة Java ديناميكياً 17:31 <+postman> مع أمور للمراقبة/التصفية/الإخفاء 17:31 <+postman> مثل وصف XML للتصفية/التنقية 17:32 <+postman> بحيث لا نحتاج مصدراً جديداً بل مجرد ملف/ملف تعريف مرشّح جديد 17:32 <+postman> (مجرد سؤال إن كان يستحق التفكير فيه) 17:32 <jrandom> معقد جداً جداً يا postman. سيكون ممكناً استخدام lexer مثل javacc لبناء لغات إدخال وتطبيق يترجم تلك اللغة إلى صيغة الإخراج 17:32 <@cervantes> الصعب هو التقاط الأشياء التي تنحرف عن البروتوكول 17:33 <+postman> كانت مجرد فكرة لتحفيز العصف الذهني 17:33 <+postman> برأيي، proxy عام مع مرشّح/مُحلّل مُنمذج مفيد جداً 17:33 <wiht> هل تمكّن أحد من الاتصال بـ eepsites.i2p؟ حاولت عدة مرات الأسبوع الماضي، لكن دون نجاح. 17:33 <jrandom> wiht: حمّلته مرة، وهو نفسه eepsites.com 17:34 <jrandom> (أم هو .net؟ أم .org؟ لا أتذكر) 17:34 * wiht يزور eepsites.com 17:34 <jrandom> postman: إن استطاع أحد ابتكار شيء يعمل، فسيكون ذلك رائعاً 17:34 <+postman> jrandom: حسناً، سأفكّر بالأمر مع susi 17:34 <jrandom> w3wt 17:34 <+postman> jrandom: ربما نتخلى عنه الأسبوع القادم 17:35 <wiht> إنه eepsites.com، وهو محرّك بحث لـ eepsites. 17:35 <+postman> لكني حلمتُ أنه نجح 17:35 <+postman> :] 17:35 <jrandom> :) 17:36 * Complication يشتبه أن وصف كل الدقائق التي تحدث في البروتوكولات... يحتاج شيفرة، ولا شيء أقل من الشيفرة 17:36 <+Complication> (لأغلب البروتوكولات على الأقل) 17:36 <@cervantes> لا، فقط بعض regex الشريرة 17:36 <+postman> Complication: ربما هذا الاشتباه هو السبب الذي يمنعنا من مزيد من التحقيق 17:37 <+postman> Complication: لست متأكداً بعد، لكن الاشتباه وحده لن يريحني من هذه المسألة 17:37 <jrandom> حسناً، نقطة مهمة هنا شيئاً عرضه لنا dust - 17:37 * Complication يخشى regex قادرة على مثل هذه الأشياء 17:37 <jrandom> الشيفرة ليست مخيفة بالضرورة. 17:37 <+postman> أرأيت؟ :) 17:37 <+postman> لغة نمذجة مرشّحات جيدة ستفعل الشيء نفسه 17:38 <+postman> :) 17:38 <@cervantes> tcl؟ :) 17:38 <+Complication> يجب أن تكون جيدة فعلاً. 17:38 * jrandom يرى أن لديك خيولاً طائرة أيضاً يا postman ;) 17:38 * dust شعر أيضاً بالسوء لإعادة استخدام الشيفرة هنا وهناك 17:38 <+postman> jrandom: لا بقر :) 17:38 <jrandom> شيفرة تعمل >>> تحسينات نظرية في الشيفرة 17:39 <+postman> ممم 17:40 <+postman> شيء تعلمته من i2p 17:40 <wiht>>>> تعني "أفضل بكثير، كثيراً؟" 17:40 <+postman> لا تستسلم من أول نظرة 17:40 <jrandom> صدقت يا postman 17:40 <jrandom> نعم يا wiht 17:41 <jrandom> سيكون رائعاً فعلاً 17:41 <jrandom> حسناً، هل لدى أحد شيء يطرحه للاجتماع؟ 17:41 <+bar> حسناً، كيف يعمل IMAP يا postman؟ (قرأتُ عنه في المنتدى ولم أجرّبه بعد بنفسي) 17:41 <+postman> bar: جرّبه بنفسك - لا تقارير مستخدمين لدي بعد 17:41 * cervantes يدحرج جرساً على شكل مهر 17:42 <+bar> حسناً، سأفعل :) 17:42 <+postman> bar: وبالنسبة لي يعمل بشكل ممتاز :) 17:42 <jrandom> جميل 17:42 <+bar> رائع 17:42 <+postman> cervantes: أنت مهووس 17:42 <@cervantes> أنا؟! 17:42 <@cervantes> :) 17:43 <jrandom> حسناً، قبل أن نصل إلى علامة 90 دقيقة 17:43 * jrandom يستعد 17:43 * jrandom يُغلق الاجتماع بـ*baf*