أخبار تكنلوجيا

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

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

وستبدأ الشركة بتنفيذ هذه الخطوة في 4 يناير 2022 – أي بعد أقل من أسبوع، وهو ما يعني المسمار الأخير في نعش النظام الشهير سابقًا.

كانت الشركة قد اتخذت خطوات قوية سابقًا مثل إيقاف المتجر الخاص بالتطبيقات وإيقاف تطبيق BBM للرسائل – صاحب الشهرة الواسعة سابقًا، لكنها الآن اتخذت خطوة نهائية لإيقاف النظام.

وقد سبق هذه الخطوة تبني بلاكبيري لنظام أندرويد في محاولة منها لإنقاذ ما يمكن إنقاذه من خلال إطلاق هواتف Evolve الذكية، وبعدها إطلاق هاتف Key عام 2018، ومن ثم إطلاق نسخة محدثة منها مع شاشة لمسية وأزرار كلاسيكية في نفس الوقت في 2019، لكنها منذ ذلك الوقت توقفت عن إطلاق المزيد من الهواتف.

المصدر:

liliputing

التدوينة بلاكبيري ستوقف دعم هواتفها بشكل نهائي في 4 يناير 2022 ظهرت أولاً على عالم التقنية.

قالت هيئة سلامة الطرق الأميركية، أمس الخميس، إن شركة تسلا تقوم باستدعاء أكثر من 475 ألفًا من سياراتها الكهربائية من طرازي 3 وS لمعالجة مشاكل تتعلق بكاميرا الرؤية الخلفية التي تزيد من مخاطر الاصطدام.

وتناقش الهيئة الوطنية لسلامة المرور على الطرق السريعة (NHTSA) مشكلة أخرى مرتبطة بالكاميرا مع صانع السيارات الكهربائية، أثناء تحقيق في نظام مساعد السائق.

تتراوح سنوات الطرازين المتأثرين بالاستدعاء بين 2014 و2021، ويساوي إجمالي عدد المركبات المسترجعة تقريبًا نصف مليون سيارة سلمتها تسلا العام الماضي.

وقالت هيئة تنظيم السوق في الصين اليوم الجمعة، إنه سيتم استدعاء حوالي 200 ألف سيارة من شركة تسلا في الصين.

وقال المنظم الفيدرالي إن الشركة المصنعة للسيارات الكهربائية في الولايات المتحدة ستستدعي 356309 سيارات من سنوات 2017-2020 من طراز 3 لمعالجة مشاكل كاميرا الرؤية الخلفية و119009 سيارات من طراز S بسبب مشاكل غطاء المحرك الأمامي، وفق ما نقلته "رويترز".

من جهتها، أكدت تسلا أنها لم تكن على علم بأي حوادث أو إصابات أو وفيات تتعلق بالمشاكل المذكورة في استدعاء سيارات طرازي 3 وS، على حد قول NHTSA.

وتراجعت أسهم تسلا بنسبة 3٪ في تداولات الصباح، لكنها انتعشت بعد ذلك وتم تداولها على ارتفاع طفيف عند 1.088.76 دولار.

ومن المتوقع أن تقوم شركة صناعة السيارات الأكثر قيمة في العالم، بالإبلاغ عن عمليات تسليم المركبات الفصلية القياسية في وقت مبكر من يوم السبت.

وقال منظم السوق الصينية، إن تسلا ستستدعي ما يقرب من 200000 سيارة في البلاد، بما في ذلك 19697 سيارة من موديل S المستورد و35836 سيارة من موديل 3 المستورد و144208 سيارات من موديل 3 صيني الصنع.

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

يسود الاعتقاد بأن سوق السيارات الكهربائية في العالم سوف يشهد انتعاشاً كبيراً خلال الشهور المقبلة، ولتسجل مبيعات السيارات التي تعمل بالكهرباء بشكل كامل ارتفاعاً ملحوظاً خلال العام 2022.

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

وتتوقع شركة (New AutoMotive) بيع أكثر من 300 ألف سيارة كهربائية جديدة تعمل بالبطارية (BEVs) في بريطانيا وحدها خلال العام 2022، بحسب تقرير نشرته الشركة واطلعت عليه "العربية نت".

وفي حال صحت هذه التوقعات فمن المحتمل أن تتجاوز مبيعات السيارات الكهربائية الجديدة مبيعات محركات الديزل في عام 2022.

وتشير الأرقام الصادرة عن جمعية مصنعي وتجار السيارات في بريطانيا إلى أن 11% من السيارات الجديدة المسجلة في أول 11 شهراً من عام 2021 كانت سيارات كهربائية، ارتفاعاً من 6% خلال نفس الفترة من عام 2020.

وقال بن نيلمز، رئيس قسم السياسات والأبحاث في شركة "نيو أوتو موتيف" إنه يتوقع استمرار الزيادة في الطلب.

وأضاف: "نعتقد أنه سيكون هناك 300 ألف سيارة كهربائية جديدة تُباع في بريطانيا خلال عام 2022، والذي من المحتمل أن تشكل حوالي 15% من السوق".

وتابع: "هذا النمو السريع هو أخبار إيجابية وجيدة، لكن 300 ألف سيارة كهربائية إضافية مقابل 32 مليون سيارة احتراق داخلي على الطريق هو أقل بكثير مما هو ممكن وما هو ضروري".

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

وسيتم حظر مبيعات السيارات والشاحنات الصغيرة الجديدة التي تعمل بالبنزين والديزل في بريطانيا اعتباراً من عام 2030.

وتقترح الحكومة مطالبة مصنعي السيارات ببيع نسبة معينة من السيارات والشاحنات الخالية من الانبعاثات اعتباراً من عام 2024 في إطار خطط للوصول إلى صافي انبعاثات الكربون الصفرية.

وقال نيلمز إنه من "الأهمية بمكان" أن يتم تحديد المتطلبات عند مستوى معين "ليرسل إشارة سياسة قوية تمكن المصنّعين من زيادة إنتاج وبيع السيارات الكهربائية".

وقال إن هذا يعني أنه "يمكن لعدد أكبر من سائقي السيارات الاستفادة من انخفاض تكاليف الوقود وتجربة قيادة أفضل، ويمكن لبقيتنا الاستفادة من هواء أنظف وتقليل انبعاثات الكربون بسرعة".

كشفت شركة نورث فولت السويدية لصناعة البطاريات يوم الأربعاء عن إنتاج أول خلية بطارية ليثيوم أيون في مصنعها في سكيلفتيا، مع الوفاء بالموعد النهائي لبدء الإنتاج في المصنع قبل نهاية عام 2021.

وقالت نورث فولت، التي تتنافس مع قسم تصنيع البطاريات في تسلا وقدرت قيمتها بـ 12 مليار دولار من قبل المستثمرين في يونيو، إنها أول بطارية من نوعها تم تصميمها وتطويرها وتجميعها بالكامل فيما يسمى بـ gigafactory من قبل شركة بطاريات أوروبية محلية.

ويمكن تصنيف مصنع غيغاوات كمصنع واسع النطاق حيث يتم قياس الإنتاج السنوي بالغيغاوات في الساعة (GWh). ومن المتوقع أن يبلغ إنتاج شركة نورث فولت في سكيلفتيا سنوياً 60 غيغاوات ساعة.

من جانبه قال الرئيس التنفيذي والمؤسس المشارك لشركة نورث فولت، بيتر كارلسون: "على مدار السنوات القادمة، نتطلع إلى قيام نورث فولت بتوسيع طاقتها الإنتاجية بشكل كبير لتمكين الانتقال الأوروبي إلى الطاقة النظيفة".

وتُصنع غالبية بطاريات السيارات الكهربائية في العالم حالياً في الولايات المتحدة وآسيا، وتأمل شركة نورث فولت في تغيير ذلك.

وعلى الرغم من أن عمرها أقل من ست سنوات، فقد وقعت شركة نورث فولت صفقات شراء بأكثر من 30 مليار دولار مع عملاء من بينهم شركات صناعة السيارات BMW وفولكس فاغن، وفولفو، وPolestar.

فيما أوضحت نورث فولت أن عمليات التسليم التجارية ستبدأ في عام 2022، مضيفة أن الطاقة الإنتاجية ستزيد إلى 60 غيغاوات/ساعة في السنوات المقبلة، وهو ما يكفي لتزويد البطاريات لنحو مليون سيارة كهربائية.

وجمعت الشركة أكثر من 6.5 مليار دولار من مجموعة من المستثمرين لمساعدتها على توسيع عملياتها.

وقد شارك غولدمان ساكس وفولكس فاغن في قيادة جولة التمويل الأخيرة، وهي الأكبر من نوعها حتى الآن، من قبل غولدمان ساكس وفولكس فاغن جنباً إلى جنب مع مستثمرين جدد بما في ذلك صناديق التقاعد السويدية AP1 وAP2 وAP3 وAP4 وصندوق التقاعد الكندي OMERS. كما يستثمر المستثمرون السابقون، مثل الرئيس التنفيذي لشركة سبوتيفاي، دانيل إيك، وشركة إدارة الاستثمار Baillie Gifford في الجولة.

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

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

ملاحظة: عند مشاهدة مستخدم لمقطع فيديو يوتيوب ضمن موقعك سوف تُشارك بيانات غير شخصية مع يوتيوب.

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

اضغط على إشارة "+" ثم اكتب اسم المكون الذي تبحث عنه YouTube، ثم اضغط عليه لاختياره.

أو تستطيع إضافة هذا المكون بطريقة أخرى من خلال كتابة /youtube ضمن جسم الصفحة والضغط على Enter أو اختيار المكون YouTube من القائمة التي ستظهر أثناء كتابتك للكلمة السابقة.

توجه ضمن يوتيوب إلى مقطع الفيديو الذي تريد تضمينه، ثم انسخ رابط URL من حقل العنوان في المتصفح.

الصق الرابط السابق ضمن حقل التضمي، ثم اضغط على تضمين، وأضف كلمات توضيحية أسفله إن أردت.

هكذا سوف يبدو لزوارك.

إن عملية تضمين قائمة تشغيل يوتيوب مشابهة لما سبق، حيث عليك التوجه إلى قائمة التشغيل ضمن يوتيوب، ثم نسخ رابط URL من حقل العنوان في المتصفح. توجه الآن إلى ووردبريس والصق الرابط ضمن حقل تضمين يوتيوب واضغط على تضمين.

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

يتضمن مكون يوتيوب إعدادات وخيارات ضمنه وضمن الشريط الجانبي الأيسر.

يتواجد شريط أدوات مكون يوتيوب فوق المكون عند تحديده.

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

تسمح لك أداة السحب بسحب المكون لأي مكان تريده، كما تستطيع تغيير ترتيب المكون لأعلى أو أسفل باستخدام الأسهم.

يتضمن خيار المحاذاة المحاذاة لليمين واليسار وعرض واسع وعرض كامل، وانتبه إلى أنك لا تستطيع استخدام العرض الكامل وعرض واسع إلا في حال كان القالب المُستخدم يسمح بذلك.

يسمح لك باستبدال الرابط الحالي برابط جديد.

تتضمن الخيارات:

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

تتضمن إعدادات الشريط الجانبي قسمين هما إعدادات الوسائط ومتقدم.

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

يتضمن هذا القسم رابط القفز HTML وحقل لإضافة أصناف CSS، ويكون رابط القفز هو عبارة عن عنوان ويب خاص لمكون يوتيوب يسمح لك بالربط مباشرةً مع المكون، بينما حقل أصناف CSS يسمح لك بإنشاء شيفرة CSS مُخصصة لتغيير تصميم المكون.

تستطيع استخدام مكون يوتيوب والاستفادة منه لأقصى درجة باتباع النصائح التالية.

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

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

اضغط على الصندوق إلى يسار Start of واضبط الزمن الذي تريد للفيديو أن يبدأ منه.

تستطيع نسخ الرابط الآن وإضافته إلى ووردبريس.

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

توجد بضع أسئلة تكرر حول مكون يوتيوب وهي:

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

تبث مقاطع الفيديو الحياة في موقعك وهي أداة ممتازة لزيادة التفاعل أيضًا، وأكثر ما يُميز مكون يوتيوب هو عدم الحاجة لتثبيت إضافة لعرض مقاطع الفيديو المفضلة لك على موقع ووردبريس.

ترجمة -وبتصرّف- للمقال How to Use the WordPress YouTube Embed Block لصاحبه Lindsay Pietroluongo.

• كيفية استخدام مكون تضمين Flickr في ووردبريس
• كيفية استخدام مكون HTML مخصص في ووردبريس
• كيفية استخدام مكون الشيفرة البرمجية في ووردبريس
• كيفية استخدام مكون الملف في ووردبريس

تقود شركة سامسونج قطاع الهواتف القابلة للطي ليس بسبب بدايتها في إطلاقها فحسب، بل بسبب التنوع والمزايا الكبيرة المتوفرة في هواتفها مقارنة مع هواتف الشركات الأخرى، وهو ما ساهم في مضاعفة مبيعات هذه الهواتف بنحو 4 مرات في 2021 مقارنة مع 2020.

تقول سامسونج إن هاتف Galaxy Z Flip 3 ساهم في تشجيع الناس نحو التحول إلى هواتفها وخاصة فئة الهواتف القابلة للطي، أكثر مما ساهمت فيه هواتفها الرائدة الأخرى في السوق.

وأضافت الشركة إلى أنها شهدت نموًا بنحو 150% في نسبة الأشخاص الذي تحولوا إلى هاتف Galaxy Z Flip 3 مقارنة مع أولئك الذين توجهوا نحو هواتف Note 20، وزيادة بنسبة 140% مقارنة مع الذين توجهوا إلى سلسلة Galaxy S21.

تقول سامسونج إنها تتوقع نمو سوق الهواتف القابلة للطي بنحو 10 مرات في عام 2023 مقارنة مع الآن، وهو ما يجعل الشركة في منافسة مع نفسها لتوفير أفضل الخيارات للمستخدمين وتجنب أي تجاوز من الشركات الأخرى مثل هواوي وشاومي.

المصدر:

Samsung

التدوينة مبيعات هواتف سامسونج القابلة للطي تضاعفت 4 مرات بفضل Galaxy Z Flip 3 ظهرت أولاً على عالم التقنية.

بدأنا بالحديث عن شبكات التراكب ثم تطرقنا إلى شبكات الند للند ثم بروتوكول البت تورنت وسنكمل في هذا القسم الأخير في الحديث عن شبكات توزيع المحتوى.

رأينا بالفعل كيف يسمح تشغيل بروتوكول HTTP عبر بروتوكول TCP لمتصفحات الويب باسترداد الصفحات من خوادم الويب، ولكن يعرف أي شخصٍ ينتظر إلى الأبد لاسترداد صفحة ويب أن النظام بعيدٌ عن الكمال. تُنشَأ شبكة الإنترنت الرئيسية backbone الآن من روابطٍ ذات 40 جيجابت في الثانية، لذلك ليس واضحًا سبب حدوث ذلك. هناك أربع نقاط اختناقٍ محتملة في النظام عندما يتعلق الأمر بتنزيل صفحات الويب هي:

• الميل الأول The first mile، حيث قد يحتوي الإنترنت على روابطٍ ذات سعةٍ عالية، ولكن هذا لا يساعدك على تنزيل صفحة ويب بصورةٍ أسرع عندما تكون متصلًا بخط DSL بسرعة 1.5 ميجابت في الثانية أو رابطٍ لاسلكي سيء الأداء.
• الميل الأخير The last mile، حيث يمكن أن يُحمَّل الرابط الذي يربط الخادم بالإنترنت بصورةٍ كبيرة عن طريق طلباتٍ كثيرة جدًا، حتى إذا كان حيز النطاق التراسلي bandwidth الإجمالي لذلك الرابط مرتفعًا جدًا.
• الخادم نفسه The server itself، حيث يحتوي الخادم على كميةٍ محدودةٍ من الموارد مثل وحدة المعالجة المركزية، والذاكرة، وحيز نطاق القرص الصلب وغير ذلك، ويمكن تحميله بصورةٍ كبيرة overload بسبب العديد من الطلبات المتزامنة.
• نقاط التناظر Peering points، حيث قد يكون لدى عددٍ من مزودي خدمة الإنترنت الذين يطبّقون جميعًا شبكة الإنترنت الرئيسية backbone أنابيبًا ذات حيز نطاقٍ تراسلي عالٍ، لكن لديهم القليل من الحافز لتوفير اتصالٍ عالي السعة لأندادهم؛ فإذا كنت متصلًا بمزود خدمة الإنترنت A وكان الخادم متصلًا بمزود خدمة الإنترنت B، فقد تُسقَط الصفحة التي تطلبها عند النقطة التي يتقابل فيها المزوّدان A وB مع بعضهما بعضًا.

ليس هناك الكثير من الأشياء الممكن فعلها بشأن المشكلة الأولى، ولكن يمكن استخدام النسخ أو التضاعف لمعالجة المشكلات المتبقية، وتُسمّى الأنظمة المسؤولة عن ذلك بشبكات توزيع المحتوى Content Distribution Networks -أو اختصارًا CDNs-، حيث تدير أكاماي Akamai أشهر شبكة CDN.

تتمثل فكرة شبكة CDN في توزيع مجموعةٍ من بدائل الخادم server surrogates جغرافيًا، والتي تضع الصفحات ضمن الذاكرة المخبئية في مجموعةٍ معينةٍ من خوادم الواجهة الخلفية backend servers. وبالتالي يمكن نشر الحِمل على عدة خوادم، بدلًا من أن ينتظر الملايين من المستخدمين إلى الأبد للاتصال عند ظهور قصةٍ إخباريةٍ كبيرة، حيث يُعرَف مثل هذا الموقف بالتجمّع المفاجئ flash crowd. وبدلًا من الاضطرار إلى عبور عددٍ من مزودي خدمة الإنترنت للوصول إلى الموقع www.cnn.com، فيجب أن يكون ممكنًا الوصول إلى خادمٍ بديلٍ دون الحاجة إلى عبور نقطة تناظر، إذا كانت هذه الخوادم البديلة منتشرةً عبر جميع مزودي خدمة الإنترنت الأساسيين. صيانةُ آلاف الخوادم البديلة في أنحاء شبكة الإنترنت مكلفٌ للغاية لأي موقعٍ يريد توفير وصولٍ أفضل إلى صفحات الويب الخاصة به. توفّر شبكات CDN التجارية هذه الخدمة للعديد من المواقع، وهذا يؤدي إلى تسديد التكلفة عبر العديد من العملاء.

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

لا يحلّ وجودُ مجموعةٍ كبيرة من الخوادم الموزّعة جغرافيًا المشكلة تمامًا، حيث تحتاج شبكات CDN أيضًا إلى توفير مجموعةٍ من مُعيدات التوجيه redirectors التي تمرر طلبات العميل إلى الخادم الأنسب، كما هو موضحٌ في الشكل السابق. يتمثل الهدف الأساسي من معيدات التوجيه بتحديد الخادم لكل طلبٍ ينتج عنه أفضل وقت استجابةٍ response time للعميل؛ أما الهدف الثانوي فهو معالجة النظام عددًا من الطلبات في الثانية والتي يستطيع العتاد الأساسي مثل روابط الشبكة وخوادم الويب دعمها. يُعَد متوسط عدد الطلبات الممكن تلبيتها في فترةٍ زمنيةٍ معينة، والمعروفة باسم إنتاجية النظام system throughput، مشكلةً أساسيةً عندما يكون النظام تحت عبءٍ ثقيل، مثل وصول تجمّعٍ مفاجئ إلى مجموعةٍ صغيرةٍ من الصفحات أو هجماتٍ موزَّعة لحجب الخدمة Distributed Denial of Service -أو اختصارًا DDoS- على موقعٍ ما، كما حدث لمواقع CNN وYahoo والعديد من المواقع البارزة الأخرى في فبراير (شباط) عام 2000.

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

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

الآلية الأولى هي تطبيق إعادة التوجيه عن طريق تعزيز نظام DNS لإرجاع عناوين خوادم مختلفة للعملاء، حيث يمكن لخادم DNS إرجاع عنوان IP للخادم الذي يستضيف صفحات الويب الخاصة بموقع CNN والمعروف عنه أنه يحتوي على أخف حِمل، عندما يطلب أحد العملاء تحليل resolve الاسم www.cnn.com على سبيل المثال؛ بينما قد ترجع مجموعةٌ معينةٌ من الخوادم العناوين فقط بطريقة جولة روبن round robin الدورية.

لاحظ أن دقة إعادة التوجيه المستندة إلى نظام DNS تكون عادةً على مستوى الموقع، مثل cnn.com عوضًا عن عنوان URL محدد، مثل:

•  https://www.cnn.com/2020/11/12/politics
• Biden-wins-arizona
• index.html

 لكن يمكن للخادم إعادة كتابة عنوان URL عند إرجاع رابطٍ مضمَّن، وبالتالي توجيه العميل بفعالية إلى الخادم الأنسب لهذا الكائن المحدد.

تستخدم شبكات CDN التجارية تركيبةً من إعادة كتابة عناوين URL مع إعادة التوجيه المستندة إلى نظام DNS، حيث يشير خادم DNS عالي المستوى أولًا ولأسبابٍ تتعلق بقابلية التوسع، إلى خادم DNS على المستوى الإقليمي، الذي يرد بعنوان الخادم الفعلي. تعدّل خوادم DNS فترات TTL لسجلات الموارد التي تعود إلى فترةٍ قصيرة جدًا مثل 20 ثانية، بهدف الاستجابة للتغيرات بسرعة، ويُعَد هذا ضروريًا حتى لا يضع العملاء النتائج في ذاكرةٍ مخبئية وبالتالي يفشلون في الرجوع إلى خادم DNS للحصول على أحدث ربطٍ بين عنوان URL والخادم.

الآلية الثانية هي استخدام ميزة إعادة توجيه بروتوكول HTTP، حيث يرسل العميل رسالة طلبٍ إلى الخادم، الذي يستجيب بخادمٍ جديدٍ أفضل يتوجب على العميل الاتصال به للحصول على الصفحة. تتطلب إعادة التوجيه المستندة إلى الخادم وقتًا إضافيًا ذهابًا وإيابًا عبر الإنترنت، ويمكن أيضًا أن تكون الخوادم عرضةً للحِمل الزائد بسبب مهمة إعادة التوجيه redirection نفسها. بدلًا من ذلك، إذا كانت هناك عقدةٌ قريبةٌ من العميل، مثل وكيل ويب محلي local Web proxy على درايةٍ بالخوادم المتاحة، فيمكنها اعتراض رسالة الطلب وإرشاد العميل لطلب الصفحة من خادمٍ آخر مناسب. إما أن يكون معيد التوجيه في هذه الحالة ضمن نقطة اختناقٍ بحيث تمر جميع الطلبات التي تغادر الموقع من خلالها، أو سيتعيّن على العميل التعاون من خلال معالجة الوكيل صراحةً، كما هو الحال مع الوكيل الكلاسيكي وليس الوكيل الشفّاف transparent proxy؛ الذي هو خادمٌ يقع بين حاسوبك والإنترنت ويعيد توجيه طلباتك واستجاباتك دون تعديلها.

قد تتساءل عن علاقة شبكات CDN بشبكات التراكب، حيث يتخذ معيد التوجيه المستند إلى الوكيل قرار توجيهٍ على مستوى التطبيق مثل عقدة التراكب، ويمرر طلبات HTTP بناءً على عنوان URL وعلى معرفته بموقع ومدى حِمل مجموعةٍ من الخوادم بدلًا من تمرير رزمة استنادًا إلى عنوانٍ ما address وبناءً على معرفته بمخطط الشبكة. لا تدعم معمارية الإنترنت الحالية إعادة التوجيه مباشرةً، حيث نعني بكلمة "مباشرةً" أن العميل يرسل طلب HTTP إلى معيد التوجيه، الذي يمرره إلى الوِجهة، بدلًا من تطبيق إعادة التوجيه بصورةٍ غير مباشرة عن طريق معيد التوجيه الذي يرجع عنوان الوجهة المناسب والعميل الذي يتصل بالخادم ذاته.

نستعرض الآن بعض الأمثلة عن السياسات التي قد يستخدمها مُعيدو التوجيه لتمرير الطلبات، حيث اقترحنا بالفعل سياسةً واحدةً بسيطةً وهي جولة روبن round-robin، وسيكون المثال الآخر هو اختيار أحد الخوادم المتاحة عشوائيًا. يوزع كلا الأسلوبين الحِمل بالتساوي عبر شبكة توصيل المحتوى، لكنهما لا يقلّلان من وقت الاستجابة المتوقَّع للعميل.

من الواضح عدم أخذ هذين الأسلوبين قُرب الشبكة في حساباتهما، وتجاهلهما أيضًا للمنطقة المحلية؛ أي يُعاد توجيه الطلبات الخاصة بعنوان URL نفسه إلى خوادم مختلفة، مما يقلل من احتمالية تخديم الصفحة من الذاكرة المخبئية الموجودة ضمن الخادم المحدد. هذا يفرض على الخادم استرداد الصفحة من قرصه الصلب، أو ربما من خادم الواجهة الخلفية. كيف يمكن لمجموعةٍ موزعةٍ من معيدات التوجيه أن تتسبب في انتقال الطلبات لنفس الصفحة إلى نفس الخادم أو إلى مجموعةٍ صغيرةٍ من الخوادم دون تنسيقٍ عالمي؟ الإجابة بسيطةٌ وهي: تستخدم جميع مُعيدات التوجيه شكلًا من أشكال تطبيق التعمية hashing لربط عناوين URL بمجالٍ صغير من القيم. الفائدة الأساسية من هذا النهج هي أنه لا حاجة لوجود اتصالٍ بين معيدي التوجيه لتحقيق عمليةٍ منسقة؛ فإن عملية التعمية تنتج نفس الخرج بغض النظر عن معيد التوجيه الذي يتلقى عنوان URL.

إذًا ما الذي يجعل مخطط التعمية جيدًا؟ مخطط تعمية النموذج الكلاسيكي، الذي يجري تعميةً على كل وحدة URL مع عددٍ من الخوادم، غير مناسبٍ لهذه البيئة، لأن حساب النموذج في حالة تغيير عدد الخوادم سيؤدي إلى تناقص الصفحات التي تحتفظ بتخصيصات الخادوم نفسها. لا نتوقع حدوث تغييراتٍ متكررةٍ في مجموعة الخوادم، إلا أن حقيقة إضافة خوادمٍ جديدة إلى المجموعة ستؤدي إلى إعادة تخصيص ضخمة أمرٌ غير مرغوبِ فيه.

البديل هو استخدام نفس خوارزمية التعمية المستقرة التي ناقشناها سابقًا، حيث يجري كل معيد توجيه أولًا تعميةً على كل خادمٍ ضمن الدائرة، ثم يجري أيضًا تعميةً إلى قيمةٍ على الدائرة لكل عنوان URL واصل، ويُعيَّن عنوان URL للخادم الأقرب في الدائرة مع قيمة التعمية الخاصة به. فإذا فشلت العقدة في هذا المخطط، فسينتقل حِملُها إلى جيرانها على الدائرة، وبالتالي فإن إضافة أو إزالة خادمٍ يؤدي فقط إلى تغييراتٍ محلية في تخصيصات الطلب.

يعرف كل معيد توجيه كيفية ربط مجموعة الخوادم مع الدائرة، لذلك يمكن لكل معيد توجيه اختيار الخادم الأقرب بصورةٍ مستقلة، على عكس حالة ند لند؛ حيث توجَّه الرسالة من عقدةٍ إلى أخرى من أجل العثور على الخادم الذي يكون معرّفه هو الأقرب إلى الكائنات. يمكن توسيع هذه الاستراتيجية بسهولة لأخذ حِمل الخادم ضمن حساباتنا، حيث نفترض معرفة معيد التوجيه الحِمل الحالي لكلٍ من الخوادم المتاحة. قد لا تكون هذه المعلومات محدَّثة تمامًا، ولكن يمكننا تخيل معيد التوجيه يحسب ببساطة عدد المرات التي مرر فيها طلبًا إلى كل خادمٍ في الثواني القليلة الماضية ويستخدم هذا العدد مثل تقديرٍ لحِمل هذا الخادم الحالي.

يجري معيد التوجيه تعميةً على عنوان URL المُستقبَل مع كلٍ من الخوادم المتاحة ويرتّب القيم الناتجة، حيث تحدّد هذه القائمة المرتَّبة بفعالية الترتيب الذي سينظر فيه معيد التوجيه في الخوادم المتاحة، ثم يتحرّك معيد التوجيه في هذه القائمة حتى يعثر على خادمٍ يكون الحِمل عليه أقل من حدٍ معين. تتمثل فائدة هذا الأسلوب في أن ترتيب الخادم يختلف باختلاف عنوان URL، لذلك إذا فشل خادمٌ ما، فسيُوزَّع حِمله بالتساوي بين الأجهزة الأخرى. يُعَد هذا النهج أساس بروتوكول توجيه ذاكرة المصفوفة المخبئية Cache Array Routing Protocol -أو اختصارًا CARP- الموضّح في الشيفرة التالية:

يتغير هذا المخطط مع زيادة الحِمل من استخدام الخادم الأول فقط في القائمة المُرتَّبة إلى نشر الطلبات على عدة خوادم. ستعالج خوادمٌ أقل انشغالًا أيضًا بعضَ الصفحات التي تتعامل معها الخوادم المشغولة. بما أن هذه العملية تستند إلى حِمل الخادم الكلي عوضًا عن الطلب على كل صفحةٍ مفردة، فقد تجد الخوادمُ التي تستضيف بعض الصفحات المطلوبة المزيدَ من الخوادم التي تتشارك معها حِملها، أكثر من الخوادم التي تستضيف بصورةٍ جماعية صفحاتٍ غير مطلوبة. ستُنسَخ بعض الصفحات غير المطلوبة ضمن النظام لمجرد أنها مُستضافة على خوادمٍ مشغولة، وإذا أصبحت بعض الصفحات مطلوبةً للغاية، فيمكن أن تكون جميع الخوادم في النظام مسؤولةً عن خدمة هذه الصفحات.

أخيرًا، يمكن إدخال تقارب الشبكة network proximity في المعادلة بطريقتين مختلفتين على الأقل. الطريقة الأولى هي إخفاء التمييز بين حِمل الخادم وتقارب الشبكة من خلال مراقبة المدة التي يستغرقها الخادم للاستجابة للطلبات واستخدام القياس الناتج مثل معاملٍ لحِمل الخادم في الخوارزمية السابقة. تميل هذه الإستراتيجية إلى تفضيل الخوادم القريبة / غير المحمَّلة كثيرًا على الخوادم البعيدة / المحمَّلة بصورةٍ كبيرة.

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

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

يحتاج التطبيق المستند إلى التراكب وجود بصمةٍ واسعةٍ ليكون فعالًا، أي وجود عدة نقاط تواجد حول العالم. تُنشَر موجهات IP على نطاقٍ واسع، لذلك إذا كان لديك إذنٌ لاستخدام مجموعةٍ منها مثل عقدٍ أساسية في شبكة التراكب الخاصة بك، فأنت جاهزٌ للعمل. لكن هذا لن يحدث، حيث لا يوجد مشغلو شبكات أو مسؤولو مؤسسةٍ على استعدادٍ للسماح للأشخاص العشوائيين بتحميل برمجيات التراكب على الموجهات الخاصة بهم.

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

توجد طريقةٌ للدفع لشخصٍ ما مقابل حقوق تحميل وتشغيل برنامجك على خوادمٍ منتشرةٍ في جميع أنحاء العالم؛ وهذا هو بالضبط ما توفره السحابات السلعية مثل Amazon AWS و Microsoft Azure و Google Cloud Platform، حيث توفّر السحابة عددًا غير محدودٍ من الخوادم ظاهريًا، ولكنها لا تقل أهميةً، إن لم تكن الأهم، عن مكان وجود هذه الخوادم، حيث تُوزَّع على نطاقٍ واسع عبر أكثر من 150 موقعًا متصلًا بصورةٍ جيدة.

لنفترض مثلًا أنك تريد بث مجموعةٍ من قنوات الفيديو أو الصوت الحية لملايين المستخدمين، أو أنك تريد دعم الآلاف من جلسات مؤتمرات الفيديو التي يربط كل منها عشرات المشاركين المُوزعين على نطاقٍ واسع. ستنشئ في كلتا الحالتين شجرة تراكب متعدد البث (شجرةٌ لكل قناة فيديو في المثال الأول، وشجرةٌ لكل جلسة مؤتمر في المثال الثاني)، مع وجود عقد التراكب في الشجرة في مجموعةٍ من تلك المواقع السحابية البالغ عددها 150 موقعًا. ثم تسمح للمستخدمين النهائيين، من متصفحات الويب ذات الأغراض العامة أو تطبيقات الهواتف الذكية المصممة لهذا الغرض، بالاتصال بشجرةٍ أو مجموعة شجرات البث المتعدد التي يختارونها. إذا كنت بحاجةٍ إلى تخزين قدرٍ من محتوى الفيديو أو الصوت لتشغيله في وقتٍ لاحق، لدعم تحويل الوقت time shifting؛ فيمكنك أيضًا شراء سعة تخزينٍ في بعض أو كل هذه المواقع السحابية، وبناء شبكة توزيع المحتوى الخاصة بك بفعالية.

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

ترجمة -وبتصرّف- للقسم Overlay Networks من فصل Applications من كتاب Computer Networks: A Systems Approach.

• المتطلبات اللازمة لبناء شبكة حاسوبية
• البرمجيات المستخدمة في بناء الشبكات الحاسوبية
• معمارية الشبكة الحاسوبية وشبكة الإنترنت (Network Architecture)
• الشبكات الحاسوبية متعددة الوصول (Multi-Access Networks)

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

تكمن أهمية بروتوكول بت تورنت في أن النَّسخ replication هو أحد الآثار الجانبية الطبيعية لعملية التنزيل downloading، فبمجرد تنزيل أحد الأنداد لقطعةٍ معينة، يصبح هذا الند مصدرًا آخر لتلك القطعة، وكلما زاد عدد الأنداد الذين ينزّلون قطعًا من الملف كلما حدث المزيد من النَّسخ للقطعة، مع توزيع التحميل بصورةٍ متناسبة، وزيادة حيز النطاق التراسلي الإجمالي المتاح لمشاركة الملف مع الآخرين. تُنزَّل القطع بترتيبٍ عشوائي لتجنب الموقف الذي يجد فيه الأنداد أنفسهم مفتقرين لنفس مجموعة القطع.

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

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

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

• حجم الملف الهدف.
• حجم القطعة.
• القيم المعمَّاة SHA-1 المحسوبة مسبقًا من كل قطعة؟
• عنوان URL لمتتبّع tracker السرب.

المتتبّع هو خادمٌ يتتبع عضوية السرب الحالية. سنرى لاحقًا أنه يمكن توسيع بروتوكول بت تورنت للتخلص من هذه النقطة المركزية التي قد تؤدي إلى حدوث اختناقٍ أو فشل. ينضم المنزِّل المحتمل بعد ذلك إلى السرب، ليصبح ندًا، عن طريق إرسال رسالةٍ إلى المتتبّع تحتوي على عنوان شبكته ومعرّف الند الذي أنشأه عشوائيًا لنفسه. تحمل الرسالة أيضًا القيمة المُعمَّاة SHA-1 للجزء الرئيسي من الملف، والتي تُستخدَم مثل معرّف سرب.

افترض أن الند الجديد يُدعَى P. يرد المتتبّع على الند P بقائمةٍ جزئيةٍ من الأنداد الذين يقدمون معرفاتهم وعناوين الشبكة الخاصة بهم، وينشئ الند P اتصالاتٍ عبر بروتوكول TCP مع بعض هؤلاء الأنداد. لاحظ أن الند P متصلٌ مباشرةً بمجموعةٍ فرعيةٍ فقط من السرب، على الرغم من أنه قد يقرر الاتصال بأندادٍ إضافيين أو طلب المزيد من الأنداد من المتتبّع. يرسل الند P معرّف السرب الخاص به ومعرّفَ الند لإنشاء اتصال بت تورنت بندٍ معين بعد إنشاء اتصال TCP الخاص به، ويرد الند بمعرّفه ومعرّف السرب؛ فإذا لم تتطابق معرّفات السرب، أو لم يكن معرّف الند الذي أجرى الرد هو ما يتوقعه الند P، فسيُلغى الاتصال.

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

كيف تُربَط الكائنات، أو القطع في هذه الحالة مع العقد الأنداد؟ سيحصل كل ندٍ في النهاية على جميع القطع، لذا فإن السؤال يتعلق بالقطع التي يمتلكها الند في وقتٍ معين قبل أن يحتوي على كل القطع أو حول الترتيب الذي ينزِّل به الندُ القطعَ. الإجابة هي أنهم ينزّلون القطع بترتيبٍ عشوائي، وذلك لمنعهم من الحصول على مجموعةٍ فرعيةٍ صارمةٍ أو مجموعةٍ شاملةٍ من القطع الخاصة بأيٍ من أندادهم.

يستخدم بروتوكول بت تورنت الموصوف حتى الآن متتبّعًا مركزيًا يشكل نقطة فشل واحدة للسرب ويمكن أن يكون نقطة اختناق للأداء. كما يمكن أن يكون أيضًا توفير متتبّعٍ مصدر إزعاجٍ لمن يرغب في إتاحة ملفٍ عبر بروتوكول بت تورنت. تدعم الإصدارات الأحدث من بروتوكول بت تورنت أيضًا الأسراب التي لا تحتوي متتبّعًا trackerless، والتي تستخدِم تطبيقًا يعتمد على جدول التعمية الموزَّع DHT؛ حيث لا يطبّق برنامج عميل بت تورنت الذي لا يحتوي متتبّعًا ند بت تورنت فحسب، بل يطبّق أيضًا ما نُطلق عليه أداة البحث عن الأنداد peer finder، التي تُسمَّى عقدة node باستخدام مصطلحات بت تورنت، والتي يستخدمها الند للعثور على أنداده.

تشكّل أدوات البحث عن الأنداد شبكةَ التراكب الخاصة بها باستخدام بروتوكولها الخاص عبر بروتوكول UDP لتطبيق جدول DHT، حيث تتضمّن شبكة أداة البحث أدوات بحثٍ عن الأنداد الذين ينتمي أندادهم المرتبطين بهم إلى أسرابٍ مختلفة؛ أي يشكّل كل سربٍ شبكةً مميزةً من أنداد بت تورنت، لكن تمتد شبكة أدوات البحث عن الأنداد عبر الأسراب بدلًا من ذلك.

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

عندما تحتاج أداة البحث F إلى العثور على أندادٍ من سرب معين، فإنها ترسل طلبًا إلى أدوات البحث في جدولها التي تكون معرّفاتها قريبةً من معرّف ذلك السرب، فإذا عرفت أداة البحث المتصلة أندادًا من هذا السرب، فإنها ترد بمعلومات الاتصال الخاصة بها؛ وإلا فإنها ترد بمعلومات الاتصال الخاصة بأدوات البحث في جدولها القريبة من السرب، بحيث يمكن لأداة البحث F الاستعلام بصورةٍ متكررةٍ عن أدوات البحث تلك. إذا وصل البحث إلى طريقٍ مسدود، نظرًا لعدم وجود أدوات بحثٍ أقرب إلى السرب، تُدخِل أداة البحث F معلومات الاتصال الخاصة بها والند المرتبط بها ضمن أدوات البحث الأقرب إلى السرب، وبالنتيجة يحدث إدخال أنداد سربٍ معين في جداول أدوات البحث القريبة من هذا السرب.

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

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

السلوك الجيد الذي يعتمد عليه بروتوكول بت تورنت هو رفع uploading الأنداد القطعَ إلى أندادٍ آخرين. نظرًا لحاجة مستخدم بت تورنت العادي لتنزيل الملف فقط بأسرع ما يمكن، فهناك إغراءٌ لتطبيق ندٍ يحاول تنزيل جميع القطع مع أقل قدرٍ ممكنٍ من الرفع،ويُعد هذا ندًا سيئَا. يشتمل بروتوكول بت تورنت على آلياتٍ تسمح للأنداد بمكافأة أو معاقبة بعضهم بعضًا بهدف التقليل من هذا السلوك السيء؛ فإذا أساء أحد الأنداد التصرفَ بعدم الرفع بصورةٍ جيدة إلى ندٍ آخر، فيمكن للند الثاني أن يخنق choke الند السيء، حيث يمكنه أن يقرر إيقاف الرفع إلى الند السيء، مؤقتًا على الأقل، ويرسل إليه رسالةً تفيد بذلك، وهناك أيضًا نوع من الرسائل لإخبار الند بإلغاء الاختناق. يستخدم الند آليةَ الاختناق أيضًا للحد من عدد اتصالات بت تورنت النشطة، للحفاظ على أداءٍ جيد لبروتوكول TCP. هناك العديد من خوارزميات الاختناق المحتملة، لكن ابتكار خوارزميةٍ جيدةٍ هو فنٌ بحد ذاته.

ترجمة -وبتصرّف- للقسم Overlay Networks من فصل Applications من كتاب Computer Networks: A Systems Approach.

• المتطلبات اللازمة لبناء شبكة حاسوبية
• البرمجيات المستخدمة في بناء الشبكات الحاسوبية
• بروتوكولات طرف إلى طرف End-to-End Protocols في الشبكات الحاسوبية