آیا تا به حال سعی کرده اید یک برنامه کامل را توسعه دهید که به d-bus متکی باشد
(بدون اینکه اطلاعات زیادی از d-bus داشته باشید) و زمانی که باید آن برنامه را در آن اجرا کنید
یک سرور بدون سر، ناگهان همه چیز از کار می افتد؟
خب… اساساً من همین کار را کردم.
امروز، ما در مورد تفاوت های بین گذرگاه سیستم و گذرگاه جلسه صحبت خواهیم کرد.
و چرا برای شما مهم است که برنامه خود را با درستی توسعه دهید
اصطلاح در ذهن
اتوبوس جلسه
Session bus یک اصطلاح ویژه برای d-bus است که یک گذرگاه پیام را مشخص می کند
(ارتباط) بین فرآیندها، و به اتصال کاربر گره خورده است. می توانید استفاده کنید
یک گذرگاه جلسه اگر برنامه شما نیاز به اجرا برای این کاربر دارد
و به آن محیط گره خورده است جلسه. اما به خاطر داشته باشید که این کار خواهد شد
نیاز دارید که برنامه شما روی سروری اجرا شود که نمایشگر گرافیکی دارد
قابلیت ها
نمونه هایی از آن:
- کجا
- گنوم
- و غیره…
اتوبوس سیستم
از سوی دیگر، گذرگاه سیستم برای ارتباطات فرآیندی در سطح سیستم استفاده می شود.
آنها به یک جلسه گرافیکی (مانند Session Bus) نیاز ندارند و می توانند
بدون هیچ مشکلی در سرورهای هدلس اجرا می شود.
گذرگاه سیستم برای شما نشان داده شده است که می توانید هر زمان که مجبور به توسعه آن هستید از آن استفاده کنید
برنامه ای که باید با سرویس دیگری در آن ارتباط برقرار کند
سرور/کامپیوتر، و لزوماً به هیچ چیز گرافیکی وابسته نیست.
چرا تفاوت بین این دو مهم است؟
تفاوت بین این دو مهم است که عمدتاً هنگام توسعه a
برنامه جدید اگر می خواهید چیزی را توسعه دهید که در یک اجرا شود
سرور/ابر/محیط زودگذر، شما باید این را در نظر داشته باشید
ماشین‌ها نمایشگر گرافیکی برای شما ندارند. شما باید بدانید
قبل از اینکه بتوانید کد خود را به آن منتشر کنید، به کدام نوع گذرگاه پیام متصل شوید
تولید.
در نهایت، اگر بخواهید خود را توسعه دهید، سردرد زیادی نخواهید داشت
سرویس با نوع “اشتباه” گذرگاه پیام، اما، این می تواند به این معنی باشد که شما
باید گردش کار خود را اصلاح کند، به تاخیر بیاندازد و احتمالاً آن را تطبیق دهد تا کار کند
با اتوبوس صحیح
چگونه اتوبوس صحیح را انتخاب کنم؟
در اصل، شما باید یک قانون بسیار ساده را دنبال کنید. اگر در حال توسعه یک برنامه جدید هستید
دیمونی که باید کاربر را در مورد چیزی (که در حال اجرا است) مطلع کند
باطن)، دیمون شما نیاز به دسترسی گرافیکی یا برقراری ارتباط با KDE، GNOME دارد
و غیره. که مورد استفاده عالی برای a است session bus.
اگر در حال توسعه سرویسی هستید که با یک سرویس پشتیبان خارجی صحبت می کند
(مثلاً یک API)، محاسباتی را انجام دهید، نیازی به به روز رسانی عناصر UI نیست
یا، و باید با سرویس های سیستم بیشتری ارتباط برقرار کنید، سپس می توانید بروید
با یک system bus.
به همین سادگی است.
نکته ای خاص در مورد گزینه گذرگاه سیستم
گذرگاه سیستم یک ویژگی خاص دارد که باید در اینجا گفته شود. اگر شما هستید
در حال اجرا خدمات خود را با معمولی session bus، به هیچ چیز اضافی نیاز نخواهید داشت
ترفندها یا ترفندها، زیرا قبلاً احراز هویت شده اید و از جلسه کاربر استفاده می کنید،
اتوبوس به طور خودکار تنظیم می شود که کاربر شما می تواند با آن تعامل داشته باشد
آن را
با این حال، برای system bus، از آنجایی که به جلسه گرافیکی نیاز ندارد،
شما نیاز به ایجاد یک .conf فایل تحت یک پوشه خاص که توسط dbus مدیریت می شود
تا به سرویس شما اجازه دهید نام خود را در اتوبوس داشته باشد و همچنین مشخص کنید کدام کاربران
می تواند از dbus خود پیام ارسال و دریافت کند.
فایل به شکل زیر است:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<!-- Allow the service to own the name -->
<policy context="default">
<allow own="com.example.service"/>
</policy>
<!-- Allow any user to invoke methods -->
<policy context="default">
<allow send_destination="com.example.service"/>
<allow receive_sender="com.example.service"/>
</policy>
</busconfig>
و باید در زیر قرار گیرد: /etc/dbus-1/system.d/com.example.service.conf
با انجام این کار، می توانید به سرویس خود اجازه دهید نام اتوبوس شما را بدست آورد
خواستن و همچنین اجازه می دهد تا کاربران خاص با آن ارتباط برقرار کنند.
مراجع
- فصل 01 – DBus سیستم گذرگاه پیام
