مرحباً جميعاً، ملاحظات حالة متأخرة هذا الأسبوع

  • Index
  1. حالة الشبكة 2) حالة تطوير Router 3) تتمة مبررات Syndie 4) حالة تطوير Syndie 5) التحكم الموزع بالإصدارات 6) ???
    1. Net status

كانت الأوضاع خلال الأسبوع أو الأسبوعين الماضيين مستقرة إلى حدّ كبير على irc وعلى الخدمات الأخرى، مع أن dev.i2p/squid.i2p/www.i2p/cvs.i2p شهدت بعض المشاكل الطفيفة (بسبب مشكلات مؤقتة متعلقة بنظام التشغيل). تبدو الأمور في حالة استقرار في الوقت الحالي.

    1. Router dev status

الجانب الآخر لنقاش Syndie هو: «حسنًا، ماذا يعني ذلك بالنسبة إلى router؟»، وللإجابة عن ذلك، دعوني أشرح قليلًا أين وصل تطوير router في الوقت الراهن.

بشكل عام، ما يمنع router من الوصول إلى الإصدار 1.0 هو في رأيي أداؤه، وليس خصائص إخفاء الهوية لديه. من المؤكد أن هناك مسائل تتعلق بإخفاء الهوية بحاجة إلى تحسين، لكن مع أننا نحصل على أداء جيد للغاية لشبكة مجهولة الهوية، إلا أن أدائنا غير كافٍ للاستخدام الأوسع. علاوة على ذلك، فإن تحسينات إخفاء الهوية في الشبكة لن تحسّن أداءها (وفي معظم الحالات التي تخطر ببالي، تؤدي تحسينات إخفاء الهوية إلى تقليل معدل النقل وزيادة الكمون). علينا معالجة مشاكل الأداء أولاً، لأنه إذا كان الأداء غير كافٍ، فالنظام بأكمله يكون غير كافٍ، بغض النظر عن مدى قوة تقنيات إخفاء الهوية فيه.

إذن، ما الذي يعيق أداءنا؟ الغريب في الأمر أنه يبدو أن استخدامنا لوحدة المعالجة المركزية (CPU) هو السبب. قبل أن نصل إلى السبب تحديداً، قليلٌ من الخلفية أولاً.

  • to prevent partitioning attacks, we all need to plausibly build our tunnels from the same pool of routers.
  • to allow the tunnels to be of manageable length (and source routed), the routers in that pool must be directly reachable by anyone.
  • the bandwidth costs of receiving and rejecting tunnel join requests exceeds the capacity of dialup users on burst.

لذلك، نحتاج إلى فئات من routers - بعضها قابل للوصول عالمياً مع حدود عرض نطاق عالية (الفئة A)، وبعضها غير ذلك (الفئة B). وقد تم تنفيذ ذلك فعلياً من خلال معلومات السعة في netDb، واعتباراً من يوم أو يومين مضيا، كانت النسبة بين الفئة B والفئة A حوالي 3 إلى 1 (93 routers من cap L أو M أو N أو O، و278 من cap K).

الآن، يوجد أساساً موردان نادران يجب إدارتُهما في المستوى A - عرض النطاق الترددي ووحدة المعالجة المركزية (CPU). يمكن إدارة عرض النطاق الترددي بالوسائل المعتادة (توزيع الحمل عبر مجموعة واسعة، وجعل بعض النظراء يتعاملون مع كميات هائلة [على سبيل المثال: أولئك على T3s]، ورفض أو تقييد سرعة tunnels والاتصالات الفردية).

إدارة استخدام وحدة المعالجة المركزية (CPU) أصعب. عنق الزجاجة الأساسي في CPU المُلاحظ على routers من الفئة A هو فك تشفير طلبات إنشاء tunnel. يمكن أن تُستنزف routers الكبيرة (وهي كذلك فعلًا) بالكامل بهذا النشاط - على سبيل المثال، متوسط زمن فك تشفير طلب إنشاء tunnel على مدى العمر التشغيلي في أحد routers لديّ هو 225ms، ومتوسط وتيرة فك تشفير طلب tunnel على مدى العمر التشغيلي هو 254 حدثًا كل 60 ثانية، أو 4.2 في الثانية. مجرد ضرب هذين الرقمين معًا يبيّن أن 95% من CPU يُستهلك بفك تشفير طلبات tunnel وحده (وذلك من دون أخذ القمم في عدد الأحداث في الاعتبار). ومع ذلك، لا يزال ذلك router، بطريقة ما، ينجح في المشاركة في 4-6000 tunnels في آن واحد، وهو يقبل تقريبًا 80% من الطلبات التي تم فك تشفيرها.

لسوء الحظ، لأن وحدة المعالجة المركزية (CPU) على ذلك الـrouter مثقلة بالحمل إلى حد كبير، فعليه إسقاط عدد كبير من طلبات إنشاء tunnel قبل أن يمكن حتى فك تشفيرها (وإلا ستبقى الطلبات في قائمة الانتظار لمدة طويلة إلى درجة أنه حتى لو قُبِلَت، فستكون الجهة الطالبة الأصلية قد اعتبرتها مفقودة أو مثقلة بالحمل بحيث يتعذر فعل أي شيء على أي حال). في ضوء ذلك، يبدو معدل القبول البالغ 80% لدى ذلك الـrouter أسوأ بكثير — إذ إنه على مدى فترة تشغيله فكّ تشفير نحو 250k طلبًا (ما يعني أن نحو 200k منها قد تم قبولها)، لكنه اضطر إلى إسقاط نحو 430k طلبًا في قائمة انتظار فك التشفير بسبب زيادة حمل الـCPU (ما حوّل معدل القبول 80% إلى 30%).

تبدو الحلول أقرب إلى تقليل تكلفة CPU المرتبطة بفك تشفير طلبات الـ tunnel. إذا خفّضنا زمن CPU بنحو عشرة أضعاف، فإن ذلك سيزيد سعة الـ router من الفئة A بشكل كبير، مما سيقلّل الرفض (سواء الصريح أو الضمني، بسبب إسقاط الطلبات). وهذا بدوره سيزيد معدل نجاح بناء الـ tunnel، وبالتالي سيخفض وتيرة انتهاء صلاحية الـ lease، مما سيقلل بعد ذلك حِمل النطاق الترددي على الشبكة بسبب إعادة بناء الـ tunnel.

إحدى الطرق للقيام بذلك ستكون تغيير طلبات إنشاء tunnel من استخدام Elgamal بحجم 2048 بت إلى، لنقل، 1024 بت أو 768 بت. لكن المشكلة هي أنه إذا كُسر التشفير لرسالة طلب إنشاء tunnel، فسيُعرَف المسار الكامل للـ tunnel. حتى لو سلكنا هذا النهج، كم سيجلب لنا ذلك من فائدة؟ قد يمحو تحسّن بمقدار مرتبة قدرية واحدة في زمن فك التشفير أثره ارتفاعٌ بمقدار مرتبة قدرية في نسبة المستوى B إلى المستوى A (المعروفة أيضاً بمشكلة freeriders، أي المستفيدين بلا مقابل)، وعندها سنكون عالقين، إذ لا سبيل لأن ننتقل إلى Elgamal بحجم 512 أو 256 بت (ونستطيع بعدها أن ننظر إلى أنفسنا في المرآة ;)

أحد البدائل هو استخدام تشفير أضعف، لكن مع التخلي عن الحماية ضد هجمات عدّ الحزم التي أضفناها ضمن عملية بناء الـ tunnel الجديدة. سيسمح لنا ذلك باستخدام مفاتيح تفاوضية مؤقتة بالكامل في tunnel تلسكوبي على غرار Tor (مع أنه، مجدداً، سيُعرّض منشئ الـ tunnel لهجمات عدّ الحزم السلبية البسيطة التي تحدد خدمة).

فكرة أخرى هي نشر واستخدام معلومات حمل أكثر صراحةً في netDb، مما يتيح للعملاء اكتشاف الحالات بدقة أكبر مثل الحالة المذكورة أعلاه حيث يقوم router ذو عرض نطاق عالٍ بإسقاط 60% من رسائل طلب tunnel الخاصة به من دون حتى النظر إليها. هناك بعض التجارب الجديرة بالتنفيذ على هذا المسار، ويمكن إجراؤها مع توافق كامل مع الإصدارات السابقة، لذا من المفترض أن نراها قريباً.

إذن، هذا هو عنق الزجاجة في الـ router/الشبكة كما أراه اليوم. سنقدّر كثيرًا أيًّا وكلّ الاقتراحات حول كيفية تعاملنا معه.

    1. Syndie rationale continued

هناك منشور مُفصَّل على المنتدى حول Syndie ومكانه في الصورة العامة - اطّلع عليه على http://forum.i2p.net/viewtopic.php?t=1910

أيضًا، أود فقط تسليط الضوء على مقتطفين من وثائق Syndie التي يُجرى العمل عليها. أولًا، من irc (ومن الأسئلة الشائعة التي لم تُنشر بعد):

سؤال كنت أفكّر فيه: من الذي سيكون لديه لاحقاً جرأة كافية لاستضافة خوادم/أرشيفات الإنتاج لـ syndie؟ ألن يكون من السهل تعقّبها بقدر سهولة تعقّب eepsites(I2P Sites) اليوم؟ أرشيفات syndie العامة لا تمتلك القدرة على قراءة المحتوى المنشور في المنتديات، ما لم تنشر المنتديات المفاتيح اللازمة لذلك وانظر الفقرة الثانية من usecases.html بالطبع، المستضيفون للأرشيفات الذين تُوجَّه إليهم أوامر قانونية بإزالة منتدى سيقومون على الأرجح بذلك (لكن يمكن للناس عندها الانتقال إلى أرشيف آخر، دون تعطيل عمل المنتدى) نعم، ينبغي أن تذكر أن الانتقال إلى وسيط مختلف سيكون سلساً إذا توقّف أرشيفي، يمكنني رفع منتداي بالكامل إلى أرشيف جديد، صحيح؟ بالضبط يا bar يمكنهم استخدام طريقتين في الوقت نفسه أثناء الانتقال وأي شخص قادر على مزامنة الوسائط صحيح يا void

القسم ذو الصلة من (غير المنشور بعد) Syndie usecases.html هو:

غالباً ما ترغب مجموعات كثيرة ومختلفة في تنظيم النقاشات ضمن منتدى عبر الإنترنت، غير أن الطبيعة المركزية للمنتديات التقليدية (مواقع ويب، أنظمة BBS، إلخ) قد تشكل مشكلة. فعلى سبيل المثال، يمكن إخراج الموقع الذي يستضيف المنتدى عن الخدمة عبر هجمات حجب الخدمة أو بإجراء إداري. إضافةً إلى ذلك، فإن الاعتماد على مضيف واحد يوفر نقطة يسهل من خلالها مراقبة نشاط المجموعة، بحيث إنه حتى لو كان المنتدى يُدار بأسماء مستعارة، يمكن ربط تلك الأسماء المستعارة بعنوان IP الذي نشر أو قرأ رسائل فردية.

بالإضافة إلى ذلك، ليست المنتديات لامركزية فحسب، بل هي منظمة بطريقة ad-hoc (حسب الحاجة) ومع ذلك متوافقة تمامًا مع تقنيات تنظيم أخرى. هذا يعني أن مجموعة صغيرة من الأشخاص يمكنهم تشغيل منتداهم باستخدام تقنية واحدة (توزيع الرسائل بلصقها على موقع ويكي)، ويمكن لمجموعة أخرى تشغيل منتداهم باستخدام تقنية أخرى (نشر رسائلهم في جدول تجزئة موزع مثل OpenDHT، وإذا كان شخص واحد على دراية بكلتا التقنيتين، فيمكنه مزامنة المنتديين معًا. هذا يتيح للأشخاص الذين كانوا على علم بموقع الويكي فقط التحدث إلى أشخاص كانوا على علم بخدمة OpenDHT فقط من دون معرفة أي شيء عن بعضهم البعض. ومع التوسع أكثر، يتيح Syndie للخلايا الفردية التحكم في مستوى ظهورهم أثناء التواصل عبر المنظمة بأكملها.

    1. Syndie dev status

لقد تحقق تقدم كبير في Syndie مؤخرًا، مع إصدار 7 نسخ ألفا وتوزيعها على الأشخاص في قناة IRC. تمت معالجة معظم المشكلات الكبرى في الواجهة القابلة للبرمجة بالنصوص (scriptable interface)، وأتمنى أن نتمكن من إطلاق Syndie 1.0 في وقت لاحق من هذا الشهر.

هل قلت للتو “1.0”؟ نعم بالتأكيد! مع أن Syndie 1.0 سيكون تطبيقاً نصياً، ولن يرقى من حيث سهولة الاستخدام إلى التطبيقات النصية الأخرى المماثلة (مثل mutt أو tin)، إلا أنه سيوفر النطاق الكامل من الوظائف، ويسمح باستراتيجيات syndication (التوزيع الآلي) المعتمدة على HTTP وعلى الملفات، ومن المأمول أن يُظهر للمطورين المحتملين قدرات Syndie.

في الوقت الحالي، أضع بشكل مبدئي إصدار Syndie 1.1 (يتيح للناس تنظيم أرشيفاتهم وعادات القراءة بشكل أفضل)، وربما إصدار 1.2 لدمج بعض وظائف البحث (سواء عمليات البحث البسيطة أو ربما عمليات البحث بالنص الكامل الخاصة بـ lucene). سيكون Syndie 2.0 على الأرجح أول إصدار بواجهة مستخدم رسومية (GUI)، على أن يأتي المكوّن الإضافي للمتصفح مع الإصدار 3.0. سيتم توفير دعم لأرشيفات إضافية وشبكات توزيع الرسائل عند تنفيذها، بالطبع (freenet، mixminion/mixmaster/smtp، opendht، gnutella، إلخ).

أدرك مع ذلك أن Syndie 1.0 لن يكون ذلك الذي يقلب الموازين كما يريده بعضهم، لأن التطبيقات القائمة على النصوص في الأساس للمهووسين بالتقنية، لكنني أود أن نحاول التخلص من عادة اعتبار “1.0” إصداراً نهائياً، وأن نعدّه بدلاً من ذلك بداية.

    1. Distributed version control

حتى الآن، كنت أعبث بـ subversion باعتباره الـ vcs (نظام إدارة الإصدارات) لمشروع Syndie، مع أنني لا أجيد فعلياً سوى CVS و clearcase. ذلك لأنني غالباً ما أكون غير متصل، وحتى عندما أكون متصلاً يكون الاتصال الهاتفي (dialup) بطيئاً، لذا كانت أدوات subversion المحلية مثل diff/revert/etc مفيدة جداً. لكن بالأمس، نبّهني void باقتراح أن ننظر بدلاً من ذلك في أحد الأنظمة الموزعة.

اطلعتُ عليها قبل بضع سنوات أثناء تقييم نظام إدارة الإصدارات (VCS) لـ I2P، لكنني صرفت النظر عنها لأنني لم أكن بحاجة إلى وظائفها دون اتصال (كان لديّ وصولًا جيدًا إلى الشبكة حينها)، لذا لم يكن من المجدي تعلّمها. لم يعد الأمر كذلك الآن، لذلك أدرسها بمزيد من الاهتمام الآن.

  • From what I can see, darcs, monotone, and codeville are the top

هناك متنافسون، ويبدو أن نظام التحكم بالإصدارات (VCS) القائم على التصحيحات لدى darcs جذابٌ بشكلٍ خاص. على سبيل المثال، يمكنني إنجاز كل عملي محلياً ثم استخدام scp لرفع الـ diffs (فروقات) المضغوطة بـ gzip والموقَّعة بـ gpg إلى دليل Apache على dev.i2p.net، ويمكن للناس المساهمة بتغييراتهم الخاصة عبر نشر الـ diffs المضغوطة بـ gzip والموقَّعة بـ gpg في المواقع التي يختارونها. وعندما يحين وقت وضع علامة لإصدار ما، سأُجري darcs diff يحدد مجموعة التصحيحات المندرجة في الإصدار وأرفع ذلك الـ diff الـ .gz’ed/.gpg’ed كما في السابق (وكذلك نشر ملفات tar.bz2 و .exe و .zip الفعلية، بالطبع ;)

وعلى نحو مثير للاهتمام بشكل خاص، يمكن نشر ملفات الفروق المضغوطة بـ gzip والمشفّرة بـ GPG كمرفقات لرسائل Syndie، مما يتيح لـ Syndie أن تكون ذاتية الاستضافة.

هل لدى أحدكم خبرة مع هذه الأشياء؟ أي نصائح؟

    1. ???

فقط 24 شاشة من النص هذه المرة (بما في ذلك منشور المنتدى) ;) للأسف لم أتمكن من حضور الاجتماع، ولكن، كما هو الحال دائمًا، يسعدني سماع آرائكم إن كانت لديكم أي أفكار أو اقتراحات - فقط انشروا على القائمة البريدية، أو في المنتدى، أو مرّوا على IRC.

=jr