كيف خفّف Bram Cohen عبء الرفع في BitTorrent من دون أن يلغي مساهمة الأقران

الخلاصة

• نقل BitTorrent قسماً كبيراً من حركة الرفع لملف شائع من الناشر إلى من ينزّلونه. وبقي خادم الويب والمتعقّب والبذرة التي تحمل النسخة الكاملة الأولى ضمن مسار التوزيع.
• كان أسلوب choking القائم على المعاملة بالمثل الذي وصفه Cohen سياسةً في العميل، لا التزاماً يفرضه بروتوكول الاتصال. قد يرفع النظير أكثر مما يتلقّى، أو يكتفي بما يحسّن تنزيله، أو يتوقف عن المشاركة بعد اكتماله.
• أظهرت دراسة عام 2007 إمكان خفض الرفع مع تحسين أداء عميل استراتيجي. وترتبط نتائجها بالأسراب والقياسات التي درستها في حينه، ولا تصف كل سرب لاحق.

من يرسل النسخة الثانية؟

في تنزيل HTTP التقليدي، يرسل خادم المصدر نسخة الملف لكل طالب. وإذا اجتذب الملف جمهوراً كبيراً في وقت قصير، فعلى الناشر توفير سعة رفع أكبر أو قبول بطء التسليم. في ورقته الصادرة عام 2003، اقترح Bram Cohen توزيع هذه المهمة: ما إن يصبح الملف قيد التنزيل لدى عدة أشخاص، حتى يتبادلون أجزاءه ويضيفون سعة رفع إلى عملية التوزيع.

لا يختفي المصدر؛ بل يتغير موضع تراكم السعة. يبدأ خادم الناشر العملية، ثم يضيف الأقران الذين انضموا إلى السرب قدرةً على الإرسال. ورأى Cohen أن ذلك قد يجعل استضافة ملف ذي شعبية واسعة في متناول اليد، ولا سيما حيث لا تُحاسَب سعة الرفع لدى المستخدم على أساس الحجم. لكن هذا افتراض مرتبط بنظام التسعير، لا حقيقة عامة: الاتصال غير المحدود في الفاتورة يظل محتاجاً إلى شبكة وطاقة وسعة، كما أن خطط الوصول تختلف.

وتبقى هناك سلسلة تشغيلية صغيرة. يضع الناشر ملف بيانات وصفية بامتداد .torrent على خادم ويب عادي؛ ويساعد المتعقّب المنزّلين على العثور على بعضهم؛ ثم تبدأ بذرة تملك الملف كاملاً الإرسال. وصف Cohen استهلاك خادم الويب والمتعقّب بأنه محدود مقارنة بنقل الملف، بينما يتعين على البذرة إرسال نسخة كاملة واحدة على الأقل. الذي يعاد توزيعه هو معظم تدفق البيانات، لا نقطة الانطلاق.

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

المعاملة بالمثل ليست ضماناً للبروتوكول

يشرح Cohen أن كل نظير يختار لمن يرفع البيانات وفق صيغة من tit-for-tat. يمكن للعميل أن يطبّق choking، أي أن يوقف الإرسال مؤقتاً إلى اتصال معيّن من دون أن يمنع التنزيل منه. ويمكنه أيضاً إجراء optimistic unchoke، فيختبر دورياً اتصالاً لم يكن يحصل على البيانات، بحثاً عن شريك نقل أفضل.

لكن Cohen يضع حداً تقنياً واضحاً: خوارزمية choking ليست، بالمعنى الدقيق، جزءاً من بروتوكول BitTorrent السلكي. يتيح البروتوكول تبادل البيانات والإشارات، أما قرار العميل بمن يخدمه فيبقى سياسة تنفيذ محلية. ومن ثم فإن القول إن «BitTorrent يضمن التبادل المتكافئ» يحمّل البروتوكول ما لم يفرضه. فالنتيجة تتأثر بالأجزاء المتاحة، وتبدل الاتصالات، واختلاف العملاء، والسعة الصاعدة غير المستخدمة.

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

ما الذي اختبرته دراسة 2007؟

عاد Michael Piatek وTomas Isdal وThomas Anderson وArvind Krishnamurthy وArun Venkataramani عام 2007 إلى السؤال عما إذا كانت الحوافز تجعل BitTorrent متيناً. وباستخدام نماذج ضُبطت على سجلات حقيقية، وجدوا أن الأقران يقدمون موارد لا تحسّن أداءهم مباشرة. وصُمم عميل BitTyrant لاستغلال هذه المساحة عبر ضبط مجموعة الأقران النشطين ومعدل الرفع المخصص لكل اتصال.

يفيد ملخص مؤتمر USENIX بتحسن وسيط قدره 70% لعميل بسرعة 1 Mbit/s في الأسراب الحية التي قاسوها. وحذّر الباحثون أيضاً من أن الانتشار الشامل للعملاء الاستراتيجيين قد يخفض متوسط الأداء في السرب مقارنة بالعملاء الذين اختبروهم. تتحدى النتيجة فكرة أن tit-for-tat وحده يكفل مساهمة موثوقة، لكنها لا تقيس كل العملاء أو أسراب اليوم؛ ورقم 70% ليس وعداً عاماً بالسرعة.

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

النسخة الكاملة نقطة تحكم لا تختفي

يبدأ الناشر التوزيع بنشر البيانات الوصفية، وإتاحة متعقّب أو وسيلة أخرى لاكتشاف الأقران، وتشغيل بذرة كاملة. وبعد ذلك يقرر كل عميل مقدار مساهمته. لا يوجد في التصميم الذي وصفه Cohen موزّع مركزي يفرض حصة رفع على كل مستخدم.

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

السؤال التشغيلي ليس ما إذا كان BitTorrent قد «حل» الاستضافة، بل مقدار البيانات التي لا يزال المصدر يرسلها، وحصة الأقران الفعلية من الحمل، وما الذي يُبقي كل جزء قابلاً للاسترداد بعد انحسار الطلب. حوّل Cohen المنزّلين إلى موزعين محتملين؛ وتوضح البحوث اللاحقة لماذا ينبغي قياس هذه القدرة بدلاً من افتراضها.

المصادر

• Bram Cohen، “Incentives Build Robustness in BitTorrent” (2003).
• Bram Cohen، BEP 3: مواصفة بروتوكول BitTorrent.
• Michael Piatek وآخرون، “Do Incentives Build Robustness in BitTorrent?” (USENIX NSDI 2007)، مع النص الكامل.
• Heng Lu، “المواصفة الأولية الدنيا، والقرار المستقبلي المحلي، والتبني الطوعي لأنظمة تنسيق الإنترنت” (Note 64). تُستخدم هنا إطاراً تحريرياً فقط، وليست دليلاً على Cohen أو BitTorrent.