التواصل الشفاف بين العمليات

تُعدّ خدمة الاتصال الشفاف بين العمليات ( TIPC ) خدمة اتصال بين العمليات (IPC) في نظام لينكس، مصممة للعمل على مستوى المجموعة الحاسوبية. ^{[ 1 ]} وتُعرف أيضًا باسم مقابس نطاق المجموعة ، ^{[ 2 ]} وذلك على عكس خدمة مقابس نطاق يونكس المعروفة ؛ إذ تعمل الأخيرة على نواة واحدة فقط.

بعض ميزات TIPC:

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

يتوفر بروتوكول TIPC كوحدة نمطية في نواة لينكس الرئيسية ، ^{[ 3 ]} وبالتالي في معظم توزيعات لينكس. كما يوفر مشروع TIPC تطبيقات مفتوحة المصدر للبروتوكول لأنظمة تشغيل أخرى، بما في ذلك VxWorks من Wind River و Solaris من Sun Microsystems . تُكتب تطبيقات TIPC عادةً بلغة C (أو C++ ) وتستخدم مقابس من عائلة عناوين AF_TIPC. كما يتوفر دعم للغات Go و D و Perl و Python و Ruby .

يمكن لتطبيق TIPC استخدام ثلاثة أنواع من العناوين.

• عنوان الخدمة . يتكون هذا النوع من العناوين من مُعرِّف نوع الخدمة (32 بت) ومُعرِّف مثيل الخدمة (32 بت) . عادةً ما يُحدِّد مُبرمج التطبيق مُعرِّف النوع ويُضمِّنه في الكود، ولكن قد يلزم تنسيق قيمته مع التطبيقات الأخرى الموجودة في نفس المجموعة. أما مُعرِّف المثيل، فيُحسب غالبًا بواسطة البرنامج بناءً على معايير خاصة بالتطبيق.

• نطاق الخدمة . يُمثل هذا النوع من العناوين نطاقًا من عناوين الخدمة من النوع نفسه، مع عدد من الحالات يقع بين حد أدنى وحد أعلى . بربط مقبس بهذا النوع من العناوين، يُمكن جعله يُمثل العديد من الحالات، وهو أمرٌ أثبت فائدته في كثير من الأحيان.
• عنوان المقبس . يُشير هذا العنوان إلى مقبس مُحدد في المجموعة. ويتضمن رقم منفذ (32 بت) ورقم عقدة (32 بت) . يُولّد النظام رقم المنفذ عند إنشاء المقبس، بينما يُحدد رقم العقدة إما من خلال الإعدادات، أو - بدءًا من Linux 4.17 - يُولّد من هوية العقدة المُقابلة. يُمكن استخدام هذا النوع من العناوين للاتصال أو لإرسال الرسائل بنفس طريقة استخدام عناوين الخدمات، ولكنه صالح فقط طالما أن المقبس المُشار إليه موجود.

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

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

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

يمكن إنشاء الاتصالات بنفس طريقة بروتوكول TCP ، باستخدام مقابس accept()SOCK_STREAM . مع ذلك، في بروتوكول TIPC connect()، يستخدم كل من العميل والخادم عناوين أو نطاقات الخدمة بدلاً من أرقام المنافذ وعناوين IP. كما يوفر TIPC بديلين لهذا الإعداد القياسي.

• يمكن إنشاء المقابس كـ SOCK_SEQPACKET، مما يعني أن تبادل البيانات يجب أن يتم بوحدات لا تتجاوز 66000 بايت من الرسائل.
• يستطيع العميل بدء الاتصال ببساطة عن طريق إرسال رسالة بيانات إلى مقبس استقبال. وبالمثل، يمكن لمقبس الخادم المُنشأ الرد برسالة بيانات إلى العميل لإتمام الاتصال. وبهذه الطريقة، يوفر بروتوكول TIPC آلية ضمنية ، تُعرف أيضًا بآلية إعداد اتصال 0-RTT ، وهي آلية موفرة للوقت بشكل خاص في كثير من الحالات.

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

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

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

• لا يمكن إجراء المراسلة إلا داخل مجموعة مغلقة من منافذ الأعضاء.

  

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

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

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

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

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

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

قبل إصدار لينكس 4.17، كان يجب تكوين كل عقدة برقم أو عنوان فريد مكون من 32 بت ، مع مراعاة بعض القيود. أما بدءًا من إصدار لينكس 4.17، فلكل عقدة هوية مكونة من 128 بت ، ويجب أن تكون فريدة ضمن مجموعة العقدة. ثم يُحسب رقم العقدة كقيمة تجزئة فريدة مضمونة من تلك الهوية.

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

يتم اكتشاف الجيران عبر البث المتعدد UDP أو البث من الطبقة الثانية، عند توفرهما. في حال عدم وجود دعم للبث/البث المتعدد في البنية التحتية، يمكن إجراء الاكتشاف باستخدام عناوين IP مُكوّنة بشكل صريح.

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

يجب حاليًا توفير الأمان عبر وسائط النقل التي تحمل بروتوكول TIPC. عند التشغيل عبر بروتوكول UDP، يمكن استخدام بروتوكول IPSec، أما عند التشغيل عبر الإيثرنت، فيُعدّ بروتوكول MACSec الخيار الأمثل. ويعمل فريق TIPC حاليًا على دراسة كيفية دعم بروتوكولي TLS أو DTLS، إما بشكل أصلي أو من خلال إضافة إلى مكتبة OpenSSL.

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

• Iproute2
• موقع IProute2 الإلكتروني
• الصفحة الرئيسية لـ TIPC
• صفحة مشروع TIPC على موقع SourceForge
• تتوفر العروض التوضيحية والأدوات المساعدة للتنزيل على موقع SourceForge