قام مشروع freedesktop.org أيضًا بتطوير مكتبة برمجية مجانية ومفتوحة المصدر تُسمى libdbus، كتطبيق مرجعي للمواصفات. هذه المكتبة ليست D-Bus نفسها، إذ توجد تطبيقات أخرى لمواصفات D-Bus، مثل GDBus (GNOME) [ 8 ] ، وQtDBus ( Qt /KDE) [ 9 ] ، و dbus-java [ 10 ] ، وsd-bus (جزء من systemd ) [ 11 ] .
ملخص
D-Bus هي آلية اتصال بين العمليات (IPC) صُممت في الأصل لتحل محل أنظمة اتصالات مكونات البرمجيات CORBA وDCOP، المستخدمة في بيئتي سطح المكتب GNOME و KDE Linux على التوالي. [ 12 ] [ 13 ] عادةً ما تُوزع مكونات بيئتي سطح المكتب هاتين على العديد من العمليات، حيث تُقدم كل عملية خدمة واحدة أو بضع خدمات فقط . ويمكن استخدام هذه الخدمات من قِبل تطبيقات العميل العادية أو من قِبل مكونات أخرى في بيئة سطح المكتب لأداء مهامها.
العمليات بدون D-Bus
نفس العمليات مع D-Bus
تتطلب مجموعات كبيرة من العمليات المتعاونة شبكة كثيفة من قنوات الاتصال الفردية (باستخدام أساليب الاتصال بين العمليات من نوع واحد إلى واحد) فيما بينها. يعمل D-Bus على تبسيط متطلبات الاتصال بين العمليات من خلال قناة مشتركة واحدة.
يوفر D-Bus تجريدًا لناقل برمجي يجمع جميع الاتصالات بين مجموعة من العمليات عبر قناة افتراضية مشتركة واحدة. [ 5 ] لا تعرف العمليات المتصلة بالناقل كيفية تنفيذه داخليًا، لكن مواصفات D-Bus تضمن إمكانية تواصل جميع العمليات المتصلة بالناقل فيما بينها من خلاله. يتسبب D-Bus في انخفاض الأداء بمقدار 2.5 ضعف على الأقل مقارنةً بالاتصال بين العمليات (IPC) من نوع واحد إلى واحد. [ 14 ]
تستفيد بيئات سطح المكتب في لينكس من إمكانيات D-Bus عن طريق إنشاء ناقلات متعددة، على وجه الخصوص: [ 15 ] [ 5 ] [ 16 ]
ناقل نظام واحد ، متاح لجميع مستخدمي النظام وعملياته، يوفر الوصول إلى خدمات النظام (أي الخدمات التي يقدمها نظام التشغيل وأيضًا أي برامج خفية للنظام )؛ و
ناقل جلسة لكل جلسة تسجيل دخول مستخدم، يوفر خدمات سطح المكتب لتطبيقات المستخدم في نفس جلسة سطح المكتب، ويسمح بتكامل جلسة سطح المكتب ككل.
يمكن لأي عملية الاتصال بأي عدد من ناقلات البيانات، شريطة أن يكون لديها إذن الوصول إليها. عمليًا، يعني هذا أن أي عملية مستخدم يمكنها الاتصال بناقل النظام وناقل جلسة العمل الحالية، ولكن ليس بناقلات جلسات مستخدم آخر، أو حتى بناقل جلسة مختلف يملكه نفس المستخدم. قد يتغير هذا القيد الأخير في المستقبل إذا تم دمج جميع جلسات المستخدم في ناقل مستخدم واحد. [ 17 ]
يوفر D-Bus وظائف إضافية أو يبسط الوظائف الحالية للتطبيقات، بما في ذلك مشاركة المعلومات، والنمطية، وفصل الصلاحيات . على سبيل المثال، يمكن لأي مشغل موسيقى قيد التشغيل حاليًا نشر معلومات حول مكالمة صوتية واردة عبر البلوتوث أو سكايب وتفسيرها، ويمكنه التفاعل عن طريق كتم الصوت أو إيقاف التشغيل مؤقتًا حتى انتهاء المكالمة. [ 18 ]
يُعرَّف كل اتصال بحافلة في سياق نظام D-Bus بما يُسمى اسم الحافلة . [ 4 ] يوجد نوعان من أسماء الحافلات: فريدة ومعروفة . يتكون اسم الحافلة المعروف من سلسلتين أو أكثر من الأحرف والأرقام والشرطات السفلية مفصولة بنقاط - وهو اسم نطاق معكوس . مثال على اسم حافلة صالح هو [ 5 ]org.freedesktop.NetworkManager .
عندما يُنشئ أحد العمليات اتصالاً بحافلة، تُخصص الحافلة لهذا الاتصال اسمًا خاصًا يُسمى اسم الاتصال الفريد . [ 16 ] [ 5 ] أسماء الحافلات من هذا النوع ثابتة لا تتغير - أي أنها مضمونة عدم تغييرها طالما أن الاتصال قائم - والأهم من ذلك، لا يمكن إعادة استخدامها خلال فترة عمل الحافلة. [ 4 ] [ 16 ] [ 5 ] هذا يعني أنه لن يُخصص أي اتصال آخر بتلك الحافلة اسم اتصال فريد كهذا، حتى لو أغلقت العملية نفسها الاتصال بالحافلة وأنشأت اتصالاً جديدًا. يسهل تمييز أسماء الاتصالات الفريدة لأنها تبدأ بعلامة النقطتين (:) المحظورة في غير ذلك. [ 16 ] [ 5 ] مثال على اسم اتصال فريد هو :1.1553(الأحرف التي تلي النقطتين ليس لها معنى محدد [ 16 ] ).
يمكن لعملية ما طلب أسماء حافلات إضافية لاتصالها، [ 16 ] شريطة ألا يكون أي اسم مطلوب مستخدمًا بالفعل من قبل اتصال آخر بالحافلة. في مصطلحات D-Bus، عندما يُخصص اسم حافلة لاتصال ما، يُقال إن هذا الاتصال يمتلك اسم الحافلة. [ 4 ] [ 16 ] وبهذا المعنى، لا يمكن أن يمتلك اسم الحافلة اتصالان في الوقت نفسه، ولكن على عكس أسماء الاتصالات الفريدة، يمكن إعادة استخدام هذه الأسماء إذا كانت متاحة: قد تستعيد عملية ما اسم حافلة تم تحريره - عمدًا أو عن غير قصد - من قبل عملية أخرى. [ 4 ] [ 5 ]
تكمن الفكرة وراء أسماء الحافلات الإضافية هذه، والتي تُعرف عادةً بالأسماء المعروفة ، في توفير طريقة للإشارة إلى خدمة باستخدام اسم حافلة مُحدد مسبقًا. [ 16 ] [ 5 ] على سبيل المثال، تقع الخدمة التي تُبلغ عن الوقت والتاريخ الحاليين في حافلة النظام ضمن العملية التي يمتلك اتصالها اسم الحافلة org.freedesktop.timedate1 ، بغض النظر عن العملية نفسها.
يمكن استخدام أسماء الحافلات كطريقة بسيطة لتنفيذ التطبيقات ذات النسخة الواحدة (تكتشف النسخ الثانية أن اسم الحافلة مستخدم بالفعل). [ 16 ] كما يمكن استخدامها لتتبع دورة حياة عملية الخدمة، حيث ترسل الحافلة إشعارًا عند تحرير اسم الحافلة نتيجةً لإنهاء عملية ما. [ 16 ]
نموذج الكائن
بسبب تصميمها الأصلي كبديلٍ لأنظمة اتصالاتٍ متعددةٍ تعتمد على المكونات، تشترك D-Bus مع سابقاتها في نموذج كائناتٍ للتعبير عن دلالات الاتصالات بين العملاء والخدمات. وتُحاكي المصطلحات المستخدمة في نموذج كائنات D-Bus تلك المستخدمة في بعض لغات البرمجة كائنية التوجه . لكن هذا لا يعني أن D-Bus يقتصر على لغات البرمجة كائنية التوجه، بل إن أكثر تطبيقاتها استخدامًا ( libdbus ) مكتوبة بلغة C ، وهي لغة برمجة إجرائية .
استعراض أسماء الحافلات والكائنات والواجهات والأساليب والإشارات الموجودة في حافلة D-Bus باستخدام D-Feet
في ناقل D-Bus، تُقدّم العملية خدماتها من خلال عرض كائنات . تحتوي هذه الكائنات على توابع يمكن استدعاؤها، وإشارات يمكنها إصدارها. [ 16 ] تُعرف التوابع والإشارات مجتمعةً بأعضاء الكائن . [ 4 ] يمكن لأي عميل متصل بالناقل التفاعل مع الكائن باستخدام توابعه، أو إرسال طلبات، أو إصدار أوامر له لتنفيذ إجراءات. [ 16 ] على سبيل المثال، يمكن للعميل الاستعلام عن كائن يُمثّل خدمة الوقت باستخدام تابع يُعيد التاريخ والوقت الحاليين. كما يمكن للعميل الاستماع إلى الإشارات التي يُصدرها الكائن عند تغيّر حالته نتيجةً لأحداث مُحدّدة، عادةً ما تكون مُرتبطة بالخدمة الأساسية. مثال على ذلك، عندما تُرسل خدمة تُدير أجهزةً مادية - مثل برامج تشغيل USB أو الشبكة - إشارةً تُفيد بإضافة جهاز مادي جديد. يجب على العملاء إبلاغ الناقل برغبتهم في تلقّي إشارات مُحدّدة من كائن مُعيّن، لأن ناقل D-Bus لا يُمرّر الإشارات إلا إلى العمليات التي لديها اهتمام مُسجّل بها. [ 5 ]
يمكن لعملية متصلة بحافلة D-Bus أن تطلب منها تصدير أي عدد تريده من كائنات D-Bus. يُعرَّف كل كائن بمسار كائن ، وهو سلسلة من الأرقام والحروف والشرطات السفلية مفصولة ومسبوقة بشرطة مائلة، سُميت كذلك لتشابهها مع مسارات نظام ملفات Unix . [ 4 ] [ 16 ] يختار العملية الطالبة مسار الكائن، ويجب أن يكون فريدًا في سياق اتصال الحافلة هذا. مثال على مسار كائن صالح هو /org/kde/kspread/sheets/3/cells/4/5. [ 16 ] مع ذلك، لا يُفرض -ولكن لا يُمنع أيضًا- إنشاء تسلسلات هرمية داخل مسارات الكائنات. [ 5 ] يعود اختيار اصطلاح التسمية الخاص بكائنات الخدمة بالكامل إلى مطوري هذه الخدمة، لكن يختار العديد من المطورين استخدام اسم النطاق المحجوز للمشروع كبادئة (مثل /org/kde ). [ 16 ]
يرتبط كل كائن ارتباطًا وثيقًا بوصلة ناقل البيانات المحددة التي تم تصديره منها، ومن وجهة نظر D-Bus، لا يوجد إلا في سياق هذه الوصلة. لذلك، لاستخدام خدمة معينة، يجب على العميل تحديد مسار الكائن الذي يوفر الخدمة المطلوبة، بالإضافة إلى اسم ناقل البيانات الذي تتصل به عملية الخدمة. [ 4 ] وهذا بدوره يسمح لعدة عمليات متصلة بناقل البيانات بتصدير كائنات مختلفة بمسارات كائنات متطابقة دون أي لبس.
تحدد الواجهة أعضاءً - طرقًا وإشارات - يمكن استخدامها مع كائن. [ 16 ] وهي مجموعة من تعريفات الطرق (بما في ذلك تمرير وإرجاع المعاملات) والإشارات (بما في ذلك معاملاتها) يتم تحديدها باسم مفصول بنقاط يشبه ترميز واجهات لغة جافا . [ 16 ] [ 5 ] مثال على اسم واجهة صالح هو org.freedesktop.Introspectable. [ 5 ] على الرغم من تشابههما، يجب عدم الخلط بين أسماء الواجهات وأسماء ناقل البيانات. يمكن لكائن D-Bus تنفيذ عدة واجهات، ولكن يجب عليه على الأقل تنفيذ واجهة واحدة، مما يوفر الدعم لكل طريقة وإشارة محددة بها. يُطلق على مجموعة جميع الواجهات التي ينفذها كائن ما اسم نوع الكائن . [ 4 ] [ 16 ]
عند استخدام كائن، يُنصح بأن يُقدّم برنامج العميل اسم واجهة العضو بالإضافة إلى اسمه، ولكن هذا إلزامي فقط في حال وجود لبس ناتج عن أسماء أعضاء مكررة متاحة من واجهات مختلفة يُنفّذها الكائن [ 4 ] [ 16 ] ، وإلا فسيكون العضو المُختار غير مُعرّف أو خاطئًا. أما الإشارة المُرسلة، فيجب أن تُشير دائمًا إلى الواجهة التي تنتمي إليها.
تحدد مواصفات D-Bus أيضًا العديد من الواجهات القياسية التي قد ترغب الكائنات في تطبيقها بالإضافة إلى واجهاتها الخاصة. [ 15 ] على الرغم من أنها اختيارية من الناحية الفنية، إلا أن معظم مطوري خدمات D-Bus يختارون دعمها في كائناتهم المُصدَّرة لأنها توفر ميزات إضافية مهمة لعملاء D-Bus، مثل الاستبطان . [ 5 ] هذه الواجهات القياسية هي: [ 15 ] [ 5 ]
org.freedesktop.DBus.Peer : يوفر طريقة لاختبار ما إذا كان اتصال D-Bus نشطًا. [ 5 ]
org.freedesktop.DBus.Introspectable : يوفر آلية استبطان تمكّن عملية العميل، أثناء التشغيل، من الحصول على وصف ( بتنسيق XML ) للواجهات والأساليب والإشارات التي ينفذها الكائن. [ 16 ] [ 15 ]
org.freedesktop.DBus.Properties : يسمح لكائن D-Bus بعرض خصائص أو سمات الكائن الأصلي الأساسي، أو محاكاتها إذا لم تكن موجودة. [ 15 ]
org.freedesktop.DBus.ObjectManager : عندما تقوم خدمة D-Bus بترتيب كائناتها بشكل هرمي، توفر هذه الواجهة طريقة للاستعلام عن كائن ما حول جميع الكائنات الفرعية الموجودة ضمن مساره، بالإضافة إلى واجهاتها وخصائصها، باستخدام استدعاء طريقة واحدة. [ 15 ]
تحدد مواصفات D-Bus عددًا من عمليات إدارة ناقل البيانات (تُسمى "خدمات الناقل") التي تُنفذ باستخدام الكائن /org/freedesktop/DBus الموجود في اسم الناقل org.freedesktop.DBus . [ 15 ] يحتفظ كل ناقل بهذا الاسم الخاص به، ويدير أي طلبات تُقدم خصيصًا لهذا المزيج من اسم الناقل ومسار الكائن. العمليات الإدارية التي يوفرها الناقل هي تلك المُحددة بواسطة واجهة الكائن org.freedesktop.DBus . تُستخدم هذه العمليات، على سبيل المثال، لتوفير معلومات حول حالة الناقل، [ 4 ] أو لإدارة طلب وتحرير أسماء ناقلات أخرى معروفة . [ 15 ] [ 5 ]
نموذج الاتصالات
صُممت D-Bus كنظام اتصال عام وعالي المستوى بين العمليات. ولتحقيق هذه الأهداف، تعتمد اتصالات D-Bus على تبادل الرسائل بين العمليات بدلاً من البيانات الأولية. [ 4 ] [ 16 ] رسائل D-Bus عبارة عن عناصر منفصلة عالية المستوى يمكن للعملية إرسالها عبر الناقل إلى عملية أخرى متصلة. تتميز الرسائل ببنية محددة جيدًا (حتى أنواع البيانات التي تحملها في حمولتها محددة)، مما يسمح للناقل بالتحقق من صحتها ورفض أي رسالة غير صحيحة. من هذا المنطلق، تُعد D-Bus أقرب إلى آلية استدعاء الإجراءات عن بُعد (RPC) منها إلى آلية الاتصال بين العمليات (IPC) التقليدية، حيث تمتلك نظام تعريف أنواع خاص بها ونظام تنسيق خاص بها . [ 4 ]
مثال على تبادل رسائل طلب واستجابة ثنائية لاستدعاء دالة عبر ناقل D-Bus. هنا، يستدعي برنامج العميل الدالة SetFoo() للكائن /org/example/object1 من برنامج الخدمة المسمى org.example.foo (أو ) في الناقل.:1.14
يدعم ناقل البيانات نمطين لتبادل الرسائل بين العميل وعملية الخدمة [ 4 ] :
طلب-استجابة فردي : هذه هي الطريقة التي يستدعي بها العميل دالة كائن. يرسل العميل رسالة إلى عملية الخدمة لتصدير الكائن، وترد الخدمة بدورها برسالة إلى عملية العميل. [ 16 ] يجب أن تحتوي الرسالة المرسلة من العميل على مسار الكائن، واسم الدالة المستدعاة (واسم واجهتها اختياريًا)، وقيم معلمات الإدخال (إن وجدت) كما هو محدد في واجهة الكائن المختارة. تحمل رسالة الرد نتيجة الطلب، بما في ذلك قيم معلمات الإخراج التي تُرجعها دالة الكائن عند استدعائها، أو معلومات الاستثناء في حال حدوث خطأ. [ 4 ] [ 16 ]
النشر/الاشتراك : هذه هي الطريقة التي يُعلن بها الكائن عن حدوث إشارة للأطراف المعنية. تقوم عملية خدمة الكائن ببث رسالة يمررها الناقل فقط إلى العملاء المتصلين المشتركين في إشارة الكائن. [ 16 ] تحمل الرسالة مسار الكائن، واسم الإشارة، والواجهة التي تنتمي إليها الإشارة، بالإضافة إلى قيم معلمات الإشارة (إن وجدت). الاتصال أحادي الاتجاه: لا توجد رسائل رد على الرسالة الأصلية من أي عملية عميل، لأن المُرسِل لا يعرف هويات المُستلمين ولا عددهم. [ 4 ] [ 16 ]
تتكون كل رسالة D-Bus من رأس وجسم. [ 16 ] يتألف الرأس من عدة حقول تُحدد نوع الرسالة، والمرسل، بالإضافة إلى المعلومات اللازمة لإيصال الرسالة إلى مُستلمها (اسم ناقل الوجهة، مسار الكائن، اسم الطريقة أو الإشارة، اسم الواجهة، إلخ). [ 16 ] [ 15 ] يحتوي الجسم على حمولة البيانات التي يُفسرها المُستقبِل - على سبيل المثال، وسائط الإدخال أو الإخراج. تُشفّر جميع البيانات بتنسيق ثنائي معروف يُسمى تنسيق السلك ، والذي يدعم تسلسل أنواع مختلفة، مثل الأعداد الصحيحة والأعداد العشرية، والسلاسل النصية، والأنواع المركبة، وما إلى ذلك، [ 15 ] ويُشار إليه أيضًا باسم التسلسل .
تحدد مواصفات D-Bus بروتوكول الاتصال السلكي : كيفية إنشاء رسائل D-Bus المراد تبادلها بين العمليات ضمن اتصال D-Bus. ومع ذلك، فهي لا تحدد طريقة النقل الأساسية لتسليم هذه الرسائل.
المكونات الداخلية
تتبع معظم تطبيقات D-Bus الحالية بنية التطبيق المرجعي. تتكون هذه البنية من عنصرين رئيسيين: [ 4 ]
مكتبة اتصالات من نقطة إلى نقطة تُطبّق بروتوكول D-Bus لتبادل الرسائل بين عمليتين. في التطبيق المرجعي، تُسمى هذه المكتبة libdbus . في تطبيقات أخرى، قد تُغلّف libdbus بمكتبة أخرى ذات مستوى أعلى، أو ربط لغة برمجة، أو تُستبدل تمامًا بتطبيق مستقل مختلف يؤدي الغرض نفسه. [ 19 ] تدعم هذه المكتبة الاتصالات من نقطة إلى نقطة فقط بين عمليتين. [ 16 ]
عملية dbus -daemon تعمل كخادم ناقل رسائل D-Bus. كل عملية متصلة بالناقل تحتفظ بوصلة D-Bus واحدة معه.عملية برمجية خاصة تعمل كخادم ناقل، وتتصل بها باقي العمليات باستخدام أي مكتبة اتصالات D-Bus من نقطة إلى نقطة. تُعرف هذه العملية أيضًا باسم خادم ناقل الرسائل [ 18 ] ، نظرًا لمسؤوليتها عن توجيه الرسائل من أي عملية متصلة بالناقل إلى عملية أخرى. في التطبيق المرجعي، يؤدي هذه المهمة dbus-daemon ، المبني بدوره على libdbus . وهناك تطبيق آخر لخادم ناقل الرسائل يُسمى dbus-broker ، المبني على sd-bus .
تتشارك العمليتان A وB اتصالاً مباشراً عبر ناقل D-Bus باستخدام مكتبة libdbus عبر مقبس نطاق Unix. ويمكنهما استخدام هذا الاتصال لتبادل الرسائل مباشرةً. [ 20 ] في هذه الحالة، لا يلزم استخدام أسماء الناقل. [ 16 ]
تتصل العمليتان A وB بخادم dbus-daemon باستخدام مكتبة libdbus عبر مقبس نطاق Unix. يمكنهما تبادل الرسائل وإرسالها إلى عملية ناقل الرسائل، التي بدورها تقوم بتسليمها إلى العملية المناسبة. في هذا السيناريو، تُعد أسماء الناقل ضرورية لتحديد العملية المستهدفة.
تستخدم مكتبة libdbus (أو ما يعادلها) داخليًا آلية اتصال بين العمليات (IPC) أصلية منخفضة المستوى لنقل رسائل D-Bus المطلوبة بين العمليتين على طرفي اتصال D-Bus. لا يحدد معيار D-Bus آليات نقل IPC معينة يجب استخدامها، إذ أن مكتبة الاتصالات هي التي تحدد طرق النقل التي تدعمها. على سبيل المثال، في أنظمة التشغيل الشبيهة بنظام Unix مثل Linux، تستخدم libdbus عادةً مقابس نطاق Unix كطريقة نقل أساسية، ولكنها تدعم أيضًا مقابس TCP . [ 4 ] [ 16 ]
يجب أن تتفق مكتبات الاتصالات لكلا العمليتين على طريقة النقل المختارة، وكذلك على القناة المستخدمة في الاتصال. تُحدد هذه المعلومات بما يُطلق عليه في D-Bus اسم " عنوان" . [ 5 ] [ 16 ] تُعتبر مقابس نطاق Unix كائنات نظام ملفات ، وبالتالي يمكن تحديدها بواسطة اسم ملف، لذا فإن العنوان الصحيح هو [ 4 ] [ 15 ]unix:path=/tmp/.hiddensocket . يجب على كلا العمليتين تمرير نفس العنوان إلى مكتبات الاتصالات الخاصة بهما لإنشاء اتصال D-Bus بينهما. يمكن للعنوان أيضًا توفير بيانات إضافية لمكتبة الاتصالات على شكل أزواج مفصولة بفواصل. [ 5 ] [ 15 ] بهذه الطريقة، على سبيل المثال، يمكنه توفير معلومات المصادقة لنوع اتصال محدد يدعمه.key=value
عند استخدام برنامج خادم ناقل الرسائل مثل dbus-daemon لتنفيذ ناقل D-Bus، يجب على جميع العمليات الراغبة في الاتصال بالناقل معرفة عنوان الناقل ، وهو العنوان الذي يُتيح للعملية إنشاء اتصال D-Bus مع عملية ناقل الرسائل المركزية. [ 4 ] [ 16 ] في هذه الحالة، يختار برنامج خادم ناقل الرسائل عنوان الناقل، ويتعين على العمليات الأخرى تمرير هذه القيمة إلى مكتبات libdbus أو ما يُماثلها. يُحدد dbus-daemon عنوان ناقل مختلفًا لكل مثيل ناقل يُوفره. تُحدد هذه العناوين في ملفات تكوين البرنامج.
يمكن لعمليتين استخدام اتصال D-Bus لتبادل الرسائل مباشرةً بينهما، [ 20 ] ولكن هذه ليست الطريقة المُثلى لاستخدام D-Bus. الطريقة المُعتادة هي استخدام خادم ناقل الرسائل (مثل dbus-daemon ) كنقطة اتصال مركزية تُنشئ كل عملية اتصال D-Bus مباشرًا بها. عندما تُرسل عملية ما - عميل أو خدمة - رسالة D-Bus، يستقبلها خادم ناقل الرسائل أولًا ثم يُسلّمها إلى المُستلم المُناسب. يُمكن اعتبار خادم ناقل الرسائل بمثابة مُوزّع أو مُوجّه مسؤول عن إيصال كل رسالة إلى وجهتها عن طريق إعادة توجيهها عبر اتصال D-Bus إلى عملية المُستلم. [ 16 ] يتم تحديد عملية المُستلم من خلال اسم ناقل الوجهة في حقل رأس الرسالة، [ 15 ] أو من خلال معلومات الاشتراك في الإشارات التي يحتفظ بها خادم ناقل الرسائل في حالة رسائل نشر الإشارات. [ 5 ] يمكن لبرنامج ناقل الرسائل أيضًا إنتاج رسائله الخاصة كرد فعل على شروط معينة، مثل رسالة خطأ إلى عملية أرسلت رسالة إلى اسم ناقل غير موجود. [ 16 ]
يُحسّن dbus-daemon مجموعة الميزات التي يوفرها D-Bus نفسه بإضافة وظائف جديدة. على سبيل المثال، يسمح تفعيل الخدمة بالتشغيل التلقائي للخدمات عند الحاجة، أي عند وصول أول طلب إلى أي اسم ناقل لهذه الخدمة إلى برنامج تشغيل ناقل الرسائل. [ 4 ] وبهذه الطريقة، لا تحتاج عمليات الخدمة إلى التشغيل أثناء تهيئة النظام أو تهيئة المستخدم، كما أنها لا تستهلك الذاكرة أو موارد أخرى عند عدم استخدامها. تم تنفيذ هذه الميزة في الأصل باستخدام أدوات مساعدة setuid ، [ 21 ] ولكن يمكن توفيرها الآن أيضًا من خلال إطار عمل تفعيل الخدمة في systemd . يُعد تفعيل الخدمة ميزة مهمة تُسهّل إدارة دورة حياة عمليات الخدمات (على سبيل المثال، متى يجب بدء تشغيل مكون سطح المكتب أو إيقافه). [ 16 ]
تأثر نظام D-Bus بشكل كبير بنظام DCOP المستخدم في الإصدارين 2 و3 من KDE ، وقد حلّ محل DCOP في إصدار KDE 4. [ 24 ] [ 23 ] [ 25 ] يدعم تطبيق D-Bus معظم أنظمة التشغيل المتوافقة مع POSIX ، كما توجد نسخة منه لنظام Windows . يُستخدم D-Bus في Qt 4، وفي GNOME لاحقًا . في GNOME، حلّ D-Bus تدريجيًا محل معظم أجزاء آلية Bonobo السابقة . كما يُستخدم أيضًا في Xfce .
كانت طبقة تجريد الأجهزة (التي أصبحت الآن قديمة) من أوائل التقنيات التي تبنت هذه التقنية . استخدمت طبقة تجريد الأجهزة (HAL) ناقل البيانات D-Bus لتصدير معلومات حول الأجهزة التي تمت إضافتها إلى الكمبيوتر أو إزالتها منه. [ 7 ]
يتوسع استخدام D-Bus بشكل مطرد ليتجاوز نطاق بيئات سطح المكتب ليشمل عددًا متزايدًا من خدمات النظام. على سبيل المثال، يستخدم كل من برنامج إدارة الشبكة NetworkManager ، وحزمة بروتوكول البلوتوث BlueZ، وخادم الصوت PulseAudio ، بروتوكول D-Bus لتوفير جزء من خدماتها أو جميعها. كما يستخدم systemd بروتوكول D-Bus للاتصال بين systemctl وsystemd، ويعمل أيضًا على تحويل برامج النظام التقليدية إلى خدمات D-Bus، مثل logind . [ 26 ] ومن بين المستخدمين الرئيسيين لـ D-Bus أيضًا Polkit ، الذي يُنفذ برنامج إدارة السياسات الخاص به كخدمة متصلة بناقل النظام. [ 27 ]
التطبيقات
libdbus
على الرغم من وجود العديد من تطبيقات D-Bus، فإنّ التطبيق المرجعي libdbus هو الأكثر استخدامًا ، وقد طوّره مشروع freedesktop.org نفسه الذي صمّم المواصفات. مع ذلك، يُعدّ libdbus تطبيقًا منخفض المستوى لم يُصمّم أبدًا للاستخدام المباشر من قِبل مطوّري التطبيقات، بل كدليل مرجعي لإعادة تنفيذ تطبيقات D-Bus الأخرى (مثل تلك المُضمّنة في المكتبات القياسية لبيئات سطح المكتب، أو في روابط لغات البرمجة ). يوصي مشروع freedesktop.org نفسه مطوّري التطبيقات بـ "استخدام أحد الروابط أو التطبيقات عالية المستوى" بدلاً من ذلك. [ 28 ]
GDBus
GDBus [ 8 ] هو تطبيق لبروتوكول D-Bus يعتمد على تدفقات GIO المضمنة في GLib ، ويهدف إلى استخدامه مع GTK+ و GNOME . لا يُعد GDBus مجرد غلاف لـ libdbus، بل هو إعادة تنفيذ كاملة ومستقلة لمواصفات وبروتوكول D-Bus. [ 29 ] كما يستخدم كل من MATE Desktop [ 30 ] و Xfce (الإصدار 4.14)، المبنيان أيضًا على GTK+ 3، بروتوكول GDBus.
ناقل البيانات SD
في عام 2013، أعاد مشروع systemd كتابة مكتبة libdbus بهدف تبسيط الكود، [ 31 ] ولكن هذا أدى أيضًا إلى زيادة ملحوظة في أداء ناقل البيانات D-Bus بشكل عام. في اختبارات معيارية أولية، وجدت BMW أن مكتبة D-Bus الخاصة بنظام systemd قد حسّنت الأداء بنسبة 360%. [ 32 ] وبحلول الإصدار 221 من systemd ، الذي صدر في عام 2015، أُعلن عن استقرار واجهة برمجة تطبيقات sd-bus . [ 33 ]
kdbus
يتم تنفيذ kdbus كبرنامج تشغيل جهاز حرفي. [ 34 ] [ 35 ] تتم جميع الاتصالات بين العمليات عبر عقد أجهزة حرفية خاصة في /dev/kdbus(انظر devfs ).
كان مشروع kdbus يهدف إلى إعادة تنفيذ D-Bus كآلية اتصال بين العمليات من نظير إلى نظير بوساطة النواة . إلى جانب تحسينات الأداء، كان من المفترض أن يتمتع kdbus بمزايا ناتجة عن ميزات أخرى لنواة لينكس، مثل مساحات الأسماء والتدقيق، [ 32 ] [ 36 ] والأمان الذي توفره النواة كوسيط، وحل مشكلات التزامن، والسماح باستخدام D-Bus أثناء بدء التشغيل وإيقاف التشغيل (حسب حاجة systemd). [ 37 ] وقد أثار تضمين kdbus في نواة لينكس جدلاً واسعاً، [ 38 ] وتم التخلي عنه لصالح BUS1 ، باعتباره وسيلة اتصال بين العمليات أكثر عمومية . [ 39 ]
↑ "مدونة هافوك، يوليو 2007" . مؤرشفة من الأصل بتاريخ 7 سبتمبر 2015. تم الاطلاع عليها بتاريخ 3 أكتوبر 2012 .
↑ وارد، برايان (2004). "14: مسح موجز لسطح مكتب لينكس". كيف يعمل لينكس: ما يجب أن يعرفه كل مستخدم متقدم ( الطبعة الثانية). سان فرانسيسكو: دار نشر نو ستارش (نُشر عام 2014). ص 305. ISBN9781593275679تم الاطلاع عليه بتاريخ 7 نوفمبر 2016. من أهم التطورات التي طرأت على بيئة سطح المكتب في لينكس هو ناقل سطح المكتب (D-Bus)، وهو نظام لتبادل الرسائل. تكمن أهمية D-Bus في كونه آلية اتصال بين العمليات، مما يسمح لتطبيقات سطح المكتب بالتواصل فيما بينها [...].
↑ فيرمولين، جيرون (14 يوليو 2013). "مقدمة إلى D-Bus" . FreeDesktop.org . تم الاطلاع عليه في 3 أكتوبر 2015. تم تصميم D-Bus [...] للاستخدام كطبقة وسيطة موحدة تحت بيئات سطح المكتب المجانية الرئيسية.
١ ٢ ٣ بالميري، جون (يناير ٢٠٠٥). "استقل حافلة D-BUS" . مجلة ريد هات. مؤرشف من الأصل في ٢٣ أكتوبر ٢٠١٥. تم الاطلاع عليه في ٣ نوفمبر ٢٠١٥ .
1 2 "gdbus" . مطور جنوم . تم الاسترجاع في 4 يناير 2015 .
↑ "وحدة QtDBus" . مشروع Qt . تم الاطلاع عليه في 1 يونيو 2015 .
↑ "وثائق DBus-Java" . FreeDesktop.org . تم الاطلاع عليه بتاريخ 4 يناير 2015 .
↑ بينينجتون، هافوك؛ ويلر، ديفيد؛ والترز، كولين. " دليل D-Bus" . تم الاطلاع عليه بتاريخ 21 أكتوبر 2015. بالنسبة لحالة استخدام جلسات سطح المكتب، تتمتع بيئات سطح المكتب GNOME وKDE بخبرة سابقة واسعة مع حلول الاتصال بين العمليات المختلفة مثل CORBA وDCOP. تم بناء D-Bus على هذه الخبرة وتم تخصيصه بعناية لتلبية احتياجات مشاريع سطح المكتب هذه على وجه الخصوص.
↑ فيرمولين، جيرون (14 يوليو 2013). " مقدمة إلى D-Bus" . FreeDesktop.org . تاريخ الاطلاع: 3 أكتوبر 2015. تم تصميم D-Bus في البداية ليحل محل نموذج المكونات الشبيه بـ CORBA الذي يقوم عليه بيئة سطح المكتب GNOME. على غرار DCOP (المستخدم في KDE)، من المقرر أن يصبح D-Bus مكونًا قياسيًا في بيئات سطح المكتب المجانية الرئيسية لأنظمة GNU/Linux وغيرها من المنصات.
↑ بوتيرينغ، لينارت (19 يونيو 2015). "واجهة برمجة تطبيقات sd-bus الجديدة لنظام systemd" . تم الاطلاع عليه في 21 أكتوبر 2015. نعمل على نقل الأمور إلى ناقل مستخدم حقيقي، حيث يوجد ناقل واحد فقط لكل مستخدم على النظام، بغض النظر عن عدد مرات تسجيل دخول هذا المستخدم.
↑ "ما هو D-Bus؟" . FreeDesktop.org . تاريخ الاطلاع: 29 أكتوبر 2015. توجد أيضًا بعض التطبيقات المُعاد تنفيذها لبروتوكول D-Bus للغات مثل C# وJava وRuby. لا تستخدم هذه التطبيقات تطبيق libdbus المرجعي.
1 2 "ما هو D-Bus؟" . FreeDesktop.org . تم الاطلاع عليه بتاريخ 29 أكتوبر 2015. يعتمد على إطار عمل عام لتمرير الرسائل من طرف إلى طرف، والذي يمكن استخدامه من قبل أي تطبيقين للتواصل مباشرة (دون المرور عبر خادم ناقل الرسائل) .
↑ "تفعيل نظام D-BUS" . FreeDesktop.org . تم الاطلاع عليه بتاريخ 18 فبراير 2016 .
↑ "ما هو D-Bus؟" . FreeDesktop.org . تاريخ الاطلاع: 5 يناير 2015. لم يُصمم التنفيذ منخفض المستوى في الأساس ليستخدمه مطورو التطبيقات، بل هو أساس لمطوري الربط ومرجع لإعادة التنفيذ. يُنصح، إن أمكن، باستخدام أحد روابط أو تطبيقات المستوى الأعلى.
↑ "الانتقال إلى GDBus" . مطورو جنوم . تم الاطلاع عليه بتاريخ 21 أكتوبر 2015. يستخدم dbus-glib تطبيق libdbus المرجعي، بينما لا يستخدمه GDBus. بدلاً من ذلك، يعتمد على تدفقات GIO كطبقة نقل، ولديه تطبيقه الخاص لإعداد اتصال D-Bus والمصادقة.
↑ "MATE: خارطة الطريق" . مؤرشف من الأصل بتاريخ 29 يوليو 2019. تم الاطلاع عليه بتاريخ 31 يناير 2019 .
