مناقشة قاعدة بيانات الشبكة

ملاحظة: ما يلي هو مناقشة لتاريخ تطبيق netDb وليس معلومات حالية. راجع الصفحة الرئيسية لـ netDb للحصول على الوثائق الحالية.

التاريخ

يتم توزيع netDb بتقنية بسيطة تسمى “floodfill”. منذ زمن بعيد، استخدم netDb أيضاً Kademlia DHT كخوارزمية احتياطية. ومع ذلك، لم تعمل بشكل جيد في تطبيقنا، وتم تعطيلها بالكامل في الإصدار 0.6.1.20.

(مقتبس من منشور بواسطة jrandom في Syndie القديم، 26 نوفمبر 2005)

إن floodfill netDb هو في الواقع مجرد إجراء بسيط وربما مؤقت، يستخدم أبسط خوارزمية ممكنة - إرسال البيانات إلى نظير في floodfill netDb، انتظار 10 ثوانٍ، اختيار نظير عشوائي في netDb وطلب الإدخال المرسل منه، والتحقق من إدراجه/توزيعه بشكل صحيح. إذا لم يرد نظير التحقق، أو لم يكن لديه الإدخال، يكرر المرسل العملية. عندما يتلقى النظير في floodfill netDb مخزن netDb من نظير ليس في floodfill netDb، فإنه يرسله إلى جميع الأنظار في floodfill netDb.

في نقطة معينة، كانت وظائف البحث/التخزين الخاصة بـ Kademlia لا تزال قائمة. اعتبرت العقد أن عقد floodfill دائماً “أقرب” لكل مفتاح من أي عقدة أخرى لا تشارك في netDb. كنا نعود إلى netDb الخاص بـ Kademlia إذا فشلت عقد floodfill لسبب أو آخر. ومع ذلك، تم تعطيل Kademlia بالكامل بعد ذلك (انظر أدناه).

مؤخراً، تم إعادة تقديم Kademlia جزئياً في أواخر عام 2009، كطريقة للحد من حجم netDb الذي يجب على كل floodfill router تخزينه.

مقدمة خوارزمية Floodfill

تم تقديم floodfill في الإصدار 0.6.0.4، مع الاحتفاظ بـ Kademlia كخوارزمية احتياطية.

(مقتبس من منشورات jrandom في Syndie القديم، 26 نوفمبر 2005)

كما قلت مراراً، لست مرتبطاً بشكل خاص بأي تقنية محددة - ما يهمني هو ما سيحقق النتائج. بينما كنت أعمل على أفكار netDb مختلفة خلال السنوات القليلة الماضية، فإن المشاكل التي واجهناها في الأسابيع القليلة الماضية قد جعلت بعضها يصل إلى نقطة حرجة. على الشبكة المباشرة، مع تعيين عامل التكرار في netDb على 4 peers (بمعنى أننا نستمر في إرسال إدخال إلى peers جدد حتى يؤكد 4 منهم أنهم حصلوا عليه) ومهلة كل peer محددة بـ 4 أضعاف متوسط وقت الرد لذلك الpeer، ما زلنا نحصل على متوسط 40-60 peer يُرسل إليهم قبل أن يؤكد 4 منهم التخزين. هذا يعني إرسال رسائل أكثر بـ 36-56 مرة مما يجب أن يُرسل، وكل منها تستخدم tunnels وبالتالي تعبر 2-4 روابط. علاوة على ذلك، هذه القيمة منحرفة بشدة، حيث كان متوسط عدد الpeers المُرسل إليهم في تخزين “فاشل” (بمعنى أن أقل من 4 أشخاص أكدوا الرسالة بعد 60 ثانية من إرسال الرسائل) في نطاق 130-160 peer.

هذا جنون، خاصة بالنسبة لشبكة تحتوي على ربما 250 نقطة اتصال فقط عليها.

الإجابة الأبسط هي القول “حسناً، يا jrandom، إنه معطل. أصلحه”، لكن هذا لا يصل تماماً إلى جوهر المسألة. بما يتماشى مع جهد حالي آخر، من المحتمل أن لدينا عدداً كبيراً من مشاكل الشبكة بسبب المسارات المقيدة - الأقران الذين لا يستطيعون التواصل مع أقران آخرين، غالباً بسبب مشاكل NAT أو جدار الحماية. إذا كان، على سبيل المثال، الأقران K الأقرب إلى إدخال netDb معين خلف “مسار مقيد” بحيث يمكن لرسالة تخزين netDb أن تصل إليهم ولكن رسالة البحث في netDb من قِبل قرين آخر لا تستطيع الوصول، فإن ذلك الإدخال سيكون غير قابل للوصول بشكل أساسي. بمتابعة هذه الخطوط قليلاً أكثر وأخذ حقيقة أن بعض المسارات المقيدة ستُنشأ بنوايا عدائية في الاعتبار، من الواضح أننا سنضطر إلى النظر عن كرب أكثر في حل netDb طويل المدى.

هناك بعض البدائل، ولكن يستحق ذكر اثنين منها بشكل خاص. الأول هو ببساطة تشغيل netDb كـ Kademlia DHT باستخدام مجموعة فرعية من الشبكة الكاملة، حيث تكون جميع تلك النظراء قابلة للوصول خارجياً. النظراء الذين لا يشاركون في netDb لا يزالون يستعلمون من تلك النظراء لكنهم لا يتلقون رسائل تخزين أو بحث netDb غير المرغوب فيها. المشاركة في netDb ستكون ذاتية الاختيار ومحددة من المستخدم - ستختار routers ما إذا كانت تريد نشر علامة في routerInfo الخاصة بها تفيد برغبتها في المشاركة بينما يختار كل router النظراء التي يريد التعامل معها كجزء من netDb (النظراء التي تنشر تلك العلامة لكنها لا تقدم أي بيانات مفيدة ستُتجاهل، مما يؤدي عملياً إلى إقصائها من netDb).

البديل الآخر هو عودة إلى الماضي، والرجوع إلى عقلية DTSTTCPW (افعل أبسط شيء يمكن أن يعمل) - floodfill netDb، ولكن مثل البديل أعلاه، يستخدم فقط مجموعة فرعية من الشبكة الكاملة. عندما يريد المستخدم نشر إدخال في floodfill netDb، يقوم ببساطة بإرساله إلى أحد الـ routers المشاركة، وينتظر ACK، ثم بعد 30 ثانية، يستعلم مشارك عشوائي آخر في floodfill netDb للتحقق من أنه تم توزيعه بشكل صحيح. إذا كان الأمر كذلك، عظيم، وإن لم يكن، فقط كرر العملية. عندما يستقبل floodfill router عملية netDb store، يرد بـ ACK فوراً ويضع عملية netDb store في قائمة انتظار لجميع أقرانه المعروفين في netDb. عندما يستقبل floodfill router استعلام netDb lookup، إذا كان لديه البيانات، يرد بها، ولكن إذا لم تكن لديه، يرد بالـ hashes لنحو 20 قريناً آخر في floodfill netDb.

من منظور اقتصاديات الشبكة، فإن floodfill netDb مشابه جداً لـ netDb الأصلي المبني على البث، باستثناء أن تكلفة نشر إدخال معين يتحملها في الغالب النظراء الموجودون في netDb، وليس الناشر. عند توسيع هذا المفهوم قليلاً ومعاملة netDb كصندوق أسود، يمكننا رؤية إجمالي عرض النطاق الترددي المطلوب من قِبل netDb كالتالي:

recvKBps = N * (L + 1) * (1 + F) * (1 + R) * S / T

حيث:

N = number of routers in the entire network
L = average number of client destinations on each router
    (+1 for the routerInfo)
F = tunnel failure percentage
R = tunnel rebuild period, as a fraction of the tunnel lifetime
S = average netDb entry size
T = tunnel lifetime

إدخال بعض القيم:

recvKBps = 1000 * (5 + 1) * (1 + 0.05) * (1 + 0.2) * 2KB / 10m
         = 25.2KBps

هذا، بدوره، يتدرج خطياً مع N (عند 100,000 نظير، يجب أن يكون netDb قادراً على التعامل مع رسائل تخزين netDb التي يبلغ مجموعها 2.5 ميجابايت في الثانية، أو عند 300 نظير، 7.6 كيلوبايت في الثانية).

بينما قد يتلقى كل مشارك في netDb الخاص بـ floodfill جزءًا صغيرًا فقط من مخازن netDb المُولدة من العميل مباشرة، فإنهم جميعًا سيتلقون جميع الإدخالات في النهاية، لذا يجب أن تكون جميع روابطهم قادرة على التعامل مع recvKBps الكامل. في المقابل، سيحتاج جميعهم إلى إرسال (recvKBps/sizeof(netDb)) * (sizeof(netDb)-1) للحفاظ على تزامن النظراء الآخرين.

لن يتطلب floodfill netDb توجيه tunnel لعملية netDb أو أي اختيار خاص حول الإدخالات التي يمكن أن يجيب عليها ‘بأمان’، حيث أن الافتراض الأساسي هو أنها تخزن كل شيء. وبالنسبة لاستخدام مساحة القرص المطلوبة لـ netDb، فإنها تظل تافهة إلى حد كبير لأي جهاز حديث، حيث تتطلب حوالي 11 ميجابايت لكل 1000 peer (N * (L + 1) * S).

إن netDb الخاص بـ Kademlia سيقلل من هذه الأرقام، مما يجعلها مثالياً K على M مضروبة في قيمتها، حيث K = عامل التكرار و M هو عدد الـ routers في netDb (مثلاً 5/100، مما يعطي recvKBps بقيمة 126KBps و 536MB عند 100,000 router). لكن العيب في netDb الخاص بـ Kademlia هو التعقيد المتزايد للتشغيل الآمن في بيئة عدائية.

ما أفكر فيه الآن هو ببساطة تنفيذ ونشر floodfill netDb في شبكتنا الحية الموجودة، مما يسمح للأقران الذين يريدون استخدامها بانتقاء أقران آخرين مميزين كأعضاء والاستعلام منهم بدلاً من الاستعلام من أقران netDb التقليديين باستخدام Kademlia. متطلبات النطاق الترددي والقرص في هذه المرحلة تافهة بما فيه الكفاية (7.6 كيلوبايت في الثانية و3 ميجابايت مساحة قرص) وستزيل netDb تماماً من خطة التشخيص - القضايا التي تبقى للمعالجة ستكون ناتجة عن شيء غير متعلق بـ netDb.

كيف سيتم اختيار الأقران لنشر هذا العلم الذي يقول أنهم جزء من floodfill netDb؟ في البداية، يمكن القيام بذلك يدوياً كخيار تكوين متقدم (يتم تجاهله إذا لم يتمكن الـ router من التحقق من إمكانية الوصول إليه خارجياً). إذا قام عدد كبير جداً من الأقران بتعيين هذا العلم، كيف يختار المشاركون في netDb أيهم سيتم استبعادهم؟ مرة أخرى، في البداية يمكن القيام بذلك يدوياً كخيار تكوين متقدم (بعد إسقاط الأقران غير القابلين للوصول). كيف نتجنب تقسيم netDb؟ من خلال جعل الـ routers تتحقق من أن netDb تقوم بـ flood fill بشكل صحيح من خلال الاستعلام من K أقران netDb عشوائيين. كيف تكتشف الـ routers التي لا تشارك في netDb routers جديدة للتنقل من خلالها؟ ربما يمكن القيام بذلك عن طريق إرسال استعلام netDb معين بحيث يستجيب router netDb ليس بأقران في netDb، ولكن بأقران عشوائيين خارج netDb.

إن netDb الخاص بـ I2P مختلف جداً عن جداول التجزئة الموزعة التقليدية التي تحمل الأحمال - فهو يحمل فقط البيانات الوصفية للشبكة، وليس أي حمولة فعلية، وهذا هو السبب في أن netDb حتى لو كان يستخدم خوارزمية floodfill سيكون قادراً على تحمل كمية عشوائية من بيانات I2P Site/IRC/bt/mail/syndie/إلخ. يمكننا حتى القيام ببعض التحسينات مع نمو I2P لتوزيع هذا الحمل بشكل أكبر (ربما تمرير مرشحات bloom بين مشاركي netDb لرؤية ما يحتاجون لمشاركته)، لكن يبدو أنه يمكننا الاستمرار بحل أبسط بكثير في الوقت الحالي.

حقيقة واحدة قد تستحق التعمق فيها - ليس كل leaseSets بحاجة إلى نشرها في netDb! في الواقع، معظمها لا يحتاج إلى ذلك - فقط تلك المخصصة للوجهات التي ستتلقى رسائل غير مطلوبة (أي الخوادم). هذا لأن الرسائل المُلفوفة بـ garlic encryption المرسلة من وجهة إلى أخرى تتضمن بالفعل leaseSet الخاص بالمرسل بحيث أي إرسال/استقبال لاحق بين هاتين الوجهتين (خلال فترة زمنية قصيرة) يعمل دون أي نشاط من netDb.

إذن، بالعودة إلى تلك المعادلات، يمكننا تغيير L من 5 إلى شيء مثل 0.1 (بافتراض أن وجهة واحدة فقط من كل 50 وجهة هي خادم). المعادلات السابقة تجاهلت أيضاً الحمل على الشبكة المطلوب للإجابة على الاستعلامات من العملاء، ولكن بينما يكون هذا الحمل متغيراً جداً (حسب نشاط المستخدم)، فمن المحتمل جداً أن يكون غير مهم مقارنة بتكرار النشر.

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

إلغاء خوارزمية Kademlia

تم تعطيل Kademlia بالكامل في الإصدار 0.6.1.20.

(مقتبس من محادثة IRC مع jrandom 11/07)

يتطلب Kademlia مستوى أدنى من الخدمة لا يستطيع النموذج الأساسي توفيره (عرض النطاق الترددي، المعالج)، حتى بعد إضافة الطبقات (Kademlia الخالص أمر سخيف في هذه النقطة). Kademlia ببساطة لن يعمل. كانت فكرة جميلة، لكن ليس للبيئة العدائية والمتغيرة.

الوضع الحالي

يلعب netDb دورًا محددًا جدًا في شبكة I2P، وقد تم ضبط الخوارزميات وفقًا لاحتياجاتنا. هذا يعني أيضًا أنها لم يتم ضبطها لمعالجة الاحتياجات التي لم نواجهها بعد. I2P حاليًا صغيرة إلى حد ما (بضع مئات من routers). كانت هناك بعض الحسابات التي تشير إلى أن 3-5 من floodfill routers يجب أن تكون قادرة على التعامل مع 10,000 عقدة في الشبكة. تنفيذ netDb يلبي احتياجاتنا أكثر من الكافي في الوقت الحالي، لكن من المرجح أن يكون هناك مزيد من الضبط وإصلاح الأخطاء مع نمو الشبكة.

تحديث الحسابات 03-2008

الأرقام الحالية:

recvKBps = N * (L + 1) * (1 + F) * (1 + R) * S / T

حيث:

N = number of routers in the entire network
L = average number of client destinations on each router
    (+1 for the routerInfo)
F = tunnel failure percentage
R = tunnel rebuild period, as a fraction of the tunnel lifetime
S = average netDb entry size
T = tunnel lifetime

التغييرات في الافتراضات:

• L الآن حوالي .5، مقارنة بـ .1 أعلاه، بسبب شعبية i2psnark والتطبيقات الأخرى.
• F حوالي .33، لكن أخطاء اختبار tunnel مُصححة في 0.6.1.33، لذا ستتحسن كثيراً.
• بما أن netDb حوالي 2/3 routerInfos بحجم 5K و 1/3 leaseSets بحجم 2K، فإن S = 4K. حجم RouterInfo يتقلص في 0.6.1.32 و 0.6.1.33 حيث نزيل الإحصائيات غير الضرورية.
• R = فترة بناء tunnel: 0.2 كانت منخفضة جداً - ربما كانت 0.7 - لكن تحسينات خوارزمية البناء في 0.6.1.32 يجب أن تخفضها إلى حوالي 0.2 مع ترقية الشبكة. لنقل 0.5 الآن مع نصف الشبكة في .30 أو أقدم.

recvKBps = 700 * (0.5 + 1) * (1 + 0.33) * (1 + 0.5) * 4KB / 10m
         ~= 28KBps

هذا يحسب فقط للمتاجر - ماذا عن الاستعلامات؟

عودة خوارزمية Kademlia؟

(مقتبس من اجتماع I2P في 2 يناير 2007)

إن netDb الخاص بـ Kademlia لم يكن يعمل بشكل صحيح. هل هو ميت إلى الأبد أم أنه سيعود؟ إذا عاد، فإن الأقران في netDb الخاص بـ Kademlia سيكونون مجموعة فرعية محدودة جداً من الموجهات في الشبكة (في الأساس عدد موسع من أقران floodfill، إذا/عندما لا تستطيع أقران floodfill التعامل مع الحمولة). ولكن حتى لا تستطيع أقران floodfill التعامل مع الحمولة (ولا يمكن إضافة أقران آخرين قادرين على ذلك)، فهو غير ضروري.

مستقبل Floodfill

(مقتبس من محادثة IRC مع jrandom 11/07)

إليك اقتراح: فئة السعة O تصبح floodfill تلقائياً. همم. ما لم نكن متأكدين، قد ننتهي بطريقة أنيقة لشن هجمات DDoS على جميع router من فئة O. هذا هو الحال تماماً: نريد التأكد من أن عدد floodfill أصغر ما يمكن مع توفير إمكانية وصول كافية. إذا/عندما تفشل طلبات netDb، فحينها نحتاج لزيادة عدد نظراء floodfill، ولكن في الوقت الحالي، لست على دراية بمشكلة في جلب netDb. يوجد 33 نظير من فئة “O” وفقاً لسجلاتي. 33 هو عدد /كبير جداً/ لجعلهم floodfill.

إذن floodfill يعمل بشكل أفضل عندما يكون عدد الأقران في تلك المجموعة محدود بقوة؟ وحجم مجموعة floodfill يجب ألا ينمو كثيراً، حتى لو كانت الشبكة نفسها تنمو تدريجياً؟ 3-5 أقران floodfill يمكنهم التعامل مع 10 آلاف router إذا كنت أتذكر بشكل صحيح (نشرت مجموعة من الأرقام حول ذلك أشرح فيها التفاصيل في syndie القديم). يبدو وكأنه متطلب صعب التحقيق مع الانضمام التلقائي، خاصة إذا كانت العقد التي تنضم لا تستطيع الوثوق بالبيانات من الآخرين. مثلاً “دعنا نرى إذا كنت ضمن أفضل 5”، ولا يمكنها الوثوق إلا بالبيانات عن نفسها (مثلاً “أنا بالتأكيد من فئة O، وأنقل 150 KB/s، وأعمل منذ 123 يوماً”). وأفضل 5 مضر أيضاً. بشكل أساسي، إنه نفس الأمر مع خوادم دليل tor - يتم اختيارها من قبل أشخاص موثوقين (أي المطورين). نعم، الآن يمكن استغلاله من خلال الانضمام الاختياري، ولكن ذلك سيكون من السهل اكتشافه والتعامل معه. يبدو في النهاية، قد نحتاج إلى شيء أكثر فائدة من Kademlia، ونجعل فقط الأقران القادرين بشكل معقول ينضمون إلى ذلك المخطط. فئة N وما فوق يجب أن تكون كمية كبيرة بما يكفي لقمع خطر قيام خصم بتسبيب رفض الخدمة، أتمنى ذلك. ولكن سيتعين أن يكون مختلفاً عن floodfill، بمعنى أنه لن يسبب حركة مرور ضخمة. كمية كبيرة؟ لـ DHT مبني على netDb؟ ليس بالضرورة مبني على DHT.

قائمة مهام Floodfill

ملاحظة: المعلومات التالية ليست حديثة. راجع صفحة netDb الرئيسية للحصول على الحالة الحديثة وقائمة بالأعمال المستقبلية.

كانت الشبكة تعمل بـ floodfill واحد فقط لعدة ساعات في 13 مارس 2008 (تقريباً 18:00 - 20:00 بالتوقيت العالمي المنسق)، وقد تسبب ذلك في الكثير من المشاكل.

التغييران المُنفذان في الإصدار 0.6.1.33 يجب أن يقللا من الاضطراب الناجم عن إزالة أو تغيير عقد floodfill:

1. عشوائية اختيار floodfill peers المستخدمة للبحث في كل مرة. هذا سيساعدك على تجاوز الأقران المعطلة في نهاية المطاف. هذا التغيير أصلح أيضاً خطأ خطير كان يؤدي أحياناً إلى جنون كود البحث في ff.
2. تفضيل floodfill peers التي تعمل. الكود الآن يتجنب الأقران الموجودة في القائمة السوداء أو المعطلة أو التي لم نسمع منها خلال نصف ساعة، إذا كان ذلك ممكناً.

إحدى الفوائد هي تحقيق اتصال أول أسرع إلى موقع I2P (أي عندما تحتاج إلى جلب الـ leaseset أولاً). مهلة البحث هي 10 ثوانِ، لذا إذا لم تبدأ بسؤال نظير معطل، يمكنك توفير 10 ثوانِ.

قد تكون هناك آثار على إخفاء الهوية في هذه التغييرات. على سبيل المثال، في كود store الخاص بـ floodfill، توجد تعليقات تفيد بأن الأقران المدرجين في القائمة السوداء لا يتم تجنبهم، حيث يمكن أن يكون أحد الأقران “سيئاً” ثم يرى ما يحدث. عمليات البحث أقل عرضة للخطر من عمليات التخزين - فهي أقل تكراراً وتكشف معلومات أقل. لذا ربما لا نعتقد أننا بحاجة للقلق بشأن ذلك؟ ولكن إذا أردنا تعديل التغييرات، فسيكون من السهل الإرسال إلى قرين مُدرج كـ “down” أو في القائمة السوداء على أي حال، فقط لا نحتسبه كجزء من الاثنين اللذين نرسل إليهما (حيث أننا لا نتوقع حقاً رداً).

هناك عدة أماكن حيث يتم اختيار floodfill peer - هذا الإصلاح يعالج واحداً فقط - من يبحث منه peer عادي [2 في الوقت الواحد]. الأماكن الأخرى حيث يجب تنفيذ اختيار floodfill أفضل:

1. من يقوم peer عادي بتخزين البيانات لديه [واحد في كل مرة] (عشوائي - يحتاج لإضافة تأهيل، لأن انتهاء المهلة الزمنية طويل)
2. من يبحث لديه peer عادي للتحقق من التخزين [واحد في كل مرة] (عشوائي - يحتاج لإضافة تأهيل، لأن انتهاء المهلة الزمنية طويل)
3. من يرسل إليه floodfill peer ردًا على بحث فاشل (الـ 3 الأقرب للبحث)
4. من يقوم floodfill peer بإغراقه بالبيانات (جميع floodfill peers الأخرى)
5. قائمة floodfill peers المرسلة في “همسة” NTCP كل 6 ساعات (رغم أن هذا قد لا يعود ضروريًا بسبب تحسينات floodfill الأخرى)

هناك الكثير مما يمكن وينبغي عمله:

• استخدام إحصائيات “dbHistory” لتقييم أفضل لتكامل نظير floodfill
• استخدام إحصائيات “dbHistory” للاستجابة الفورية لأنظار floodfill التي لا تستجيب
• أن نكون أذكى في المحاولات المتكررة - المحاولات المتكررة يتم التعامل معها بواسطة طبقة عليا، وليس في FloodOnlySearchJob، لذا تقوم بترتيب عشوائي آخر وتحاول مرة أخرى، بدلاً من تخطي أنظار ff التي جربناها للتو بشكل مقصود.
• تحسين إحصائيات التكامل أكثر
• استخدام إحصائيات التكامل فعلياً بدلاً من مجرد إشارة floodfill في netDb
• استخدام إحصائيات زمن الاستجابة أيضاً؟
• المزيد من التحسين في التعرف على أنظار floodfill الفاشلة

المكتملة مؤخراً:

• [في الإصدار 0.6.3] تنفيذ الانضمام التلقائي إلى floodfill لنسبة معينة من أقران الفئة O، بناءً على تحليل الشبكة.
• [في الإصدار 0.6.3] الاستمرار في تقليل حجم إدخال netDb لتقليل حركة مرور floodfill - نحن الآن في الحد الأدنى من الإحصائيات المطلوبة لمراقبة الشبكة.
• [في الإصدار 0.6.3] قائمة يدوية بأقران floodfill المراد استبعادها (قوائم الحظر حسب هوية router)
• [في الإصدار 0.6.3] تحسين اختيار أقران floodfill للتخزين: تجنب الأقران الذين لديهم netDb قديم، أو لديهم فشل حديث في التخزين، أو مدرجين في القائمة السوداء إلى الأبد.
• [في الإصدار 0.6.4] تفضيل أقران floodfill المتصلين بالفعل لتخزين RouterInfo، لتقليل عدد الاتصالات المباشرة بأقران floodfill.
• [في الإصدار 0.6.5] الأقران الذين لم يعودوا floodfill يرسلون routerInfo كاستجابة لاستعلام، بحيث يعرف router الذي يقوم بالاستعلام أنه لم يعد floodfill.
• [في الإصدار 0.6.5] ضبط إضافي لمتطلبات أن تصبح floodfill تلقائياً
• [في الإصدار 0.6.5] إصلاح ملف تعريف وقت الاستجابة استعداداً لتفضيل floodfills السريعة
• [في الإصدار 0.6.5] تحسين إدراج القوائم السوداء
• [في الإصدار 0.7] إصلاح استكشاف netDb
• [في الإصدار 0.7] تشغيل القوائم السوداء افتراضياً، حظر مُثيري المشاكل المعروفين
• [عدة تحسينات في الإصدارات الأخيرة، جهد مستمر] تقليل متطلبات الموارد على routers عالية النطاق الترددي و floodfill

هذه قائمة طويلة ولكن سيتطلب الأمر كل هذا العمل للحصول على شبكة مقاومة لهجمات حجب الخدمة من العديد من العقد التي تشغل وتطفئ مفتاح floodfill. أو التظاهر بأنها router floodfill. لم تكن أي من هذه المشاكل موجودة عندما كان لدينا اثنان فقط من ff routers، وكانا كلاهما يعملان على مدار الساعة طوال الأسبوع. مرة أخرى، غياب jrandom وجهنا إلى أماكن تحتاج إلى تحسين.

للمساعدة في هذا الجهد، يتم الآن عرض بيانات ملف تعريف إضافية لنظراء floodfill (اعتباراً من الإصدار 0.6.1.33) في صفحة “الملفات الشخصية” في وحدة تحكم router. سنستخدم هذا لتحليل البيانات المناسبة لتقييم نظراء floodfill.

الشبكة مقاومة جداً في الوقت الحالي، ومع ذلك سنواصل تحسين خوارزمياتنا لقياس والاستجابة لأداء وموثوقية نظراء floodfill. بينما لسنا في الوقت الراهن محصنين بالكامل ضد التهديدات المحتملة من floodfill الخبيثة أو هجوم DDOS على floodfill، فإن معظم البنية التحتية موجودة، ونحن في موقع جيد للاستجابة بسرعة في حالة نشوء الحاجة لذلك.