مراجعة سريعة
الحضور: ailouros, bar, bla, cervantes, Complication, gott, jrandom, modulus, polecat, Pseudonym, tethra, zzz
سجل الاجتماع
15:26 <jrandom> 0) مرحبا 15:26 <jrandom> 1) 0.6.1.7 وحالة الشبكة 15:26 <jrandom> 2) أعطال tunnel التجريبية 15:26 <jrandom> 3) SSU وNATs 15:26 <jrandom> 4) Syndie 15:26 <jrandom> 5) ??? 15:26 <jrandom> 0) مرحبا 15:26 * jrandom يلوّح 15:26 <jrandom> تم نشر ملاحظات الحالة الأسبوعية على http://dev.i2p.net/pipermail/i2p/2005-December/001237.html 15:26 * ailouros قرأ الملاحظات 15:27 * jrandom متأخر، لذا سأمنحكم لحظة للاطلاع :) 15:29 <jrandom> حسنًا، لننتقل إلى 1) 0.6.1.7 وحالة الشبكة 15:29 <@cervantes> *سعال* 15:29 <jrandom> ليس لدي الكثير لأضيفه أكثر مما في الرسالة بخصوص هذه النقطة. هل لدى أحد تعليقات/أسئلة/أفكار إضافية؟ 15:30 <Pseudonym> يبدو أن إجراء تحسينات الأداء قبل تغيير خوارزمية إنشاء tunnel قد يكون معكوسًا 15:30 <gott> I am getting a lot of "No HTTP method found in the request. 15:30 <gott> Software caused connection abort: socket write error 15:30 <gott> " 15:30 <@modulus> تأخر tunnel أقل بكثير، لا أدري إن كنت قد أجريت تغييرات أم أن مزود خدمتي أصبح أفضل فجأة. 15:30 <gott> من I2PTunnel Webmanager 15:31 <jrandom> gott: هذا يوحي بوجود طلبات HTTP سيئة، أو أشياء لم يتمكن eepproxy من فهمها 15:31 <jrandom> modulus: رائع، لقد قمنا بالكثير لمحاولة تحسين الأمور 15:31 <jrandom> Pseudonym: حسنًا، حتى الآن لم يكن إنشاء tunnel نقطة الاختناق لدينا — كانت نقطة الاختناق في أمور على مستوى أعلى بكثير 15:32 <jrandom> ومن ناحية أخرى، تحسينات الإصدارات القليلة الماضية كشفت بعض المشاكل هناك 15:32 <Pseudonym> أوه، إذًا كان التحسين متعلقًا بأجزاء أخرى من الشيفرة؟ 15:32 <Pseudonym> رائع 15:33 <jrandom> نعم، على مستوى SSU وكذلك على مستوى تشغيل tunnel. إنشاء tunnel ليس عملية حساسة للأداء [إلا عندما يكون كذلك ;] 15:34 <jrandom> أجري بعض اختبارات التحميل الحية على الشبكة، وأجمع إحصاءات تحميل غير مجهولة لأقران مختلفين لمحاولة تضييق النطاق أكثر 15:34 <ailouros> أتساءل لماذا أحيانًا أرى tunnels أكثر مما هو مُهيأ لوجهة ما (مثلًا eeProxy، inbound 7 tunnels و 4 outbound) 15:34 <jrandom> لذا خلال الأيام القليلة القادمة عندما ترون الـrouter 7xgV ينقل الكثير من البيانات، لا تقلقوا ;) 15:35 <jrandom> ailouros: عندما يستغرق إنشاء tunnel وقتًا، يتم بناء إضافيات احتياطًا. 15:35 <jrandom> zzz يوضح بعض الأمور الغريبة على هذا الصعيد أيضًا، وهناك رقعة قيد العمل لتحسين الأمور قليلًا 15:35 <ailouros> فهمت.. لكن لماذا تنتهي صلاحيتها كلها في الوقت نفسه؟ 15:35 <@cervantes> jrandom: من باب الفضول، متى بدأت تلك الاختبارات؟ 15:35 <jrandom> cervantes: قبل بضعة أيام 15:36 <@cervantes> آه رائع، إذًا ليس ذلك ;-) 15:36 <jrandom> لا أدري يا ailouros، يعتمد على بضعة ظروف. لكن هناك بعض... *سعال* غرائب في كود إنشاء tunnel، وقد تجنبت العبث به لأنه سيُعاد كتابته في 0.6.2 15:38 <ailouros> فهمت. ظننت أنها مسألة سياسات... أفضل أن أرى الـtunnels تنتهي في أوقات مختلفة ما لم تكن هناك مبررات لغير ذلك 15:38 <ailouros> أي أن إنشاء الـtunnels غير متزامن 15:39 <jrandom> نعم، ستكون هناك عشوائية أفضل في 0.6.2، ورقعة zzz تضيف بعض العشوائية للإصدار الحالي أيضًا 15:40 <+Complication> أتساءل لماذا قد يقرر إصدار معقول من i2phex... إعادة تجزئة الملفات كل مرة أخرى عند تشغيله؟ 15:40 <jrandom> لا فكرة لدي 15:40 <+Complication> تبدو تهيئة تالفة هي السبب المرجح حتى الآن، لكنني لم أحذف تهيئتي بعد. 15:40 <jrandom> ربما طوابع زمنية منحرفة؟ 15:42 <+Complication> لا، تبدو صحيحة أيضًا 15:42 * jrandom لا يعلم. لم أنظر أبدًا إلى ذلك الجزء من كود phex... 15:42 <jrandom> أقصد code 15:42 <+Complication> سأرى إن كان حذف ملفات التهيئة القديمة سيجدي نفعًا 15:42 <jrandom> جيد 15:43 <jrandom> حسنًا، أي شيء آخر حول 1) حالة الشبكة / 0.6.1.7؟ 15:43 <jrandom> إن لم يكن، ننتقل إلى 2) أعطال tunnel التجريبية 15:44 <jrandom> تطرقنا إلى هذا قليلًا بالفعل، وهناك المزيد في الملاحظات وعلى zzz.i2p 15:44 <jrandom> zzz: هل لديك ما تضيفه/تطرحه؟ 15:46 <jrandom> إن لم يكن، فلننتقل إلى 3) SSU وNATs 15:46 <jrandom> bar: أي شيء تريد إضافته؟ 15:46 <+bar> لا، ليس لدي ما أضيفه سوى ما في البريد 15:47 <jrandom> رائع، نعم لا يزال علي الرد على بعض التفاصيل — أظن أن إعادة الإرسال لدينا ستتكفل ببعض المشاكل التي أشرت إليها 15:48 <jrandom> الحيلة ستكون في اكتشاف الحالة الجارية، لكي نستطيع أتمتة الإجراء الصحيح (أو إبلاغ المستخدم بأن وضعه سيئ) 15:48 <+bar> كل شيء في حينه، لا داعي للعجلة 15:49 <+bar> نعم، اقترحت إعدادًا يدويًا لتجاوز تلك المشكلة في الوقت الراهن، ربما لا يكون ممكنًا، لكن يمكننا مناقشته لاحقًا 15:50 <jrandom> نعم، التعديلات اليدوية ستفيد، لكن خبرتي مع إصدارات i2p السابقة كانت أن الجميع (*الجميع*) أفسدوها ;) لذا الأتمتة مفضلة 15:50 <jrandom> (وأقصد بالجميع نفسي أيضًا ;) 15:52 <+bar> أتفق 15:52 <ailouros> لول، إن كنت قد فعلت ذلك أيضًا فهناك خطب في الوثائق، إذ اتبعتها خطوة بخطوة :D 15:53 <+bar> في الأثناء، سأقضي بعض الوقت في دراسة اختبار الأقران 15:53 <jrandom> رائع، شكرًا bar! 15:54 <+bar> (ربما أستطيع توليد بعض الرسائل المزعجة غير المفيدة حول ذلك أيضًا :) 15:54 <jrandom> :) 15:55 <jrandom> حسنًا، إن لم يكن هناك شيء آخر في 3)، فلننتقل إلى 4) Syndie 15:56 <jrandom> كان هناك الكثير من التقدم مؤخرًا على هذا الصعيد، مع إعادة تصميم كبيرة لواجهة المستخدم منذ صدور 0.6.1.7 15:57 <jrandom> هناك أيضًا تثبيت/بناء مستقل جديد، لكن بما أن لدى الجميع i2p مثبتًا، فلا نحتاج إلى واحد منفصل 15:57 <ailouros> أجد أن تخطيط 6.1.7 أصعب استخدامًا من 6.1.6 15:58 <jrandom> هممم، هل تشغّل syndie في وضع المستخدم الواحد؟ وهل تستخدم أحدث بناء من CVS أم البناء الرسمي 0.6.1.7؟ 15:58 <ailouros> رسمي 0.6.1.7، مستخدم واحد 15:58 <jrandom> هل أنت من المؤيدين لواجهة شبيهة بالمدونات، بدلًا من التنقل المترابط؟ 15:58 <ailouros> لست كذلك، رغم أنني لا أعرف فعلًا أيها يشبه المدونة 15:58 <ailouros> شخصيًا أفضل عرضًا مترابطًا 15:59 <ailouros> (ومع تمييز لوني للرسائل الجديدة أيضًا في عرض الخيوط) 15:59 <+Complication> CVS متأخر نسبيًا، مستخدم واحد 15:59 <+Complication> وجدت غرابة بسيطة (وأظن أنها غير مقصودة) 15:59 <jrandom> آه، تم إحراز تقدم كبير على هذا الصعيد في CVS يا ailouros 15:59 <ailouros> رائع :) 16:00 <jrandom> لدينا أيضًا عرض مترابط جديد، يستخدم اقتراح cervantes بالاجتياز الكامل لفرع واحد فقط بدلًا من كل الفروع 16:00 <@cervantes> هل دُفِعت تلك التغييرات إلى syndiemedia.i2p.net؟ 16:00 <+bla> هل سيكون من الجيد عرض أمثلة افتراضية للموقع في http://localhost:7657/syndie/syndicate.jsp ؟ 16:00 <jrandom> syndiemedia.i2p.net هو رأس CVS، نعم 16:00 <+Complication> عندما تفتح خيطًا وتقرأ منشوراته... ثم تختار تطبيق مرشح لا يطابقه أي منشور (مثلًا افتح الخيط "Syndie threading"، وطبّق المرشح "i2p.i2phex")... 16:00 <jrandom> نعم، ربما يا bla. عمليات التثبيت الجديدة ستحوي الثلاثة الافتراضيين هناك، لكن الأمثلة ستكون جيدة 16:01 <@cervantes> (شجرة الخيط الفعلية تحتاج أيضًا لأن تُفتح بالكامل) 16:01 <+Complication> ...يبدو أنه يترك المنشورات الحالية معروضة، كما لو أنها متطابقة أو شيء من هذا القبيل... 16:01 <+Complication> رغم أنني ضغطت بالتأكيد على زر "Go". 16:01 <@cervantes> Complication: نعم وجدته مربكًا أنا أيضًا 16:02 <jrandom> هممم Complication، الفكرة العامة كانت أن نسمح لك بالتصفح بينما لا تزال تنظر إلى منشور، لكن ربما من الأفضل إسقاط المنشورات المعروضة 16:02 <jrandom> cervantes: آه، نعم توسيعه حتى الورقة سيكون جيدًا، ويجب أن يكون سهل التنفيذ 16:02 <+Complication> للتو لاحظت ذلك، وبما أنه برز لي، ظننت أن أخبركم 16:02 <@cervantes> (أو جعله أوضح أنه لا توجد أي مطابقات) 16:03 <jrandom> حسنًا، متصفح الخيوط يقول *لا يوجد تطابق* :) 16:03 <ailouros> ربما هو يبحث عن قدّاحة 16:03 <jrandom> !thwap 16:03 <@cervantes> (أو جعله أوضح أكثر أنه لا توجد أي مطابقات) 16:03 <jrandom> <blink>No matches</blink> 16:03 <+Complication> عذرًا :) 16:04 <tethra> يبدو أن !thwap أصاب spaetz__ بدلًا من ذلك، jr! 16:04 <+Complication> صحيح، أحيانًا يبدو متصفح الخيوط بعيدًا جدًا :) 16:04 <jrandom> نعم، نجرب بعض CSS لجعله يطفو على الجانب، كخيار 16:05 <@cervantes> مع دعم السمات (skinning) يمكنك وضع الخيط أعلى/أسفل/يسار/يمين إلخ 16:05 <@cervantes> آه كما قال jr 16:05 <+Complication> رابط "Threads" يأخذك إلى هناك بسرعة إلى حد ما 16:05 <+Complication> ...إذا كان ضمن منطقة العرض حاليًا. 16:06 <+Complication> ومن اعتاد التنقل بلوحة المفاتيح يمكنه ببساطة ضغط "End" 16:06 <jrandom> بالطبع، هذه الأشياء سهلة جدًا في التعديل (كما ترون من التغييرات السريعة في CVS :)، لذا إن كان لدى أحد اقتراحات (أو نماذج أولية — html / png / إلخ)، لطفًا، انشروها متى شئتم 16:07 <jrandom> أتوقع أن تكون لدينا صفحة نظرة عامة رئيسية شبيهة بمدونة خلال الأيام القليلة القادمة في CVS 16:08 <jrandom> حسنًا، هناك الكثير من الأمور الأخرى الجارية مع Syndie، لذا زوروا http://localhost:7657/syndie/ لمزيد من المعلومات :) 16:08 <jrandom> هل لدى أحد شيئًا آخر لطرحه حول هذا، أم ننتقل إلى 5) ??? 16:09 <zzz> مرحبًا دخلت للتو. بخصوص 2)، أبحث عن مختبرين لرقعتي. 16:10 <zzz> نتائجي هي تحسينات في تأخر المهام والاعتمادية، وتقليل حالات تعليق الـrouter. لذا آمل أن يجربها آخرون. 16:10 <ailouros> هذا يبدو جيدًا بما يكفي. ماذا علي أن أفعل؟ 16:11 <jrandom> أهلًا zzz، حسنًا رائع، سأختبرها قليلًا هنا أيضًا. لديها الكثير من المكونات المختلفة، لذا قد يستحق تقسيمها إلى أجزاء، لكنها تبدو جيدة وعلى المسار لـ 0.6.1.8 16:11 <ailouros> (متوسط زمن التشغيل حوالي 10 ساعات هنا :( 16:11 <zzz> إذا كان لديك الشيفرة المصدرية وant فقط طبّق الرقعة — أو يمكنني رفع i2pupdate.zip إن أردت 16:12 <zzz> jrandom سأعمل على تقسيمها 16:12 <ailouros> سأختار التحديث، شكرًا 16:13 <zzz> ailouros سأضعه على zzz.i2p خلال ساعة — شكرًا 16:13 <jrandom> zzz: لا داعي للقلق إلا إذا كان لديك وقت فراغ... أستطيع قراءة diff :) 16:13 <ailouros> شكرًا لك 16:14 <zzz> jrandom حسنًا. هناك بعض الأشياء المتفرقة التي يمكن إزالتها بسهولة سواء منك أو مني. 16:16 <ailouros> أظن أننا الآن عند 5) ???؟ 16:16 <zzz> jrandom موضوع آخر كانت هناك حالات نفاد الذاكرة (OOM) للـrouter مع i2phex واحتمال وجود مشاكل SAM 16:16 <jrandom> نعم يا ailouros 16:16 <jrandom> آه نعم zzz، سيكون رائعًا تتبّع ما يجري مع SAM 16:17 <ailouros> j346، هل حظيت بفرصة لتجربة تطبيقي؟ 16:17 <jrandom> ما سيكون رائعًا حقًا هو لو تمكن شخص ما من استلام صيانة SAM bridge، إذ لم أقم بأي عمل جوهري عليه، وhuman لم يكن موجودًا منذ فترة. 16:19 <jrandom> ليس بعد يا ailouros، للأسف. كنت غير واثق قليلًا من كيفية عمله، لذا علي قراءة المصدر أولًا 16:20 <ailouros> لا تتردد في السؤال 16:20 <ailouros> (وحظًا موفقًا في رحلتك عبر المصدر، إنه تعريف جيد لكلمة "فوضى") 16:20 <jrandom> ههه 16:21 <zzz> للتوضيح تجربتي كانت حالات OOM عند استخدام i2p-bt، وليس i2phex. يحدث ذلك بعد حوالي 24 ساعة عند تشغيل i2p-bt واحد وفي غضون بضع ساعات عند تشغيل اثنين i2p-bt 16:22 <+Complication> حدثت لي بعد اختبار إجهاد لوقت متأخر من الليل. 16:22 <+Complication> (وخلاله، على فكرة، رأيت متوسطات 5 دقائق بلغت 50 KB/s) 16:22 <bar_> هل تذكّرني من فضلك ما هو تطبيقك/ماذا يفعل، يا ailouros؟ ذاكرتي جيدة لكن قصيرة... 16:22 <+Complication> الاستقبال، أعني. 16:22 <+Complication> كان الإرسال محدودًا بـ 35 KB/s 16:22 <@cervantes> Complication: لم أسمع أحدًا يسميه "اختبار إجهاد لوقت متأخر من الليل" من قبل... 16:22 <jrandom> جميل يا Complication 16:23 <+Complication> cervantes: حسنًا، يمكن للمرء أن يسميه "استنزافًا ضخمًا شبه يومي" إذًا :P 16:23 <ailouros> bar_: إنه إثبات جدوى عامل لتطبيق مشاركة ملفات موزع يشارك الكُتَل المشتركة بين ملفات مختلفة (كما اقترح polecat) 16:23 <bar_> آه، صحيح، شكرًا يا ailouros 16:24 <tethra> cervantes: هههههه ;) 16:24 <ailouros> على الرحب (إن أراد أحد الحصول على المصدر، فهو C/C++) 16:25 <+polecat> ailouros: كن حذرًا، احتمال أن تكون كتلتان ثنائيتان متماثلتين نادر بما يكفي، أنا أتحدث غالبًا عن نظرية صِرف قد لا تكون مفيدة عمليًا. 16:25 <ailouros> polecat، أتفق. أفضل تخمين لدي أنه يصبح مفيدًا عندما تحصل على نسخ مختلفة من الملفات نفسها 16:25 <ailouros> مثل فيلم لديه كتلة تالفة 16:25 <+polecat> يمكنك نقل كتل من الأصفار بسرعة البرق! ("الكتلة التالية أصفار" "أوه لدي تلك بالفعل" "الكتلة التالية أصفار" "أوه لدي تلك بالفعل") 16:26 <ailouros> أو أرشيف لملفات zip أخرى 16:26 <jrandom> أو مثلًا وسوم ID3 المعدلة، إلخ 16:26 <ailouros> بالضبط 16:26 <+polecat> صحيح. لكن طريقة سهلة لـ "إصلاح" فيلم ذي كتلة تالفة هي أن تطلب من bittorrent أن ينزّل فوقه. معظم العُملاء سيحافظون على الكتل التي تجزئتها متشابهة، ويستبدلون تلك المختلفة. 16:26 <jrandom> لكن أرشيفات الملفات ربما لن تعمل، لأنها ستحتاج إلى الانقسام عند حدود الملفات 16:27 <ailouros> j636، لهذا أريد تنفيذ فكرة LBFS بالانقسام على علامات البيانات وليس أحجام كتل ثابتة 16:27 <@cervantes> مجتمع DC استخدم تلك الطريقة، عبر مشاركة توزيعات الملفات في rarsets 16:27 <+polecat> قد يكون مفيدًا أن تنشئ خوارزمية تصحيح أخطاء عامة للثنائيات، ثم تطبقها على نطاق واسع. يمكن "تصحيح" كل الكتل إلى بعضها البعض، وعندها لن تضطر إلا لنقل بيانات التصحيح، والتي قد تكون أصغر من نقل الكتلة نفسها. 16:29 <@cervantes> ثم تُبنى عمليات البحث على تجزئات Tiger لتلك أجزاء الـrar 16:29 <+Complication> فكرة جميلة... تبدو صعبة رغم ذلك :) 16:29 <+polecat> لكنها مكافئة تجزئة بتجزئة... لن تجد كتلتين متشابهتين أبدًا! 16:29 <ailouros> cervantes، ما هي "rarset"؟ :D (عدا عن "ملف RAR") 16:29 <+polecat> إلا إذا كان لدى الطرفين الملف بالفعل، وكان لدى أحدهما نسخة تالفة. 16:29 <ailouros> polecat، ماذا تقصد؟ 16:29 <@cervantes> ailouros: أرشيف RAR مُجزّأ، مع ملفات تماسك (parity) إن لزم 16:30 <ailouros> cervantes: لا أفهم ميزة فعل ذلك 16:31 <@cervantes> ميزته الأساسية كانت إضافة تنزيل متعدد المصادر بشكل شبه وهمي إلى DC 16:32 <ailouros> حسنًا، هذا جزء من آلية مشاركة الكتل بين الملفات، أليس كذلك؟ 16:34 <ailouros> polecat: بخصوص تنزيل bittorrent فوق الملفات التالفة، ما لا يقدمه لك هو عندما تحاول الحصول على عدة نسخ في وقت واحد 16:35 <@cervantes> عميلك يطابق/ينزّل الأجزاء الصحيحة فقط، وإذا كان لديك ملفات تماسك يمكنك أيضًا استعادة الأجزاء التالفة 16:35 <ailouros> مع نظامي لا توجد أجزاء تالفة (لا تُركّب الملفات إلا عند تنزيل الكتل المكوِّنة وإعادة التحقق منها) 16:36 <@cervantes> أشياء يقوم بها bittorrent افتراضيًا، باستثناء أنك لا تستطيع البحث تحديدًا عن أجزاء فردية 16:36 <+polecat> النسخ المتعددة على الأرجح لن يكون بينها بت واحد مشترك... ولهذا فهي سيئة جدًا. يقرر أحدهم إعادة ترميز الفيلم بحجم طابع بريدي ويعطيه الاسم نفسه. 16:37 <+polecat> أو يأخذ شخص آخر بيانات عشوائية ويسميها باسم الملف الذي تريد تنزيله. 16:37 <ailouros> لول هذا صحيح 16:37 <@cervantes> بالضبط وإصدارات rarset منيعة على ذلك... 16:37 <ailouros> لكن ضع في اعتبارك أن الملفات من شبكات أخرى (emule، kazaa، وما إلى ذلك) غالبًا ما تأتي تالفة 16:38 <+polecat> إصدارات rarset ليست منيعة... 16:38 <+polecat> لا يزال عليك معرفة أي rarset هي الصحيحة. 16:38 <ailouros> cervantes، كيف تكون rarsets منيعة أمام أحمق ينشر نفايات عشوائية؟ 16:38 <@cervantes> (شريطة أن يكون لديك مصدر موثوق) 16:39 <@cervantes> لأن مجموعة الإصدار تنشر تجزئات/معلومات التوزيع 16:39 <ailouros> ههههه هذا سهل :D 16:39 <@cervantes> وتُوسَم الأشياء بأنها nuked إذا كانت ذات جودة رديئة، والناس يزيلونها من مشاركاتهم 16:40 <ailouros> cervantes، مشروعي التجريبي يقوم بذلك بالفعل 16:40 <@cervantes> رائع 16:40 <ailouros> تحصل على واصف الملف من مصدر موثوق، وتسحب الملف من مصادر متعددة فورًا 16:41 <@cervantes> يبدو جيدًا ;-) 16:41 <ailouros> لا يمكنك البحث عن الملفات، لكن يمكنك تصفح دليل كل مستخدم مُشارَك، لذا يمكنك استخدام زاحف ويب وتخزين النتائج مؤقتًا 16:42 <ailouros> رغم أنني قد أضيف وظيفة بحث في وقت لاحق إن دعت الحاجة 16:44 <ailouros> أعتقد أن مشروعي التجريبي، إذا طُوِّر بشكل صحيح إلى تطبيق، يمكن أن يقدم التخزين المؤقت والمرونة التي يحاول فريق Freenet تقديمها 16:44 <ailouros> مثل توزيع المحتوى الثابت والتخزين المؤقت 16:45 <ailouros> تقرأ مدونتي، تخزّنها مؤقتًا وتعرضها للآخرين عندما يريدون. لا تفعل أكثر من إبقاء المحتوى هناك 16:45 <ailouros> لا يعجبك المحتوى؟ احذفه وانتهى الأمر 16:45 <jrandom> هممم، فهل تراها كمخزن خلفي (backing store) يمكن استخدامه مع Syndie؟ 16:46 <ailouros> يمكن استخدامها كمخزن خلفي 16:46 <ailouros> وكما هي الآن، يمكنك حتى استخدامها بدل jetty، في تثبيتات i2p الافتراضية 16:46 <jrandom> مثلًا مرفقات/روابط إلى [clunk hash="$foo"]my file[/clunk] 16:46 <ailouros> (حسنًا مع بعض التغييرات البسيطة :D ) 16:46 <jrandom> هه 16:47 <jrandom> حسنًا، نعم، بالتأكيد لا أفهم كيف يعمل clunk... هل تود أن تنشر عنه في Syndie، أو تضع eepsite؟ :) 16:47 <ailouros> تُنزّل تجزئات الملفات عند طلب الملف، وتُستخدَم هذه التجزئات لتنزيل الملف الكامل تلقائيًا 16:48 <jrandom> صحيح، لكن "التنزيل" سؤال من أين وإلى أين، إلخ. سيكون وصف بنية الشبكة العامة مفيدًا 16:48 <ailouros> سأكتب وثيقة جيدة أولًا، ثم أنشرها في مكان ما 16:48 <jrandom> رائع، شكرًا 16:48 <ailouros> تُنزَّل من أي مكان حصلت منه على التجزئة 16:48 <ailouros> بالإضافة إلى كل من يشارك هذه الكتل 16:49 <ailouros> فكّر في go!zilla وDownload Accelerator :) 16:49 <jrandom> أظنك لا تدرك مدى ارتباكي 16:49 <ailouros> لكن بشفافية وداخل i2p 16:49 <ailouros> لول أظن ذلك :D 16:50 <jrandom> شرح بسيط جدًا جدًا مثلًا: "تشغّل عميل clunk، وتنزّل من خادم clunk، وتحصل على معلومات عن أقران clunk"، إلخ 16:50 <jrandom> هل أستخدم متصفح ويب للاستعلام من عميل clunk؟ أم خادم؟ أم قرين؟ 16:51 <jrandom> (لهذا الحد أنا تائه) 16:51 <ailouros> أعد من الصفر :) 16:51 <ailouros> تستخدم متصفح الويب لديك 16:51 <ailouros> تتصل بعميلك 16:51 <ailouros> تتصفح دلائل الآخرين بمتصفحك 16:51 <ailouros> تختار الملفات لتنزيلها عبر متصفحك 16:51 <ailouros> عميلك يقوم بالعمل القذر 16:52 <ailouros> تسترجع الملف المُنزَّل 16:52 <ailouros> هل هذا أوضح؟ :) 16:52 <jrandom> حسنًا رائع، شكرًا — إذًا "تصفح دليل الآخرين" يتم عبر أن عميلك يستعلم عميلهم ويرد بتمثيل HTML له 16:52 <ailouros> بالضبط 16:52 <jrandom> (أو يُسحب من خادم/قارِن فائق superpeer/إلخ) 16:53 <jrandom> جيد 16:53 <ailouros> كل العمل القذر (إيجاد المتطابقات، التنزيل من مصادر متعددة، وما إلى ذلك) يتم بواسطة عميلك (المحلي) بشفافية 16:54 <ailouros> ما تراه، أساسًا، شجرة أدلة وبعض الملفات التي يمكنك تنزيلها 16:54 <jrandom> رائع 16:55 <ailouros> لنشر بياناتك تعطي عنوانك العام (p2p) 16:55 <ailouros> وللمشاركة تنسخ الملفات (أو تنشئ symlink) إلى دليل pub/ (أو بعض الأدلة الفرعية). الأمر بهذه السهولة 16:57 * jrandom سيغوص أكثر في المصدر، ويتطلع إلى مزيد من المعلومات :) 16:57 <jrandom> حسنًا، هل لدى أحد أي شيء آخر للاجتماع؟ 16:57 <bar_> أمم.. ما الفرق بين النشر والمشاركة، إن سمحت بالسؤال؟ هل يدفع النشر البيانات إلى مخزن ما؟ 16:58 <ailouros> bar_: المشاركة هي إعطاء الكتل للتنزيل. النشر هو إعلام العالم بما تشاركه 16:58 <ailouros> النشر مجموعة فرعية من المشاركة 16:58 <bar_> آه، فهمت، شكرًا 16:58 <ailouros> على سبيل المثال، إذا كان لديك نصف ملف، فأنت تشاركه لكن لا تنشره 16:59 <jrandom> كيف سيعرف الناس أنهم يستطيعون الحصول على تلك الكتل منك إذًا؟ 16:59 <ailouros> ولك السيطرة الكاملة على أي الملفات تنشر (على عكس emule حيث كل ملف مُنزّل يُنشر) 16:59 <ailouros> لأن كل عميل يرسل دوريًا معلومات إلى الشبكة عن أي كتل لديه ليعرضها 17:00 <jrandom> جيد 17:00 <ailouros> يرسل إلى الشبكة بمعنى خادم (كما هو الآن) أو DHT (مستقبلًا) 17:00 <jrandom> إذًا هو على شاكلة mnet، مع متتبع كتل 17:00 <ailouros> أممم على شاكلة mnet؟ 17:01 <jrandom> مشابه لكيفية عمل mnet (mnetproject.org) 17:01 * ailouros يقرأ mnetproject.org 17:02 <ailouros> حسنًا، لديك مساحاتك الشخصية فقط، لا مساحات مشتركة 17:02 <ailouros> ولا تقوم بـ PUSH للكتل هنا وهناك 17:02 <jrandom> نعم، ليس مطابقًا لـ mnet، لكنه مشابه بنيويًا 17:03 <jrandom> إنه مثل mnet حيث الجميع مفلسون لدرجة أن لا أحد يستضيف بياناتهم ;) 17:03 <ailouros> نعم 17:03 <ailouros> :D 17:03 <jrandom> حسنًا، هل لدى أحد أي شيء آخر لطرحه؟ 17:04 <jrandom> إن لم يكن... 17:04 * jrandom يستعد 17:04 * jrandom يغلق الاجتماع بـ *baf*