MOSQUITTO.CONF(5) قالب‌های فایل و قراردادها MOSQUITTO.CONF(5)

mosquitto.conf - فایل پیکربندی برای mosquitto

mosquitto.conf

mosquitto.conf فایل پیکربندی برای mosquitto است. تا زمانی که mosquitto دسترسی خواندن آن را داشته باشد، این فایل می‌تواند در هر مکانی قرار گیرد. به‌طور پیش‌فرض، mosquitto نیازی به فایل پیکربندی ندارد و از مقادیر پیش‌فرض فهرست‌شده در زیر استفاده خواهد کرد. برای اطلاعات بیشتر در مورد نحوه بارگذاری فایل پیکربندی، mosquitto(8) را ببینید.

می‌توان به mosquitto دستور داد تا با ارسال سیگنال SIGHUP مطابق آنچه در بخش Signals از mosquitto(8) توضیح داده شده است، فایل پیکربندی را دوباره بارگذاری کند. همه گزینه‌های پیکربندی قابل بارگذاری مجدد نیستند، همان‌طور که در توضیحات گزینه‌های زیر مشخص شده است.

ادامه این صفحه راهنما به بخش‌های زیر تقسیم شده است:

قالب فایل (File Format) شرحی از ساختار نوشتاری فایل پیکربندی.

احراز هویت (Authentication) بررسی گزینه‌های احراز هویت در دسترس.

گزینه‌های عمومی (General Options) گزینه‌های عمومی برای پیکربندی Mosquitto.

شنوندگان (Listeners) گزینه‌های عمومی برای پیکربندی شنوندگان، که راه‌های اتصال کلاینت‌های MQTT به Mosquitto هستند، و همچنین گزینه‌های SSL/TLS مبتنی بر گواهی و کلید از پیش اشتراک‌گذاری‌شده (PSK).

پیکربندی پل‌ها (Configuring Bridges) گزینه‌های عمومی برای پیکربندی پل‌ها، که روشی برای اتصال چندین کارگزار (broker) به یکدیگر است، و همچنین گزینه‌های SSL/TLS مبتنی بر گواهی و کلید از پیش اشتراک‌گذاری‌شده.

سایر (Other) بخش‌های فایل‌ها، باگ‌ها و همچنین ببینید.

تمام خطوطی که اولین نویسه آن‌ها # باشد، به عنوان توضیح (کامنت) در نظر گرفته می‌شوند.

خطوط پیکربندی با یک نام متغیر شروع می‌شوند. مقدار متغیر با یک فاصله (space) از نام متغیر جدا می‌شود.

گزینه‌های احراز هویت شرح داده شده در زیر در ترکیب با گزینه‌های شنونده (listener) امکانات گسترده‌ای را فراهم می‌کنند. هدف این بخش روشن ساختن این امکانات است. یک نمای کلی نیز در آدرس زیر در دسترس است: https://mosquitto.org/documentation/authentication-methods/

ساده‌ترین حالت، عدم استفاده از هیچ‌گونه احراز هویت است. در صورتی که گزینه دیگری تعیین نشده باشد، این حالت پیش‌فرض خواهد بود. پشتیبانی از رمزگذاری بدون احراز هویت با استفاده از گزینه‌های SSL/TLS مبتنی بر گواهی certfile و keyfile فراهم می‌شود.

پروتکل MQTT احراز هویت نام کاربری/گذرواژه را به عنوان بخشی از پروتکل ارائه می‌دهد. از گزینه password_file برای تعیین نام‌های کاربری و گذرواژه‌های معتبر استفاده کنید. اگر از این گزینه استفاده می‌کنید، حتماً از رمزگذاری شبکه بهره ببرید؛ در غیر این صورت نام کاربری و گذرواژه در برابر شنود آسیب‌پذیر خواهند بود. از گزینه per_listener_settings برای کنترل اینکه آیا گذرواژه‌ها به صورت سراسری الزامی باشند یا بر اساس هر شنونده، استفاده کنید.

نرم‌افزار Mosquitto افزونه Dynamic Security را ارائه می‌دهد که احراز هویت نام کاربری/گذرواژه و کنترل دسترسی را بسیار انعطاف‌پذیرتر از یک فایل گذرواژه مدیریت می‌کند. آدرس زیر را ببینید: https://mosquitto.org/documentation/dynamic-security/

هنگام استفاده از رمزگذاری مبتنی بر گواهی، سه گزینه بر احراز هویت تأثیر می‌گذارند. گزینه اول require_certificate است که می‌تواند روی true یا false تنظیم شود. اگر false باشد، بخش SSL/TLS کلاینت سرور را اعتبارسنجی می‌کند اما کلاینت ملزم به ارائه چیزی به سرور نیست: احراز هویت محدود به نام کاربری/گذرواژه توکار MQTT خواهد بود. اگر require_certificate برابر true باشد، کلاینت برای اتصال موفقیت‌آمیز باید یک گواهی معتبر ارائه دهد. در این حالت، گزینه‌های دوم و سوم، use_identity_as_username و use_subject_as_username، اهمیت می‌یابند. در صورت تنظیم روی true، گزینه use_identity_as_username باعث می‌شود مقدار نام عمومی (Common Name یا CN) از گواهی کلاینت به جای نام کاربری MQTT برای کنترل دسترسی استفاده شود. گذرواژه استفاده نمی‌شود زیرا فرض بر این است که فقط کلاینت‌های احراز هویت‌شده دارای گواهی‌های معتبر هستند. این بدان معناست که هر گواهی CA که در cafile یا capath وارد کنید، قادر به صدور گواهی‌های کلاینت معتبر برای اتصال به کارگزار شما خواهد بود. اگر use_identity_as_username برابر false باشد، کلاینت باید مانند حالت عادی (در صورت الزام توسط password_file) از طریق گزینه‌های MQTT احراز هویت شود. همین اصل برای گزینه use_subject_as_username نیز صدق می‌کند، اما کل موضوع گواهی (subject) به عنوان نام کاربری استفاده می‌شود، نه فقط CN.

هنگام استفاده از رمزگذاری مبتنی بر کلید از پیش اشتراک‌گذاری‌شده از طریق گزینه‌های psk_hint و psk_file، کلاینت باید قبل از برقراری هرگونه ارتباط MQTT، یک هویت و کلید معتبر برای اتصال به کارگزار ارائه دهد. اگر use_identity_as_username برابر true باشد، هویت PSK به جای نام کاربری MQTT برای اهداف کنترل دسترسی استفاده می‌شود. اگر use_identity_as_username برابر false باشد، کلاینت در صورت استفاده از گزینه password_file همچنان می‌تواند با استفاده از نام کاربری/گذرواژه MQTT احراز هویت کند.

هر دو رمزگذاری مبتنی بر گواهی و مبتنی بر PSK به ازای هر شنونده پیکربندی می‌شوند.

می‌توان افزونه‌های احراز هویت ایجاد کرد تا گزینه‌های password_file، acl_file و psk_file را با جستجوهای مبتنی بر مثلاً SQL ارتقا دهند.

پشتیبانی همزمان از چندین طرح احراز هویت امکان‌پذیر است. می‌توان پیکربندی‌ای ایجاد کرد که برای تمامی گزینه‌های رمزگذاری مختلف شرح داده شده در بالا دارای یک شنونده باشد و بنابراین روش‌های متعددی برای احراز هویت ارائه دهد.

acl_file مسیر فایل

نکته: پیشنهاد می‌شود به جای این گزینه از افزونه mosquitto_acl_file استفاده کنید. استفاده از افزونه‌ها برای احراز هویت و اعطای مجوز امکان کنترل بیشتری بر روی اعمال آن‌ها به شنوندگان مختلف، بدون نیاز به گزینه منسوخ‌شده per_listener_settings فراهم می‌کند.

مسیر یک فایل فهرست کنترل دسترسی (ACL) را تنظیم می‌کند. در صورت تعریف، محتوای فایل برای کنترل دسترسی کلاینت به موضوعات (topics) روی کارگزار استفاده می‌شود.

اگر این پارامتر تعریف شود، فقط به موضوعات فهرست‌شده دسترسی داده خواهد شد. دسترسی به موضوع با خطوطی با قالب زیر اضافه می‌شود:

topic [read|write|readwrite|deny] <topic>

نوع دسترسی با استفاده از "read"، "write"، "readwrite" یا "deny" کنترل می‌شود. این پارامتر اختیاری است (مگر اینکه <topic> شامل نویسه فاصله باشد) - در صورت عدم تعیین، دسترسی read/write خواهد بود. <topic> می‌تواند مانند اشتراک‌ها شامل نویسه‌های عام + یا # باشد. گزینه "deny" می‌تواند برای رد صریح دسترسی به موضوعی استفاده شود که در غیر این صورت با دستور گسترده‌تر read/write/readwrite مجاز می‌شد. هر موضوع "deny" قبل از موضوعاتی که دسترسی خواندن/نوشتن می‌دهند پردازش می‌شود.

اولین مجموعه موضوعات، با فرض اینکه allow_anonymous برابر true باشد، به کلاینت‌های ناشناس اعمال می‌شود. فهرست‌های دسترسی مربوط به کاربران خاص بعد از خط کاربر به صورت زیر اضافه می‌شوند:

user <username>

نام کاربری ذکر شده در اینجا همان نام کاربری در password_file است، نه شناسه کلاینت (clientid).

همچنین می‌توان ACLها را بر اساس جایگزینی الگو در موضوع تعریف کرد. قالب آن مانند کلمه کلیدی topic است، اما از pattern به عنوان کلمه کلیدی استفاده می‌شود.

pattern [read|write|readwrite|deny] <topic>

الگوهای موجود برای جایگزینی عبارتند از:

•%c برای تطبیق با شناسه کلاینت (client id)
•%u برای تطبیق با نام کاربری کلاینت

الگوی جایگزینی باید تنها متن در آن سطح از سلسله‌مراتب باشد. الگوهای ACL برای همه کاربران اعمال می‌شوند حتی اگر کلمه کلیدی "user" پیش‌تر داده شده باشد.

مثال:

pattern write sensor/%u/data

اجازه دسترسی برای پیام‌های اتصال پل:

pattern write $SYS/broker/connection/%c/state

اگر اولین نویسه یک خط از فایل ACL علامت # باشد، به عنوان توضیح در نظر گرفته می‌شود.

اگر per_listener_settings برابر true باشد، این گزینه تنها به شنونده‌ای که در حال حاضر پیکربندی می‌شود اعمال خواهد شد. اگر per_listener_settings برابر false باشد، این گزینه برای تمام شنوندگان اعمال می‌شود.

نکته: به‌طور کلی امکان اعطای دسترسی نوشتن به موضوعات درون درخت موضوعی $SYS وجود ندارد. استثنای آن $SYS/broker/connection/+/state است.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود. داده‌های ACL بارگذاری‌شده فعلی آزاد شده و دوباره بارگذاری خواهند شد. اشتراک‌های موجود پس از بارگذاری مجدد تحت تأثیر قرار خواهند گرفت.

همچنین ببینید: https://mosquitto.org/documentation/dynamic-security/

allow_anonymous [ true | false ]

مقدار بولی سراسری که تعیین می‌کند آیا کلاینت‌هایی که بدون ارائه نام کاربری متصل می‌شوند اجازه اتصال دارند یا خیر. در صورت تنظیم روی false باید ابزار اتصال دیگری برای کنترل دسترسی کلاینت احراز هویت‌شده ایجاد شود.

مقدار پیش‌فرض false است، مگر اینکه هیچ شنونده‌ای در فایل پیکربندی تعریف نشده باشد، که در این صورت روی true تنظیم می‌شود، اما اتصالات فقط از ماشین محلی مجاز خواهند بود.

اگر می‌خواهید این تنظیم را برای هر شنونده به طور جداگانه کنترل کنید، از گزینه listener_allow_anonymous استفاده نمایید.

(نکته: منسوخ‌شده) اگر per_listener_settings برابر true باشد، این گزینه فقط برای شنونده فعلی که در حال پیکربندی است اعمال می‌شود. اگر per_listener_settings برابر false باشد، این گزینه برای همه شنوندگان اعمال خواهد شد.


مهم
در نسخه 1.6.x و قبل‌تر، این گزینه به طور پیش‌فرض روی true بود مگر اینکه گزینه امنیتی دیگری تنظیم شده باشد.
با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

allow_duplicate_messages [ true | false ]

این گزینه منسوخ شده است و در نسخه آینده حذف خواهد شد. رفتار آن به صورت پیش‌فرض true خواهد بود.

اگر کلاینتی در چندین اشتراک مشترک شده باشد که هم‌پوشانی دارند، به عنوان مثال foo/# و foo/+/baz ، آنگاه MQTT انتظار دارد هنگامی که کارگزار پیامی در مورد موضوعی دریافت می‌کند که با هر دو اشتراک مطابقت دارد، مانند foo/bar/baz، کلاینت باید فقط یک بار پیام را دریافت کند.

نرم‌افزار Mosquitto برای برآورده کردن این نیاز ردیابی می‌کند که پیام به کدام کلاینت‌ها ارسال شده است. این گزینه اجازه می‌دهد این رفتار غیرفعال شود، که ممکن است در صورتی که تعداد زیادی کلاینت دارید که در یک مجموعه موضوع مشابه مشترک هستند و می‌خواهید مصرف حافظه را به حداقل برسانید، مفید باشد.

اگر از قبل می‌دانید که کلاینت‌های شما هرگز اشتراک‌های هم‌پوشان نخواهند داشت، می‌توان با خیال راحت آن را روی true تنظیم کرد، در غیر این صورت کلاینت‌های شما باید بتوانند حتی زمانی که QoS=2 دارند پیام‌های تکراری را به درستی پردازش کنند.

پیش‌فرض روی true است.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

allow_zero_length_clientid [ true | false ]

پروتکل‌های MQTT 3.1.1 و MQTT 5 به کلاینت‌ها اجازه می‌دهند با یک شناسه کلاینت با طول صفر متصل شوند و از کارگزار بخواهند یک شناسه کلاینت برای آن‌ها ایجاد کند. از این گزینه برای مجاز/غیرمجاز کردن این رفتار استفاده کنید. پیش‌فرض true است.

گزینه auto_id_prefix را نیز ببینید.

اگر per_listener_settings برابر true باشد، این گزینه تنها به شنونده فعلی که در حال پیکربندی است اعمال می‌شود. اگر per_listener_settings برابر false باشد، این گزینه به تمامی شنوندگان اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

auth_plugin_deny_special_chars [ true | false ]

اگر true باشد، قبل از انجام بررسی ACL، نام کاربری/شناسه کلاینت متقاضی بررسی، برای وجود نویسه‌های '+' یا '#' جستجو می‌شود. اگر هر یک از این نویسه‌ها در نام کاربری یا شناسه کلاینت پیدا شود، بررسی ACL قبل از ارسال به افزونه رد می‌شود.

این بررسی از مواردی جلوگیری می‌کند که در آن یک کاربر مخرب می‌تواند با استفاده از یکی از این نویسه‌ها به عنوان نام کاربری یا شناسه کلاینت خود، یک بررسی ACL را دور بزند. این همان مشکلی است که برای خود mosquitto با عنوان CVE-2017-7650 گزارش شد.

اگر کاملاً مطمئن هستید که افزونه‌ای که استفاده می‌کنید در برابر این حمله آسیب‌پذیر نیست (یعنی اگر هرگز از نام‌های کاربری یا شناسه‌های کلاینت در موضوعات استفاده نمی‌کنید) می‌توانید با تنظیم این گزینه روی false این بررسی اضافه را غیرفعال کرده و بنابراین تمام بررسی‌های ACL را به افزونه خود تحویل دهید.

پیش‌فرض روی true است.

به افزونه احراز هویت فعلی که در حال پیکربندی است اعمال می‌شود.

در حال حاضر با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

auto_id_prefix پیشوند

این گزینه منسوخ شده است، لطفاً به جای آن از listener_auto_id_prefix استفاده کنید.

اگر allow_zero_length_clientid برابر true باشد، این گزینه به شما امکان می‌دهد رشته‌ای را تنظیم کنید که به ابتدای شناسه‌های کلاینت ایجادشده به صورت خودکار اضافه شود تا دیده‌شدن آن‌ها در گزارش‌ها آسان‌تر شود. پیش‌فرض auto- است.

اگر per_listener_settings برابر true باشد، این گزینه فقط برای شنونده فعلی که در حال پیکربندی است اعمال می‌شود. اگر per_listener_settings برابر false باشد، این گزینه برای همه شنوندگان اعمال خواهد شد.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

autosave_interval ثانیه

تعداد ثانیه‌هایی که mosquitto بین هر بار ذخیره پایگاه داده درون حافظه روی دیسک منتظر می‌ماند. اگر روی 0 تنظیم شود، پایگاه داده درون حافظه فقط زمانی ذخیره می‌شود که mosquitto خارج شود یا سیگنال SIGUSR1 را دریافت کند. توجه داشته باشید که این تنظیم فقط در صورتی تأثیر دارد که پایداری (persistence) توکار فعال باشد. پیش‌فرض 1800 ثانیه (30 دقیقه) است.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

autosave_on_changes [ true | false ]

اگر true باشد، mosquitto تعداد تغییرات اشتراک، پیام‌های نگه‌داشته‌شده (retained) دریافت شده و پیام‌های صف‌بندی‌شده را می‌شمارد و اگر مجموع از autosave_interval بیشتر شود، پایگاه داده درون حافظه روی دیسک ذخیره خواهد شد. اگر false باشد، mosquitto با تلقی کردن autosave_interval به عنوان زمان بر حسب ثانیه، پایگاه داده درون حافظه را روی دیسک ذخیره می‌کند.

تنها به پایداری توکار اعمال می‌شود.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

check_retain_source [ true | false ]

این گزینه بر سناریویی تأثیر می‌گذارد که کلاینتی در یک موضوع که دارای پیام‌های نگه‌داشته‌شده است مشترک می‌شود. ممکن است کلاینتی که پیام نگه‌داشته‌شده را در موضوع منتشر کرده است، در زمان انتشار دسترسی داشته باشد، اما این دسترسی متعاقباً حذف شده باشد. اگر check_retain_source روی true (پیش‌فرض) تنظیم شده باشد، منبع یک پیام نگه‌داشته‌شده قبل از انتشار مجدد برای بررسی حقوق دسترسی بررسی می‌شود. وقتی روی false تنظیم شود، هیچ بررسی انجام نخواهد شد و پیام نگه‌داشته‌شده همیشه منتشر می‌شود.

این گزینه صرف نظر از گزینه per_listener_settings به صورت سراسری اعمال می‌شود.

clientid_prefixes پیشوند

این گزینه منسوخ شده است و در نسخه آینده حذف خواهد شد.

در صورت تعریف، فقط کلاینت‌هایی که شناسه کلاینت با پیشوندی مطابق با clientid_prefixes دارند، اجازه اتصال به کارگزار را خواهند داشت. برای مثال، تنظیم "secure-" در اینجا به این معنی است که کلاینت "secure-client" می‌تواند متصل شود اما کلاینت دیگری با شناسه "mqtt" نمی‌تواند. به‌طور پیش‌فرض، همه شناسه‌های کلاینت معتبر هستند.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود. توجه داشته باشید که کلاینت‌هایی که در حال حاضر متصل هستند تحت تأثیر هیچ تغییری قرار نخواهند گرفت.

connection_messages [ true | false ]

اگر روی true تنظیم شود، لاگ شامل ورودی‌هایی در هنگام اتصال و قطع اتصال کلاینت‌ها خواهد بود. اگر روی false تنظیم شود، این ورودی‌ها ظاهر نمی‌شوند.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

enable_control_api [ true | false ]

اگر روی true تنظیم شود، مسیر $CONTROL/broker/v1 فعال خواهد شد. این در حال حاضر امکان بررسی اینکه کدام افزونه‌ها فعال هستند را می‌دهد، اما در آینده امکان دسترسی به پیکربندی گزینه‌های عمومی کارگزار را فراهم خواهد کرد. اگر این را فعال کنید، باید مطمئن شوید که احراز هویت و کنترل دسترسی مناسب پیکربندی شده است، یعنی فقط اجازه دسترسی به $CONTROL/broker/# را برای مجموعه محدودی از کاربران بدهید.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

global_max_clients تعداد

حداکثر تعداد نشست‌های کلاینت مجاز در سراسر کارگزار. در این زمینه، یک نشست کلاینت به معنای کلاینتی است که در حال حاضر از طریق شبکه متصل است، یا کلاینتی که clean_session = False (در MQTT v3.x) دارد و قطع شده است، یا قطع شده و هنوز از بازه انقضای نشست خود فراتر نرفته است (در MQTT v5).

تنظیم max_connections را نیز ببینید که برای شنوندگان اعمال می‌شود. اگر global_max_clients را روی 1000 و max_connections روی یک شنونده را روی 10 تنظیم کنید، این بدان معناست که تنها 10 اتصال همزمان در یک زمان مجاز خواهد بود، با حداکثر کلی 1000 نشست کلاینت.

این گزینه به صورت سراسری اعمال می‌شود.

پیش‌فرض -1 (نامحدود) است.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

global_max_connections تعداد

حداکثر تعداد کلاینت‌های متصل همزمان مجاز در سراسر کارگزار.

تنظیمات global_max_clients و max_connections را نیز ببینید.

این گزینه به صورت سراسری اعمال می‌شود.

پیش‌فرض -1 (نامحدود) است.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

global_plugin مسیر فایل

یک ماژول خارجی برای گسترش ویژگی‌های کارگزار بارگذاری می‌کند. این افزونه‌ها را برای استفاده در تمام شنوندگان، صرف نظر از مقدار گزینه per_listener_settings بارگذاری می‌کند. این گزینه از همه جهات دیگر عملکردی مشابه گزینه plugin دارد.

اگر per_listener_settings true را تنظیم کرده و سپس هر دو گزینه global_plugin و یک plugin (که به یک شنونده خاص متصل خواهد شد) را تعریف کنید، افزونه سراسری همیشه ابتدا پردازش می‌شود.

اگر per_listener_settings false را تنظیم کنید، آنگاه global_plugin دقیقاً مانند plugin عمل می‌کند.

include_dir مسیر پوشه

فایل‌های پیکربندی خارجی را می‌توان با استفاده از گزینه include_dir اضافه کرد. این گزینه یک دایرکتوری را تعریف می‌کند که برای فایل‌های پیکربندی جستجو خواهد شد. همه فایل‌هایی که به '.conf' ختم می‌شوند به عنوان یک فایل پیکربندی بارگذاری می‌شوند. بهتر است این گزینه را به عنوان آخرین گزینه در فایل اصلی قرار دهید. این گزینه فقط از فایل پیکربندی اصلی پردازش می‌شود. دایرکتوری مشخص‌شده نباید شامل فایل پیکربندی اصلی باشد.

فایل‌های پیکربندی در include_dir به ترتیب الفبایی حساس به حروف بزرگ و کوچک بارگذاری می‌شوند، به‌طوری‌که حروف بزرگ هر حرف قبل از حروف کوچک همان حرف مرتب می‌شوند.

مثال: ترتیب بارگذاری برای include_dir. با داشتن فایل‌های b.conf، A.conf، 01.conf، a.conf، B.conf، و 00.conf درون include_dir، فایل‌های پیکربندی به این ترتیب بارگذاری می‌شوند:

00.conf
01.conf
A.conf
a.conf
B.conf
b.conf

اگر این گزینه چندین بار استفاده شود، هر گزینه include_dir به طور کامل به ترتیبی که در فایل پیکربندی اصلی نوشته شده‌اند پردازش می‌شود.

مثال: ترتیب بارگذاری برای چندین include_dir. با فرض دایرکتوری one.d شامل فایل‌های B.conf و C.conf، و دایرکتوری دوم two.d شامل فایل‌های A.conf و D.conf، و یک پیکربندی:

include_dir one.d
include_dir two.d

سپس فایل‌های پیکربندی به این ترتیب بارگذاری می‌شوند:

# فایل‌ها از one.d
B.conf
C.conf
# فایل‌ها از two.d
A.conf
D.conf

log_dest مقاصد

پیام‌های لاگ را به یک مقصد خاص ارسال می‌کند. مقاصد ممکن عبارتند از: stdout stderr syslog topic file dlt android.

گزینه‌های stdout و stderr گزارش‌ها را در کنسول روی خروجی نام‌گذاری‌شده ثبت می‌کنند.

گزینه syslog از امکانات syslog فضای کاربری استفاده می‌کند که معمولاً در /var/log/messages یا موارد مشابه قرار می‌گیرد.

گزینه topic در موضوع کارگزار '$SYS/broker/log/<severity>' لاگ می‌اندازد، که در آن severity یکی از E، W، N، I، M به معنای خطا (error)، هشدار (warning)، اعلان (notice)، اطلاعات (information) و پیام (message) است. شدت نوع پیام توسط گزینه‌های log_type با مقادیر subscribe و unsubscribe استفاده می‌شود و پیام‌های لاگ را در $SYS/broker/log/M/subscribe و $SYS/broker/log/M/unsubscribe منتشر می‌کند. پیام‌های اشکال‌زدایی (debug) هرگز در موضوعات ثبت نمی‌شوند.

مقصد file به یک پارامتر اضافی نیاز دارد که فایلی است که گزارش‌ها در آن ثبت می‌شوند، به عنوان مثال "log_dest file /var/log/mosquitto.log". وقتی کارگزار سیگنال HUP دریافت کند، فایل بسته شده و دوباره باز می‌شود. تنها یک مقصد فایل می‌تواند پیکربندی شود.

مقصد dlt برای ابزار خودروسازی `Diagnostic Log and Trace` است. این نیاز دارد که Mosquitto با پشتیبانی از DLT کامپایل شده باشد.

مقصد android فقط برای اندروید است و به دیمن logd خروجی می‌دهد.

اگر می‌خواهید ثبت گزارش را غیرفعال کنید از "log_dest none" استفاده کنید. پیش‌فرض stderr است. این گزینه می‌تواند چندین بار مشخص شود.

توجه داشته باشید که اگر کارگزار به عنوان یک سرویس ویندوز اجرا شود، به طور پیش‌فرض روی "log_dest none" قرار می‌گیرد و نه ثبت در stdout و نه در stderr در دسترس نخواهد بود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

log_facility بخش محلی

در صورت استفاده از ثبت در syslog (نه در ویندوز)، پیام‌ها به طور پیش‌فرض در بخش "daemon" ثبت می‌شوند. از گزینه log_facility برای انتخاب اینکه به جای آن در کدام‌یک از local0 تا local7 لاگ انداخته شود، استفاده کنید. مقدار گزینه باید یک مقدار عدد صحیح باشد، مثلاً "log_facility 5" برای استفاده از local5.

log_timestamp [ true | false ]

مقدار بولی؛ اگر روی true تنظیم شود، یک مقدار برچسب زمان به هر ورودی لاگ اضافه می‌شود. پیش‌فرض true است.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

log_timestamp_format قالب

قالب برچسب زمان گزارش را تنظیم می‌کند. اگر تنظیم نشده رها شود، تعداد ثانیه‌های سپری‌شده از مبدأ یونیکس (Unix epoch) خواهد بود. این گزینه یک رشته متنی آزاد است که به عنوان مشخص‌کننده قالب به تابع strftime ارسال می‌شود. برای مثال، برای دریافت تاریخ‌زمان ISO 8601: 
log_timestamp_format %Y-%m-%dT%H:%M:%S

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

log_type انواع

انواع پیام‌ها را برای ثبت انتخاب می‌کند. انواع ممکن عبارتند از: debug، error، warning، notice، information، subscribe، unsubscribe، websockets، none، all.

پیش‌فرض error، warning، notice و information است. این گزینه می‌تواند چندین بار مشخص شود. توجه داشته باشید که نوع debug (که برای رمزگشایی بسته‌های شبکه ورودی/خروجی استفاده می‌شود) هرگز در موضوعات ثبت نمی‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

max_inflight_bytes تعداد

پیام‌های خروجی QoS 1 و 2 مجاز خواهند بود تا زمانی که به این محدودیت بایت برسند در جریان ارسال (in flight) باشند. این امکان کنترل نرخ پیام خروجی را بر اساس اندازه پیام به جای تعداد پیام فراهم می‌کند. اگر محدودیت روی 100 تنظیم شود، پیام‌های بیش از 100 بایت همچنان مجاز هستند، اما تنها یک پیام می‌تواند در یک زمان در جریان باشد. پیش‌فرض 0 است (بدون محدودیت).

گزینه max_inflight_messages را نیز ببینید.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

max_inflight_messages تعداد

حداکثر تعداد پیام‌های خروجی QoS 1 یا 2 که می‌توانند به طور همزمان در حال انتقال باشند. این شامل پیام‌هایی است که در حال حاضر دست‌تکانی (handshake) را طی می‌کنند و پیام‌هایی که در حال تلاش مجدد هستند. پیش‌فرض 20 است. برای نامحدود بودن روی 0 تنظیم کنید. اگر روی 1 تنظیم شود، تحویل مرتب پیام‌ها را تضمین می‌کند.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

max_keepalive مقدار

برای کلاینت‌های MQTT v5، این امکان وجود دارد که سرور یک مقدار "server keepalive" ارسال کند که مقدار نگه‌داری اتصال تنظیم‌شده توسط کلاینت را بازنویسی کند. این در نظر گرفته شده است تا به عنوان مکانیزمی استفاده شود که بگوید سرور کلاینت را زودتر از آنچه پیش‌بینی کرده بود قطع خواهد کرد و کلاینت باید از مقدار جدید keepalive استفاده کند. گزینه max_keepalive به شما امکان می‌دهد مشخص کنید کلاینت‌ها فقط می‌توانند با مقدار keepalive کمتر یا مساوی این مقدار متصل شوند، در غیر این صورت یک server keepalive برای آنها ارسال می‌شود که به آنها می‌گوید از max_keepalive استفاده کنند. این فقط برای کلاینت‌های MQTT v5 اعمال می‌شود. حداکثر مقدار 65535 است. برای مجاز کردن keepalive بی‌نهایت روی 0 تنظیم کنید. پیش‌فرض 0 است.

تنظیم روی 0 به کلاینت‌ها اجازه می‌دهد keepalive = 0 را تنظیم کنند، به این معنی که هیچ بررسی keepalive انجام نمی‌شود و در صورت عدم دریافت پیام، کلاینت هرگز توسط کارگزار قطع نخواهد شد. باید کاملاً مطمئن باشید که این همان رفتاری است که می‌خواهید.

برای کلاینت‌های MQTT v3.1.1 و v3.1، هیچ مکانیزمی برای گفتن به کلاینت در مورد اینکه از چه مقدار keepalive باید استفاده کند وجود ندارد. اگر یک کلاینت MQTT v3.1.1 یا v3.1 زمان نگه‌داری اتصال بیشتری از max_keepalive مشخص کند، یک پیام CONNACK با کد دلیل "identifier rejected" برای آن ارسال شده و اتصال قطع می‌شود.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

max_packet_size مقدار

برای کلاینت‌های MQTT v5، این امکان وجود دارد که سرور یک مقدار "maximum packet size" ارسال کند که به کلاینت دستور می‌دهد بسته‌های MQTT با اندازه بزرگتر از value بایت را نمی‌پذیرد. این امر برای کل بسته MQTT اعمال می‌شود، نه فقط بدنه داده (payload). تنظیم این گزینه روی یک مقدار مثبت، حداکثر اندازه بسته را روی آن تعداد بایت تنظیم می‌کند. اگر کلاینتی بسته‌ای ارسال کند که بزرگتر از این مقدار باشد، ارتباط آن قطع خواهد شد. این امر برای همه کلاینت‌ها بدون در نظر گرفتن نسخه پروتکلی که استفاده می‌کنند اعمال می‌شود، اما کلاینت‌های v3.1.1 و نسخه‌های قبل‌تر مسلماً اطلاعات حداکثر اندازه بسته را دریافت نکرده‌اند.

از نسخه 2.1 به بعد پیش‌فرض 2000000 بایت است. نسخه‌های قبل‌تر به طور پیش‌فرض بدون محدودیت بودند.

این گزینه برای همه کلاینت‌ها اعمال می‌شود، نه فقط کلاینت‌هایی که از MQTT v5 استفاده می‌کنند، اما اطلاع‌رسانی محدودیت به کلاینت‌هایی که از MQTT v3.1.1 یا MQTT v3.1 استفاده می‌کنند امکان‌پذیر نیست.

تنظیم زیر 20 بایت ممنوع است زیرا حتی با محموله‌های کوچک نیز احتمالاً در عملکرد عادی کلاینت اختلال ایجاد می‌کند.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

max_queued_bytes تعداد

تعداد بایت‌های پیام‌های خروجی QoS 1 و 2 فراتر از پیام‌هایی که در حال حاضر در جریان هستند، توسط کارگزار (به ازای هر کلاینت) صف‌بندی می‌شوند. هنگامی که این محدودیت پر شود، پیام‌های بعدی بدون اعلام حذف خواهند شد (silently dropped). این گزینه مهمی است اگر پیام‌ها را با نرخ بالایی ارسال می‌کنید و/یا کلاینت‌هایی دارید که دیر پاسخ می‌دهند یا ممکن است برای مدت طولانی آفلاین باشند. پیش‌فرض 0 است (بدون محدودیت).

گزینه max_queued_messages را نیز ببینید. اگر هر دو گزینه max_queued_messages و max_queued_bytes مشخص شوند، بسته‌ها تا زمانی که به اولین محدودیت برسند صف‌بندی می‌شوند.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

max_queued_messages تعداد

حداکثر تعداد پیام‌های QoS 1 یا 2 برای نگه‌داری در صف (به ازای هر کلاینت) علاوه بر پیام‌هایی که در حال حاضر در جریان هستند. پیش‌فرض 1000 است. برای عدم محدودیت روی 0 تنظیم کنید (توصیه نمی‌شود). گزینه‌های queue_qos0_messages و max_queued_bytes را نیز ببینید.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

memory_limit محدودیت

این گزینه حداکثر تعداد بایت‌های حافظه هیپ (heap) را که کارگزار تخصیص می‌دهد تنظیم می‌کند و بنابراین یک محدودیت سخت‌گیرانه برای استفاده از حافظه توسط کارگزار تعیین می‌نماید. درخواست‌های حافظه که بیش از این مقدار باشند رد خواهند شد. تأثیر بسته به آنچه رد شده است متفاوت خواهد بود. اگر یک پیام ورودی در حال پردازش باشد، پیام حذف شده و کلاینت منتشرکننده قطع خواهد شد. اگر یک پیام خروجی در حال ارسال باشد، پیام منفرد حذف شده و کلاینت دریافت‌کننده قطع خواهد شد. پیش‌فرض بدون محدودیت است.

این گزینه تنها در صورتی در دسترس است که پشتیبانی از ردیابی حافظه به صورت کامپایل‌شده وجود داشته باشد.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود. تنظیم روی مقدار کمتر و بارگذاری مجدد منجر به آزادسازی حافظه نخواهد شد.

message_size_limit محدودیت

این گزینه حداکثر اندازه بدنه داده پیام انتشاری (publish payload) را که کارگزار مجاز می‌داند تنظیم می‌کند. پیام‌های دریافتی که بیش از این اندازه باشند توسط کارگزار پذیرفته نخواهند شد. این بدان معنی است که پیام برای کلاینت‌های مشترک ارسال نخواهد شد، اما جریان QoS برای پیام‌های QoS 1 یا QoS 2 تکمیل خواهد شد. کلاینت‌های MQTT v5 که از QoS 1 یا QoS 2 استفاده می‌کنند، یک PUBACK یا PUBREC با کد دلیل "implementation specific error" دریافت خواهند کرد.

مقدار پیش‌فرض 0 است، به این معنی که تمام پیام‌های معتبر MQTT پذیرفته می‌شوند. پروتکل MQTT حداکثر اندازه محموله 268435455 بایت را تحمیل می‌کند.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

password_file مسیر فایل

نکته: پیشنهاد می‌شود به جای این گزینه از افزونه mosquitto_password_file استفاده کنید. استفاده از افزونه‌ها برای احراز هویت و اعطای مجوز امکان کنترل بیشتری بر روی اعمال آن‌ها به شنوندگان مختلف، بدون نیاز به گزینه منسوخ‌شده per_listener_settings فراهم می‌کند.

مسیر فایل گذرواژه را تعیین می‌کند. در صورت تعریف، محتویات فایل برای کنترل دسترسی کلاینت به کارگزار استفاده می‌شود. این فایل را می‌توان با استفاده از ابزار mosquitto_passwd(1) ایجاد کرد. اگر mosquitto بدون پشتیبانی TLS کامپایل شده باشد (توصیه می‌شود پشتیبانی TLS گنجانده شود)، فایل گذرواژه باید یک فایل متنی باشد که هر خط آن در قالب "username:password" است، که در آن دونقطه و گذرواژه اختیاری اما توصیه شده است. اگر allow_anonymous روی false تنظیم شود، فقط کاربرانی که در این فایل تعریف شده‌اند قادر به اتصال خواهند بود. تنظیم allow_anonymous روی true در صورت تعریف password_file معتبر است و می‌تواند همراه با acl_file برای داشتن مثلاً حساب‌های مهمان/ناشناس فقط‌خواندنی و کاربران تعریف‌شده‌ای که می‌توانند پیام منتشر کنند، استفاده شود.

اگر per_listener_settings برابر true باشد، این گزینه تنها به شنونده فعلی که در حال پیکربندی است اعمال خواهد شد. اگر per_listener_settings برابر false باشد، این گزینه برای همه شنوندگان اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود. داده‌های نام کاربری و گذرواژه که در حال حاضر بارگذاری شده‌اند آزاد شده و دوباره بارگذاری خواهند شد. کلاینت‌هایی که قبلاً متصل شده‌اند تحت تأثیر قرار نخواهند گرفت.

همچنین ببینید: mosquitto_passwd(1) و https://mosquitto.org/documentation/dynamic-security/

per_listener_settings [ true | false ]

اگر true باشد، تنظیمات احراز هویت و کنترل دسترسی به ازای هر شنونده کنترل می‌شود. گزینه‌های زیر تحت تأثیر قرار می‌گیرند:

password_file، acl_file، psk_file، allow_anonymous، allow_zero_length_clientid، auto_id_prefix. plugin، plugin_opt_*، توجه داشته باشید که اگر روی true تنظیم شود، یک کلاینت پایدار (یعنی با تنظیم clean session روی false) که قطع شده است، از تنظیمات ACL تعریف‌شده برای شنونده‌ای استفاده می‌کند که اخیراً به آن متصل بوده است.

رفتار پیش‌فرض برای این گزینه false است که رفتار تنظیمات نسخه‌های قبلی mosquitto را حفظ می‌کند.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

persistence [ true | false ]

اگر true باشد، پایداری (persistence) توکار فعال می‌شود. توصیه می‌شود به جای آن از پایداری مبتنی بر افزونه استفاده شود.

در صورت فعال بودن، داده‌های اتصال، اشتراک و پیام در mosquitto.db در مکانی که توسط persistence_location تعیین شده است، روی دیسک نوشته می‌شود. وقتی mosquitto راه‌اندازی مجدد شود، اطلاعات ذخیره‌شده در mosquitto.db را دوباره بارگذاری می‌کند. داده‌ها هنگام بسته شدن mosquitto و همچنین در فواصل زمانی مشخص‌شده توسط autosave_interval روی دیسک نوشته می‌شوند. نوشتن پایگاه داده پایداری را نیز می‌توان با ارسال سیگنال SIGUSR1 به mosquitto اجبار کرد. اگر false باشد، داده‌ها فقط در حافظه ذخیره می‌شوند. پیش‌فرض false است.

فایل پایداری ممکن است قالب خود را در یک نسخه جدید تغییر دهد. کارگزار در حال حاضر می‌تواند تمام قالب‌های قدیمی را بخواند، اما فقط در آخرین قالب ذخیره می‌کند. ارتقا باید همیشه امن باشد، اما کاربران محتاط ممکن است مایل باشند قبل از نصب نسخه جدید یک کپی از فایل پایداری تهیه کنند تا در صورت لزوم بتوانند به نسخه قبلی بازگردند.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

persistence_file نام فایل

نام فایلی که برای پایگاه داده ماندگار توکار استفاده می‌شود. پیش‌فرض mosquitto.db است.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

persistence_location مسیر

مسیری که افزونه‌ها باید هر گونه داده پایداری را در آن ذخیره کنند، و مسیری که پایداری توکار داده‌های خود را در آن ذخیره خواهد کرد. اگر داده نشود، از دایرکتوری فعلی استفاده می‌شود.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

persistent_client_expiration مدت زمان

این گزینه به نشست کلاینت‌های ماندگار (آن‌هایی که clean session روی false تنظیم شده است) که در حال حاضر متصل نیستند اجازه می‌دهد در صورتی که در یک بازه زمانی معین مجدداً متصل نشوند، حذف شوند. این یک گزینه غیر استاندارد در MQTT v3.1 است. نسخه‌های MQTT v3.1.1 و v5.0 به کارگزاران اجازه می‌دهند نشست‌های کلاینت را حذف کنند.

کلاینت‌هایی با طراحی ضعیف ممکن است clean session را روی false قرار دهند در حالی که از شناسه کلاینت تولیدشده به صورت تصادفی استفاده می‌کنند. این منجر به کلاینت‌های ماندگاری می‌شود که یک بار متصل می‌شوند و هرگز دوباره متصل نمی‌شوند. این گزینه اجازه می‌دهد این کلاینت‌ها حذف شوند.

دوره انقضا باید یک عدد صحیح باشد و به دنبال آن یکی از حروف s h d w m y به ترتیب برای ثانیه، ساعت، روز، هفته، ماه و سال بیاید. برای مثال:

•persistent_client_expiration 2m
•persistent_client_expiration 14d
•persistent_client_expiration 1y

اگرچه امکان تعیین زمان انقضا بر حسب ثانیه وجود دارد، این به این معنی نیست که باید از یک بازه انقضای کوتاه استفاده کنید. اگر سیستمی دارید که فکر می‌کنید کلاینت‌ها باید به طور خودکار در مدت زمان کوتاهی منقضی شوند، در صورت امکان باید مشکل کلاینت‌ها را برطرف کنید.

از آنجا که این یک گزینه غیر استاندارد است، مقدار پیش‌فرض در صورت عدم تنظیم این است که هرگز کلاینت‌های ماندگار منقضی نشوند.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

pid_file مسیر فایل

یک فایل pid در فایل مشخص‌شده می‌نویسد. اگر داده نشود (پیش‌فرض)، هیچ فایل pid نوشته نخواهد شد. اگر فایل pid قابل نوشتن نباشد، mosquitto خارج خواهد شد.

اگر mosquitto به طور خودکار توسط یک اسکریپت init راه‌اندازی می‌شود معمولاً نوشتن یک فایل pid الزامی خواهد بود. سپس این باید به عنوان مثال /var/run/mosquitto/mosquitto.pid پیکربندی شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

plugin_opt_* مقدار

گزینه‌هایی که باید به جدیدترین plugin تعریف‌شده در فایل پیکربندی منتقل شوند. برای جزئیات گزینه‌های موجود، دستورالعمل‌های خاص افزونه را ببینید.

برای افزونه/global_plugin فعلی که در حال پیکربندی است اعمال می‌شود.

این همچنین به عنوان گزینه auth_opt_* نیز در دسترس است، اما این استفاده منسوخ شده و در نسخه آینده حذف خواهد شد.

plugin مسیر فایل

یک ماژول خارجی را برای استفاده در احراز هویت، کنترل دسترسی و سایر ویژگی‌ها مشخص می‌کند. این اجازه می‌دهد توابع نام کاربری/گذرواژه و کنترل دسترسی سفارشی ایجاد شده و رفتارهای دیگر اصلاح شوند.

می‌توان چندین بار برای بارگذاری چندین افزونه مشخص کرد. افزونه‌ها به ترتیبی که مشخص شده‌اند پردازش می‌شوند.

اگر password_file یا acl_file در فایل پیکربندی در کنار plugin استفاده شوند، بررسی‌های افزونه قبل از بررسی‌های توکار اجرا می‌شوند.

در حال حاضر با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

اگر per_listener_settings روی true تنظیم شده باشد، این افزونه فقط برای شنونده فعلی بارگذاری خواهد شد.

همچنین ببینید: https://mosquitto.org/documentation/dynamic-security/ و گزینه global_plugin.

این همچنین به عنوان گزینه auth_plugin نیز در دسترس است، اما این استفاده منسوخ شده و در نسخه آینده حذف خواهد شد.

psk_file مسیر فایل

مسیر یک فایل کلید از پیش اشتراک‌گذاری‌شده (PSK) را تنظیم می‌کند. این گزینه نیازمند این است که یک شنونده پشتیبانی PSK را فعال کرده باشد. در صورت تعریف، محتویات فایل برای کنترل دسترسی کلاینت به کارگزار استفاده می‌شود. هر خط باید در قالب "identity:key" باشد، که در آن کلید یک رشته هگزادسیمال بدون "0x" در ابتدا است. کلاینتی که به شنونده‌ای با پشتیبانی PSK فعال متصل می‌شود، باید یک هویت و PSK منطبق ارائه دهد تا اتصال رمزگذاری‌شده ادامه یابد.

اگر per_listener_settings برابر true باشد، این گزینه تنها به شنونده فعلی که در حال پیکربندی است اعمال می‌شود. اگر per_listener_settings برابر false باشد، این گزینه برای همه شنوندگان اعمال خواهد شد.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود. داده‌های هویت و کلید که در حال حاضر بارگذاری شده‌اند آزاد شده و دوباره بارگذاری خواهند شد. کلاینت‌هایی که قبلاً متصل شده‌اند تحت تأثیر قرار نخواهند گرفت.

queue_qos0_messages [ true | false ]

روی true تنظیم کنید تا هنگام قطع اتصال کلاینت ماندگار، پیام‌های با سطح QoS 0 در صف قرار گیرند. هنگامی که موضوعات پل با سطح QoS 1 یا 2 پیکربندی می‌شوند، پیام‌های ورودی QoS 0 برای این موضوعات نیز در صف قرار می‌گیرند. این پیام‌ها در محدودیت تحمیل‌شده توسط max_queued_messages گنجانده می‌شوند. پیش‌فرض false است.

توجه داشته باشید که مشخصات MQTT v3.1.1 بیان می‌کند که فقط پیام‌های QoS 1 و 2 باید در این وضعیت ذخیره شوند، بنابراین این یک گزینه غیر استاندارد است.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

retain_available [ true | false ]

اگر روی false تنظیم شود، پیام‌های نگه‌داشته‌شده (retained) پشتیبانی نمی‌شوند. اگر این گزینه روی false تنظیم شده باشد، کلاینت‌هایی که پیامی با بیت retain ارسال می‌کنند قطع خواهند شد. پیش‌فرض true است.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

retain_expiry_interval دقیقه

رفتار پیش‌فرض mosquitto حذف پیام‌های نگه‌داشته‌شده‌ای است که در دسترسی بعدی به ویژگی message-expiry-interval خود رسیده‌اند - چه با جایگزین شدن با یک پیام جدید، یا در اشتراک بعدی که با پیام مطابقت دارد. اگر الگویی برای انتشار پیام‌های نگه‌داشته‌شده متعدد با message-expiry-interval دارید اما در آن‌ها مشترک نمی‌شوید، پیام‌های نگه‌داشته‌شده منقضی‌شده در حافظه باقی می‌مانند. این گزینه کارگزار را پیکربندی می‌کند تا به طور دوره‌ای درخت پیام‌های نگه‌داشته‌شده را برای پیام‌های منقضی‌شده بررسی کند.

پیش‌فرض خاموش (off) است. تنظیم روی مقداری بزرگتر از صفر به این معنی است که کارگزار در بازه زمانی آن تعداد دقیقه بررسی را انجام خواهد داد.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

set_tcp_nodelay [ true | false ]

اگر روی true تنظیم شود، گزینه TCP_NODELAY روی سوکت‌های کلاینت تنظیم می‌شود تا الگوریتم Nagle غیرفعال شود. این کار باعث کاهش تأخیر برخی پیام‌ها با احتمال افزایش تعداد بسته‌های TCP ارسالی می‌شود. پیش‌فرض false است.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

sys_interval ثانیه

تعداد ثانیه‌های صحیح بین به‌روزرسانی‌های سلسله‌مراتب اشتراک $SYS که اطلاعات وضعیت کارگزار را ارائه می‌دهد. اگر تنظیم نشود، پیش‌فرض 10 ثانیه است.

برای غیرفعال کردن کامل انتشار سلسله‌مراتب $SYS روی 0 تنظیم کنید.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

upgrade_outgoing_qos [ true | false ]

مشخصات MQTT ایجاب می‌کند که QoS پیامی که به یک مشترک تحویل داده می‌شود هرگز برای تطابق با QoS اشتراک ارتقا نیابد. فعال کردن این گزینه این رفتار را تغییر می‌دهد. اگر upgrade_outgoing_qos روی true تنظیم شود، پیام‌های ارسالی به یک مشترک همیشه با QoS اشتراک آن مطابقت خواهد داشت. این یک گزینه غیر استاندارد است که در مشخصات پیش‌بینی نشده است. پیش‌فرض false است.

این گزینه به صورت سراسری اعمال می‌شود.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

user نام کاربری

هنگام اجرا به عنوان کاربر ریشه (root)، در زمان راه‌اندازی به این کاربر و گروه اصلی آن تغییر می‌یابد. اگر روی "mosquitto" تنظیم شود یا تنظیم نشده رها شود، و اگر کاربر "mosquitto" وجود نداشته باشد، mosquitto به جای آن به کاربر "nobody" تغییر می‌یابد. اگر این روی مقدار دیگری تنظیم شود و mosquitto نتواند به این کاربر و گروه تغییر کند، با خطا خارج می‌شود. کاربر مشخص‌شده باید دسترسی خواندن/نوشتن به پایگاه داده پایداری داشته باشد اگر قرار است نوشته شود. اگر به عنوان یک کاربر غیر ریشه اجرا شود، این تنظیم هیچ تأثیری ندارد. پیش‌فرض mosquitto است.

این تنظیم روی ویندوز هیچ تأثیری ندارد و بنابراین باید mosquitto را به عنوان کاربری که می‌خواهید اجرا شود، اجرا کنید.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

درگاه‌های شبکه‌ای که mosquitto روی آن‌ها گوش می‌دهد را می‌توان با استفاده از شنوندگان (listeners) کنترل کرد. گزینه‌های پیش‌فرض شنونده را می‌توان بازنویسی کرد و شنوندگان بیشتری ایجاد نمود.

accept_protocol_versions نسخه‌ها

نسخه‌های پروتکل پذیرفته‌شده. این مشخص می‌کند چه نسخه‌هایی از پروتکل MQTT روی این شنونده پذیرفته می‌شوند. می‌تواند هر ترکیبی از 3، 4، 5 در یک لیست جدا شده با ویرگول باشد، مثلاً: 
# فقط نسخه v5.0 مجاز است:
listener 1883
accept_protocol_versions 5
# نسخه‌های v3.1 و v3.1.1 مجاز هستند:
listener 1884
accept_protocol_versions 3, 4

پیش‌فرض اجازه دادن به همه نسخه‌ها است.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

bind_address آدرس

این گزینه منسوخ شده است و در نسخه آینده حذف خواهد شد. به جای آن از listener استفاده کنید.

تنها به اتصالات شبکه ورودی روی آدرس IP/نام میزبان مشخص‌شده گوش می‌دهد. این برای محدود کردن دسترسی به برخی رابط‌های شبکه مفید است. برای محدود کردن دسترسی به mosquitto فقط به میزبان محلی، از "bind_address localhost" استفاده کنید. این فقط برای شنونده پیش‌فرض اعمال می‌شود. از گزینه listener برای کنترل سایر شنوندگان استفاده کنید.

توصیه می‌شود به جای اتکا به گزینه‌های پیش‌فرض ضمنی شنونده مانند این، از یک listener صریح استفاده کنید.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

bind_interface دستگاه

تنها روی رابط شبکه مشخص‌شده به اتصالات شبکه ورودی گوش می‌دهد. این شبیه به گزینه bind_address است اما زمانی مفید است که یک رابط دارای چندین آدرس باشد یا آدرس ممکن است تغییر کند.

اگر همزمان با bind_address برای شنونده پیش‌فرض یا بخش bind address/host از listener استفاده شود، آنگاه bind_interface اولویت خواهد داشت.

این گزینه در ویندوز و AIX در دسترس نیست.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

enable_proxy_protocol [ 2 | 1 ]

پشتیبانی از پروتکل PROXY را برای این شنونده فعال می‌کند. نسخه‌های 1 و 2 پشتیبانی می‌شوند؛ اگر حق انتخاب دارید، نسخه 2 توصیه می‌شود زیرا به شما امکان دسترسی به اطلاعات TLS را می‌دهد و از سوکت‌های یونیکس پشتیبانی می‌کند.

این گزینه مستلزم استفاده از یک متعادل‌کننده بار/پروکسی مانند HAProxy در جلوی Mosquitto است، به‌طوری‌که پروکسی برای استفاده از پروتکل PROXY پیکربندی شده باشد.

پروتکل PROXY برای ارسال اطلاعات مربوط به اتصالات سوکت کلاینت از پروکسی به کارگزار استفاده می‌شود. بدون این، اطلاعات اتصال و لاگ‌ها در کارگزار شامل آدرس IP و درگاه خود پروکسی خواهد بود، نه کلاینت.

فعال کردن این گزینه فقط باید زمانی انجام شود که یک پروکسی قابل اعتماد در جلوی Mosquitto قرار داده شده باشد و هیچ دسترسی خارجی دیگری به Mosquitto امکان‌پذیر نباشد. دادن دسترسی خارجی به شنونده‌ای با این گزینه فعال، یک ریسک امنیتی است، به ویژه اگر از گواهی‌های کلاینت روی پروکسی استفاده می‌کنید.

هنگام استفاده از PROXY نسخه 2، این گزینه می‌تواند با خاتمه TLS (TLS termination) روی پروکسی استفاده شود. در این حالت، اطلاعات TLS نیز به کارگزار منتقل خواهد شد. از proxy_protocol_v2_require_tls برای رد کلاینت‌هایی که از TLS استفاده نمی‌کنند استفاده کنید - این به شدت توصیه می‌شود. فعال کردن require_certificate روی شنونده باعث می‌شود کارگزار اطلاعات TLS ارائه‌شده را بررسی کند تا اطمینان حاصل شود که کلاینت یک گواهی معتبر ارائه داده است. فعال کردن use_identity_as_username نیز باعث می‌شود مقدار commonName از گواهی به جای نام کاربری ارائه‌شده در بسته CONNECT به عنوان نام کاربری کلاینت استفاده شود. در هر دو حالت، شنونده نباید دارای TLS پیکربندی‌شده باشد.

امکان استفاده از گزینه‌های use_subject_as_username، certfile، یا keyfile در ترکیب با enable_proxy_protocol وجود ندارد.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

http_dir پوشه

هنگامی که یک شنونده از پروتکل http_api استفاده می‌کند، امکان ارائه داده‌های http نیز وجود دارد. http_dir را روی دایرکتوری‌ای که حاوی فایل‌هایی است که می‌خواهید ارائه دهید تنظیم کنید. اگر این گزینه مشخص نشده باشد، هیچ اتصال معمولی http امکان‌پذیر نخواهد بود.

این گزینه همچنین برای شنوندگان وب‌سوکت در صورتی که Mosquitto با پشتیبانی از وب‌سوکت ارائه‌شده توسط libwebsockets کامپایل شده باشد در دسترس است. این پیش‌فرض نیست و در نسخه 3.0 حذف خواهد شد.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

listener درگاه [آدرس bind/میزبان/مسیر سوکت یونیکس]

روی درگاه مشخص‌شده به اتصال شبکه ورودی گوش می‌دهد. یک آرگومان اختیاری دوم به شنونده اجازه می‌دهد تا به یک آدرس IP/نام میزبان خاص متصل شود. اگر از این متغیر استفاده شود و هیچ یک از گزینه‌های سراسری bind_address یا port استفاده نشوند، شنونده پیش‌فرض راه‌اندازی نخواهد شد.

گزینه bind address/host به این شنونده اجازه می‌دهد تا با ارسال یک آدرس IP یا نام میزبان به یک آدرس IP خاص متصل شود. برای شنوندگان وب‌سوکت، تنها امکان ارسال یک آدرس IP در اینجا وجود دارد.

در سیستم‌هایی که از Unix Domain Sockets پشتیبانی می‌کنند، این گزینه همچنین می‌تواند برای ایجاد یک سوکت یونیکس به جای باز کردن سوکت TCP استفاده شود. در این حالت، درگاه باید روی 0 تنظیم شود و مسیر سوکت یونیکس باید داده شود.

این گزینه می‌تواند چندین بار مشخص شود. گزینه mount_point را نیز ببینید.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

listener_allow_anonymous [ true | false ]

مقدار بولی که تعیین می‌کند آیا کلاینت‌هایی که بدون ارائه نام کاربری متصل می‌شوند مجاز به اتصال به این شنونده خاص هستند یا خیر. در صورت تنظیم، این مقدار تنظیم‌شده توسط allow_anonymous را بازنویسی می‌کند. اگر روی false تنظیم شود، باید روش اتصال دیگری برای کنترل دسترسی کلاینت احراز هویت‌شده ایجاد شود.

اگر به صراحت تنظیم نشود، از مقدار allow_anonymous استفاده خواهد شد.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

auto_id_prefix پیشوند

این گزینه به شما امکان می‌دهد رشته‌ای را تنظیم کنید که به ابتدای شناسه‌های کلاینت ایجادشده به صورت خودکار (یعنی زمانی که یک کلاینت بدون ارائه شناسه کلاینت متصل می‌شود) اضافه شود تا دیده‌شدن در لاگ‌ها آسان‌تر شود. پیش‌فرض auto- است.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

max_connections تعداد

تعداد کل کلاینت‌های متصل برای شنونده فعلی را محدود می‌کند. برای داشتن اتصالات "نامحدود" روی -1 تنظیم کنید. توجه داشته باشید که ممکن است محدودیت‌های دیگری خارج از کنترل mosquitto اعمال شود. به عنوان مثال limits.conf() را ببینید.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

max_qos مقدار

مقدار QoS مجاز برای کلاینت‌های متصل به این شنونده را محدود می‌کند. پیش‌فرض 2 است، به این معنی که از هر QoS می‌توان استفاده کرد. برای محدود کردن به آن مقادیر QoS روی 0 یا 1 تنظیم کنید. این از ویژگی MQTT v5 برای اطلاع‌رسانی محدودیت به کلاینت‌ها استفاده می‌کند. کلاینت‌های MQTT v3.1.1 از این محدودیت آگاه نخواهند بود. کلاینت‌هایی که با یک QoS بیش از حد بالا در این شنونده پیام منتشر می‌کنند قطع خواهند شد.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

max_topic_alias_broker عدد

هنگام انتشار به کلاینت‌های MQTT v5، نرم‌افزار Mosquitto می‌تواند نام‌های مستعار موضوع (topic aliases) را بر اساس اولویت ورود ایجاد کند، یعنی موضوعاتی که ابتدا به یک کلاینت منتشر می‌شوند دارای نام مستعار می‌شوند. این گزینه تعداد نام‌های مستعار را به ازای هر کلاینت کنترل می‌کند. این گزینه به ازای هر شنونده اعمال می‌شود.

توجه داشته باشید که این رفتار تضمین نمی‌شود که یکسان باقی بماند. ممکن است نسخه‌های آینده مکانیزم‌هایی را برای کنترل اینکه کدام موضوعات نام مستعار دریافت می‌کنند معرفی کنند.

این گزینه حداکثر تعداد نام‌های مستعار موضوع را که Mosquitto برای یک کلاینت MQTT v5 ایجاد می‌کند تنظیم می‌کند، حتی اگر کلاینت تعداد بیشتری را مجاز بداند.

برای مثال، اگر کلاینت topic-alias-maximum را روی 100 تنظیم کند و این گزینه روی 10 تنظیم شود، کارگزار حداکثر 10 نام مستعار موضوع ایجاد خواهد کرد. به همین ترتیب، اگر کلاینت topic-alias-maximum را روی 20 تنظیم کند و این گزینه روی 100 تنظیم شود، کارگزار حداکثر 20 نام مستعار موضوع ایجاد خواهد کرد.

پیش‌فرض 10 است. حداکثر 65535. برای غیرفعال کردن کامل نام‌های مستعار موضوع از کارگزار به کلاینت روی 0 تنظیم کنید.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

max_topic_alias عدد

این گزینه حداکثر تعداد نام‌های مستعار موضوع را که یک کلاینت MQTT v5 مجاز به ایجاد آن است تنظیم می‌کند. این گزینه به ازای هر شنونده اعمال می‌شود. پیش‌فرض 10 است. برای عدم پذیرش نام‌های مستعار موضوع از سوی کلاینت‌ها روی 0 تنظیم کنید. حداکثر مقدار ممکن 65535 است.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

mount_point پیشوند موضوع

این گزینه با گزینه listener برای جداسازی گروه‌هایی از کلاینت‌ها استفاده می‌شود. هنگامی که یک کلاینت به شنونده‌ای متصل می‌شود که از این گزینه استفاده می‌کند، آرگومان رشته‌ای به ابتدای تمام موضوعات برای این کلاینت متصل می‌شود. این پیشوند زمانی که هر پیامی به کلاینت ارسال می‌شود حذف می‌گردد. این بدان معنی است که کلاینت متصل به شنونده‌ای با نقطه اتصال (mount point) example تنها می‌تواند پیام‌هایی را ببیند که در سلسله‌مراتب موضوع example و زیرمجموعه‌های آن منتشر شده‌اند.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

port شماره درگاه

این گزینه منسوخ شده است و در نسخه آینده حذف خواهد شد. به جای آن از listener استفاده کنید.

درگاه شبکه را برای شنونده پیش‌فرض جهت گوش دادن تنظیم می‌کند. پیش‌فرض 1883 است.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

توصیه می‌شود به جای اتکا به گزینه‌های پیش‌فرض ضمنی شنونده مانند این، از یک listener صریح استفاده کنید.

protocol مقدار

پروتکل پذیرش را برای شنونده فعلی تنظیم می‌کند. می‌تواند mqtt (پیش‌فرض)، websockets، یا http_api باشد.

mqtt: شنونده استاندارد MQTT.

websockets: پروتکل MQTT تونل‌شده روی وب‌سوکت. اگر از پشتیبانی قدیمی وب‌سوکت با استفاده از libwebsockets استفاده شود، تنها مجموعه ویژگی‌های کاهش‌یافته TLS در دسترس خواهد بود، یعنی cafile، certfile، keyfile، ciphers، و ciphers_tls1.3.

http_api: این شنونده را به عنوان یک وب‌سرور بسیار ساده راه‌اندازی می‌کند (گزینه http_dir را ببینید) که می‌تواند به برخی از درخواست‌های HTTP API نیز پاسخ دهد. پروتکل TLS برای این شنونده پشتیبانی می‌شود، با این حال فقط گزینه‌های certfile و keyfile مجاز هستند. احراز هویت در حال حاضر امکان‌پذیر نیست - برای استفاده از این شنونده اکیداً توصیه می‌شود که شنونده را به رابط loopback متصل کرده و سپس یک پروکسی معکوس با رمزگذاری و احراز هویت مناسب پیکربندی کنید.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

proxy_protocol_v2_require_tls [ true | false ]

هنگامی که یک شنونده از پروتکل PROXY استفاده می‌کند، می‌توان از این گزینه برای الزام کلاینت به استفاده از TLS استفاده کرد. اگر روی true تنظیم شود، هدر پروتکل PROXY باید حاوی نشانگر TLS باشد. اگر نباشد، اتصال بسته خواهد شد. پیش‌فرض false است.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

socket_domain [ ipv4 | ipv6 ]

به‌طور پیش‌فرض، یک شنونده تلاش می‌کند روی تمام نسخه‌های پروتکل IP پشتیبانی‌شده گوش دهد. اگر رابط IPv4 یا IPv6 ندارید، ممکن است بخواهید پشتیبانی از هر یک از آن نسخه‌های پروتکل را غیرفعال کنید. به‌ویژه، توجه داشته باشید که به دلیل محدودیت‌های کتابخانه وب‌سوکت، اگر پشتیبانی IPv6 کامپایل شده باشد تنها تلاش می‌کند سوکت‌های IPv6 را باز کند، و بنابراین اگر IPv6 در دسترس نباشد شکست خواهد خورد.

برای اجبار شنونده به استفاده انحصاری از IPv4 روی ipv4 تنظیم کنید، یا برای اجبار به استفاده از IPv6 روی ipv6 تنظیم نمایید. اگر می‌خواهید از هر دو نسخه IPv4 و IPv6 پشتیبانی شود، از گزینه socket_domain استفاده نکنید.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

use_username_as_clientid [ true | false ]

گزینه use_username_as_clientid را روی true قرار دهید تا شناسه‌ای که کلاینت با آن متصل شده با نام کاربری آن جایگزین شود. این اجازه می‌دهد تا احراز هویت به شناسه کلاینت گره بخورد، به این معنی که می‌توان از قطع اتصال یک کلاینت توسط کلاینت دیگر با استفاده از همان شناسه کلاینت جلوگیری کرد. پیش‌فرض false است.

اگر یک کلاینت بدون نام کاربری متصل شود، هنگامی که این گزینه روی true تنظیم شده باشد به عنوان غیرمجاز قطع خواهد شد. در ترکیب با clientid_prefixes استفاده نکنید.

این به صورت سراسری اعمال نمی‌شود، بلکه به ازای هر شنونده اعمال می‌شود.

همچنین ببینید: use_identity_as_username.

با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود.

packet_buffer_size اندازه, websockets_headers_size اندازه

اندازه بافر استفاده‌شده هنگام خواندن از شبکه را قبل از مشخص شدن اندازه بسته MQTT تغییر می‌دهد. پیش‌فرض 4096 است. بسته‌های دریافتی که کوچکتر از این مقدار هستند در اصل فقط به یک فراخوانی read() نیاز دارند که خواندن بسته‌ها را کارآمدتر می‌کند.

این همچنین به عنوان گزینه‌ای عمل می‌کند که اندازه بافر مورداستفاده توسط وب‌سوکت‌ها را هنگام خواندن هدر اولیه تنظیم می‌کند. اگر داده‌های هدر بزرگ مانند کوکی‌ها را ارسال می‌کنید، ممکن است لازم باشد این مقدار را افزایش دهید.

websockets_log_level سطح

سطح ثبت وقایع وب‌سوکت‌ها را تغییر می‌دهد. این یک گزینه سراسری است و امکان تنظیم آن به ازای هر شنونده وجود ندارد. این یک عدد صحیح است که توسط libwebsockets به عنوان ماسک بیتی برای شمارشگر lws_log_levels آن تفسیر می‌شود. برای جزئیات بیشتر مستندات libwebsockets را ببینید.

برای استفاده از این گزینه، log_type websockets نیز باید فعال باشد. پیش‌فرض 0 است.

websockets_origin مبدأ

در صورت تنظیم، هنگامی که یک اتصال تلاش می‌کند به WebSockets ارتقا یابد، این با هدر مبدأ http مقایسه می‌شود. فقط مبداهای منطبق مجاز خواهند بود. از رشته دقیقی که توسط مرورگر در هدر مبدأ ارائه شده است استفاده کنید، به عنوان مثال http://example.com:8080. می‌تواند چندین بار برای هر شنونده مشخص شود.

اگر تنظیم نشود، اتصالات از هر مبدئی مجاز خواهند بود.

نیازمند libwebsockets نسخه 3.1.0 یا بالاتر است.

گزینه‌های زیر برای همه شنوندگان جهت پیکربندی پشتیبانی SSL مبتنی بر گواهی در دسترس هستند. همچنین بخش «پشتیبانی از SSL/TLS مبتنی بر کلید از پیش اشتراک‌گذاری‌شده» را ببینید.

cafile مسیر فایل

گزینه cafile برای تعریف مسیر فایلی شامل گواهی‌های CA کدگذاری‌شده با PEM استفاده می‌شود که هنگام بررسی گواهی‌های کلاینت ورودی مورد اعتماد هستند.

capath مسیر پوشه

گزینه capath برای تعریف دایرکتوری شامل گواهی‌های CA کدگذاری‌شده با PEM استفاده می‌شود که هنگام بررسی گواهی‌های کلاینت ورودی مورد اعتماد هستند. برای اینکه capath به درستی کار کند، فایل‌های گواهی باید پسوند ".pem" داشته باشند و شما باید هر بار که گواهی اضافه یا حذف می‌کنید "openssl rehash <مسیر به capath>" را اجرا کنید.

گزینه capath برای وب‌سوکت‌ها پشتیبانی نمی‌شود.

certfile مسیر فایل

مسیر گواهی سرور با کدگذاری PEM. این گزینه و keyfile باید وجود داشته باشند تا رمزگذاری TLS مبتنی بر گواهی فعال شود.

گواهی مشخص‌شده توسط این گزینه هنگامی که Mosquitto یک سیگنال SIGHUP دریافت کند، دوباره بارگذاری می‌شود. این می‌تواند برای بارگذاری گواهی‌های جدید قبل از انقضای گواهی‌های موجود استفاده شود.

ciphers فهرست_رمزها

فهرست الگوریتم‌های رمزنگاری (ciphers) مجاز برای این شنونده، فقط برای TLS v1.2 و قبل‌تر، که هر کدام با یک دونقطه جدا شده‌اند. الگوریتم‌های رمزنگاری موجود را می‌توان با استفاده از دستور "openssl ciphers" به دست آورد.

ciphers_tls1.3 فهرست_مجموعه‌رمزها

فهرست مجموعه‌رمزهای مجاز برای این شنونده برای TLS v1.3 که هر کدام با دونقطه جدا شده‌اند.

crlfile مسیر فایل

اگر require_certificate را روی true تنظیم کرده‌اید، می‌توانید یک فایل فهرست ابطال گواهی (CRL) برای لغو دسترسی به گواهی‌های کلاینت خاص ایجاد کنید. اگر این کار را انجام داده‌اید، از crlfile برای اشاره به فایل ابطال با کدگذاری PEM استفاده کنید.

dhparamfile مسیر فایل

برای امکان استفاده از تبادل کلید گذرای دیفی-هلمن (ephemeral DH) که امنیت رو به جلو (forward security) را فراهم می‌کند، شنونده باید پارامترهای DH را بارگذاری کند. این را می‌توان با گزینه dhparamfile مشخص کرد. فایل dhparamfile را می‌توان به عنوان مثال با این دستور تولید کرد: 
openssl dhparam -out dhparam.pem 2048

disable_client_cert_date_checks [ true | false ]

در صورت تنظیم روی true، گزینه disable_client_cert_date_checks رفتار اعتبارسنجی گواهی را تغییر می‌دهد تا گواهی‌های کلاینت منقضی‌شده یا گواهی‌هایی را که هنوز معتبر نشده‌اند، هنگام استفاده از require_certificate true بپذیرد.

پیش‌فرض false است.

keyfile مسیر فایل

اگر tls_keyform برابر "pem" باشد، این مسیر کلید خصوصی سرور با کدگذاری PEM است. این گزینه و certfile باید وجود داشته باشند تا رمزگذاری TLS مبتنی بر گواهی فعال شود. اگر tls_keyform برابر "engine" باشد، این نشان‌دهنده دستگیره موتور (engine handle) کلید خصوصی است.

کلید خصوصی اشاره‌شده توسط این گزینه با دریافت سیگنال SIGHUP توسط Mosquitto دوباره بارگذاری می‌شود. این می‌تواند برای بارگذاری کلیدهای جدید قبل از انقضای کلیدهای موجود استفاده شود.

require_certificate [ true | false ]

به‌طور پیش‌فرض، شنونده‌ای که SSL/TLS روی آن فعال است به روشی مشابه با وب‌سرور دارای https عمل می‌کند، به این صورت که سرور دارای گواهی امضا شده توسط یک CA است و کلاینت تأیید می‌کند که این یک گواهی معتبر است. هدف کلی رمزگذاری ترافیک شبکه است. با تنظیم require_certificate روی true، کلاینتی که به این شنونده متصل می‌شود باید یک گواهی معتبر ارائه دهد تا اتصال شبکه برقرار شود. این امکان را فراهم می‌کند که دسترسی به کارگزار خارج از مکانیزم‌های ارائه‌شده توسط MQTT کنترل شود.

tls_engine شناسه موتور

یک شناسه موتور openssl معتبر. این موارد را می‌توان با دستور openssl engine فهرست کرد.

tls_engine_kpass_sha1 هش_sha1_گذرواژه_موتور

هش SHA1 گذرواژه کلید خصوصی هنگام استفاده از موتور TLS. برخی از موتورهای TLS مانند موتور TPM ممکن است برای دسترسی به گذرواژه نیاز داشته باشند. این گزینه اجازه می‌دهد یک هش SHA1 با کدگذاری هگز از گذرواژه مستقیماً به موتور ارسال شود، به جای اینکه گذرواژه از کاربر پرسیده شود.

tls_keyform [ pem | engine ]

نوع کلید خصوصی مورد استفاده هنگام برقراری اتصالات TLS را مشخص می‌کند. این می‌تواند "pem" یا "engine" باشد. این پارامتر زمانی مفید است که یک ماژول TPM استفاده می‌شود و کلید خصوصی با آن ایجاد شده است. پیش‌فرض "pem" است که به معنای استفاده از فایل‌های کلید خصوصی معمولی است.

tls_version نسخه

حداقل نسخه پروتکل TLS را برای استفاده در این شنونده پیکربندی می‌کند. مقادیر ممکن عبارتند از tlsv1.3 و tlsv1.2. در صورت تنظیم نشدن، پیش‌فرض اجازه دادن به TLS v1.3 و v1.2 است.

در نسخه 1.6.x و قبل‌تر Mosquitto، این گزینه تنها نسخه پروتکل TLS مجاز را تنظیم می‌کرد، نه حداقل نسخه را.

use_identity_as_username [ true | false ]

اگر require_certificate برابر true باشد، می‌توانید use_identity_as_username را روی true تنظیم کنید تا از مقدار CN از گواهی کلاینت به عنوان نام کاربری استفاده شود. اگر این true باشد، گزینه password_file برای این شنونده استفاده نخواهد شد.

اگر هر دو روی true تنظیم شده باشند، این گزینه بر use_subject_as_username اولویت دارد.

گزینه use_subject_as_username را نیز ببینید.

use_subject_as_username [ true | false ]

اگر require_certificate برابر true باشد، می‌توانید use_subject_as_username را روی true تنظیم کنید تا از مقدار کامل موضوع (subject) از گواهی کلاینت به عنوان نام کاربری استفاده شود. اگر این true باشد، گزینه password_file برای این شنونده استفاده نخواهد شد.

موضوع در قالبی مشابه زیر تولید خواهد شد: CN=test client,OU=Production,O=Server,L=Nottingham,ST=Nottinghamshire,C=GB.

گزینه use_identity_as_username را نیز ببینید.

گزینه‌های زیر برای همه شنوندگان جهت پیکربندی پشتیبانی SSL مبتنی بر کلید از پیش اشتراک‌گذاری‌شده در دسترس هستند. همچنین «پشتیبانی از SSL/TLS مبتنی بر گواهی» را ببینید.

ciphers فهرست_رمزها

هنگام استفاده از PSK، رمزهای رمزگذاری مورداستفاده از لیست رمزهای PSK موجود انتخاب می‌شوند. اگر می‌خواهید کنترل کنید کدام رمزها در دسترس باشند، از این گزینه استفاده کنید. فهرست رمزهای موجود را می‌توان با استفاده از دستور "openssl ciphers" به دست آورد و باید در همان قالب خروجی آن دستور ارائه شود.

psk_hint راهنما (hint)

گزینه psk_hint پشتیبانی از کلید از پیش اشتراک‌گذاری‌شده را برای این شنونده فعال می‌کند و همچنین به عنوان یک شناسه برای این شنونده عمل می‌کند. این راهنما به کلاینت‌ها ارسال می‌شود و ممکن است به صورت محلی برای کمک به احراز هویت استفاده شود. این راهنما یک رشته آزاد است که به خودی خود معنای چندانی ندارد، بنابراین در انتخاب آن آزاد هستید.

اگر این گزینه ارائه شده است، برای تعریف کلیدهای از پیش اشتراک‌گذاری‌شده مورد استفاده یا ایجاد یک افزونه امنیتی برای مدیریت آن‌ها، psk_file را ببینید.

tls_version نسخه

حداقل نسخه پروتکل TLS را برای استفاده در این شنونده پیکربندی می‌کند. مقادیر ممکن عبارتند از tlsv1.3 و tlsv1.2. در صورت تنظیم نشدن، پیش‌فرض اجازه دادن به TLS v1.3 و v1.2 است.

در نسخه 1.6.x و قبل‌تر Mosquitto، این گزینه تنها نسخه پروتکل TLS مجاز را تنظیم می‌کرد، نه حداقل نسخه را.

use_identity_as_username [ true | false ]

گزینه use_identity_as_username را تنظیم کنید تا هویت psk ارسال شده توسط کلاینت به عنوان نام کاربری آن استفاده شود. نام کاربری مانند حالت عادی بررسی می‌شود، بنابراین باید از password_file یا ابزار دیگری برای بررسی احراز هویت استفاده شود. هیچ گذرواژه‌ای استفاده نخواهد شد.

چندین پل (اتصال به سایر کارگزارها) را می‌توان با استفاده از متغیرهای زیر پیکربندی کرد.

با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود.

address آدرس[:درگاه] [آدرس[:درگاه]], addresses آدرس[:درگاه] [آدرس[:درگاه]]

آدرس و به صورت اختیاری درگاه پلی را که باید به آن متصل شود مشخص می‌کند. این باید برای هر اتصال پل داده شود. اگر درگاه مشخص نشده باشد، از درگاه پیش‌فرض 1883 استفاده می‌شود.

اگر از آدرس IPv6 استفاده می‌کنید، تعیین درگاه اختیاری نیست و الزامی است.

چندین آدرس میزبان را می‌توان در پیکربندی address مشخص کرد. برای جزئیات بیشتر در مورد رفتار پل‌ها با چندین آدرس، گزینه round_robin را ببینید.

bridge_attempt_unsubscribe [ true | false ]

اگر یک پل موضوعاتی با جهت "out" داشته باشد، رفتار پیش‌فرض این است که یک درخواست لغو اشتراک (unsubscribe) به کارگزار راه دور در آن موضوع ارسال کند. این بدان معنی است که تغییر جهت موضوع از "in" به "out" باعث ادامه دریافت پیام‌های ورودی نخواهد شد. ارسال این درخواست‌های لغو اشتراک همیشه مطلوب نیست؛ تنظیم bridge_attempt_unsubscribe روی false ارسال درخواست لغو اشتراک را غیرفعال می‌کند. پیش‌فرض true است.

bridge_bind_address آدرس آی‌پی

اگر لازم است که پل از طریق یک رابط شبکه خاص متصل شود، از bridge_bind_address استفاده کنید تا به پل بگویید سوکت باید به کدام آدرس IP محلی متصل شود، مثلاً bridge_bind_address 192.168.1.10.

bridge_max_packet_size مقدار

اگر می‌خواهید اندازه پیام‌های ارسالی به یک پل راه دور را محدود کنید، از این گزینه استفاده نمایید. این حداکثر تعداد بایت را برای کل پیام، شامل سرآیندها و بدنه پیام تنظیم می‌کند. توجه داشته باشید که کارگزاران MQTT v5 ممکن است ویژگی maximum-packet-size مخصوص به خود را ارائه دهند. در این حالت، محدودیت کوچکتر از بین این دو اعمال خواهد شد. برای حالت "نامحدود" روی 0 تنظیم کنید.

bridge_max_topic_alias مقدار

اگر پل از MQTT v5 استفاده می‌کند، این گزینه حداکثر تعداد نام‌های مستعار موضوع را که پل به کارگزار راه دور اجازه پیکربندی می‌دهد، تعیین می‌کند. پیش‌فرض 10 است، حداکثر 65535. برای غیرفعال کردن کامل نام‌های مستعار موضوعات ورودی، روی 0 تنظیم کنید.

bridge_outgoing_retain [ true | false ]

برخی از کارگزاران MQTT پیام‌های نگه‌داشته‌شده (retained) را مجاز نمی‌دانند. پروتکل MQTT v5 مکانیزمی را در اختیار کارگزاران قرار می‌دهد تا به کلاینت‌ها اعلام کنند از پیام‌های نگه‌داشته‌شده پشتیبانی نمی‌کنند، اما این کار برای MQTT v3.1.1 یا v3.1 امکان‌پذیر نیست. اگر نیاز به اتصال به یک کارگزار v3.1.1 یا v3.1 دارید که از پیام‌های نگه‌داشته‌شده پشتیبانی نمی‌کند، گزینه bridge_outgoing_retain را روی false تنظیم کنید. این کار بدون در نظر گرفتن هرگونه تنظیم دیگر، بیت retain را در تمام پیام‌های خروجی به آن پل حذف می‌کند. پیش‌فرض true است.

bridge_protocol_version نسخه

نسخه پروتکل MQTT را برای استفاده با این پل تنظیم می‌کند. می‌تواند یکی از موارد mqttv50، mqttv311 یا mqttv31 باشد. پیش‌فرض mqttv311 است.

bridge_receive_maximum تعداد

اگر پل از MQTT v5.0 استفاده می‌کند، از bridge_receive_maximum برای محدود کردن تعداد پیام‌های QoS 1 یا 2 که می‌توانند همزمان در جریان باشند استفاده کنید. باید بین 1 تا 65535 باشد. پیش‌فرض max_inflight_messages است که مقدار پیش‌فرض آن 20 می‌باشد.

bridge_session_expiry_interval بازه زمانی

اگر پل از MQTT v5.0 استفاده می‌کند، از bridge_session_expiry_interval برای تنظیم بازه انقضای نشست استفاده کنید. روی 0 تنظیم کنید تا با قطع اتصال، نشست بلافاصله منقضی شود. روی 0xFFFFFFFF تنظیم کنید تا بازه انقضای نامحدود داشته باشد. در غیر این صورت، بازه انقضا روی تعداد ثانیه‌هایی که مشخص می‌کنید تنظیم می‌شود. پیش‌فرض 0 است.

bridge_tcp_keepalive بیکاری فاصله شمارنده

پارامترهای TCP keepalive را برای این اتصال پل تنظیم می‌کند. از این گزینه استفاده کنید تا بتوانید مقدار طولانی برای نگه‌داری اتصال در پروتکل MQTT تنظیم کنید، در حالی که همچنان قادر به تشخیص قطع اتصال در یک زمان معقول باشید.

این گزینه ممکن است هنگام اتصال به سرویس‌هایی که برای پیام‌های PINGREQ هزینه دریافت می‌کنند مفید باشد.

به‌طور پیش‌فرض غیرفعال است.

bridge_tcp_user_timeout مهلت زمانی

حداکثر مدت زمانی (بر حسب میلی‌ثانیه) را مشخص می‌کند که داده‌های ارسال‌شده ممکن است در سطح TCP بدون تأیید باقی بمانند. توزیع‌های محبوب لینوکس به نظر می‌رسد این زمان را روی "حداکثر تا 20 دقیقه با پیش‌فرض‌های سیستم" تنظیم می‌کنند (برگرفته از صفحه راهنمای tcp لینوکس). زمان پیش‌فرض به tcp_retries2 مربوط می‌شود. کاهش این مقدار به تشخیص سریع‌تر اتصالات قطع‌شده کمک می‌کند.

توجه داشته باشید که وقتی در ترکیب با TCP Keepalive استفاده می‌شود، ممکن است رفتار دومی را تغییر دهد.

می‌توانید جزئیات بیشتر درباره این تنظیم را در اینجا بیابید: https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/

فقط در لینوکس موجود است.

cleansession [ true | false ]

گزینه clean session را برای این پل تنظیم می‌کند. تنظیم روی false (پیش‌فرض) به این معنی است که تمام اشتراک‌ها در کارگزار راه دور در صورت قطع اتصال شبکه حفظ می‌شوند. اگر روی true تنظیم شود، تمام اشتراک‌ها و پیام‌ها در کارگزار راه دور در صورت قطع اتصال پاکسازی خواهند شد. توجه داشته باشید که تنظیم روی true ممکن است باعث ارسال حجم زیادی از پیام‌های نگه‌داشته‌شده در هر بار اتصال مجدد پل شود.

اگر از پل‌هایی با cleansession تنظیم‌شده روی false (پیش‌فرض) استفاده می‌کنید، در صورت تغییر موضوعاتی که در آن‌ها مشترک می‌شوید ممکن است رفتار غیرمنتظره‌ای از موضوعات ورودی مشاهده کنید. این به این دلیل است که کارگزار راه دور اشتراک موضوع قبلی را نگه می‌دارد. اگر این مشکل را دارید، پل خود را با cleansession تنظیم‌شده روی true متصل کنید، سپس به حالت معمول با cleansession تنظیم‌شده روی false مجدداً متصل شوید.

local_cleansession [ true | false]

گزینه معمول cleansession هم اشتراک‌های محلی و هم اشتراک‌های راه دور را پوشش می‌دهد. local_cleansession امکان تفکیک این دو را فراهم می‌کند. تنظیم روی false به این معنی است که اتصال محلی اشتراک را مستقل از اتصال راه دور حفظ خواهد کرد.

پیش‌فرض مقدار bridge.cleansession است مگر اینکه به صراحت مشخص شده باشد.

connection نام

این متغیر شروع اتصال جدید یک پل را مشخص می‌کند. همچنین برای دادن نامی به پل استفاده می‌شود که به عنوان شناسه کلاینت در کارگزار راه دور استفاده می‌گردد.

keepalive_interval ثانیه

تعداد ثانیه‌هایی را تنظیم می‌کند که پس از آن در صورت عدم وقوع ترافیک دیگر، پل باید پینگ ارسال کند. پیش‌فرض 60 است. حداقل مقدار مجاز 5 ثانیه است.

idle_timeout ثانیه

مدت زمانی را تعیین می‌کند که یک پل با نوع راه‌اندازی lazy باید قبل از متوقف شدن در حالت بیکار بماند. پیش‌فرض 60 ثانیه است.

local_clientid شناسه

شناسه کلاینت را برای استفاده در کارگزار محلی تنظیم می‌کند. در صورت عدم تعریف، پیش‌فرض local.<remote_clientid> است. اگر یک کارگزار را به خودش متصل می‌کنید، مهم است که local_clientid و remote_clientid یکسان نباشند.

local_password گذرواژه

گذرواژه‌ای را پیکربندی می‌کند که هنگام اتصال این پل به کارگزار محلی استفاده می‌شود. این ممکن است در هنگام استفاده از احراز هویت و ACLها مهم باشد.

local_username نام کاربری

نام کاربری را برای اتصال این پل به کارگزار محلی پیکربندی می‌کند. این ممکن است در هنگام استفاده از احراز هویت و ACLها مهم باشد.

notifications [ true | false ]

اگر روی true تنظیم شود، پیام‌های اعلان حاوی اطلاعاتی در مورد وضعیت اتصال پل را به کارگزاران محلی و راه دور منتشر می‌کند. پیام‌های نگه‌داشته‌شده در موضوع $SYS/broker/connection/<remote_clientid>/state منتشر می‌شوند مگر اینکه با notification_topic طور دیگری تنظیم شده باشد. اگر پیام 1 باشد اتصال فعال است و اگر 0 باشد اتصال با شکست مواجه شده است. پیش‌فرض true است.

این گزینه از قابلیت وصیت‌نامه (Last Will and Testament یا LWT) استفاده می‌کند.

notifications_local_only [ true | false ]

اگر روی true تنظیم شود، فقط پیام‌های اعلان مربوط به وضعیت اتصال پل را به کارگزار محلی ارسال می‌کند. پیش‌فرض false است.

notification_topic موضوع

موضوعی را انتخاب می‌کند که اعلان‌ها برای این پل در آن منتشر خواهند شد. در صورت عدم تنظیم، پیام‌ها در موضوع $SYS/broker/connection/<remote_clientid>/state ارسال خواهند شد.

remote_clientid شناسه

شناسه کلاینت را برای این اتصال پل تنظیم می‌کند. اگر تعریف نشود، به طور پیش‌فرض روی 'name.hostname' قرار می‌گیرد که در آن name نام اتصال و hostname نام میزبان این رایانه است.

این گزینه جایگزین گزینه قدیمی "clientid" شده است تا از سردرگمی بین طرف‌های محلی/راه دور پل جلوگیری شود. گزینه "clientid" فعلاً معتبر باقی می‌ماند.

remote_password مقدار

یک گذرواژه برای پل پیکربندی می‌کند. این برای اهداف احراز هویت هنگام اتصال به کارگزاری که از MQTT v3.1 به بالا پشتیبانی می‌کند و برای اتصال به نام کاربری و/یا گذرواژه نیاز دارد استفاده می‌شود. این گزینه فقط در صورتی معتبر است که remote_username نیز ارائه شده باشد.

این گزینه جایگزین گزینه قدیمی "password" شده است تا از سردرگمی بین طرف‌های محلی/راه دور پل جلوگیری شود. گزینه "password" فعلاً معتبر باقی می‌ماند.

remote_username نام

یک نام کاربری برای پل پیکربندی می‌کند. این برای اهداف احراز هویت هنگام اتصال به کارگزاری که از MQTT v3.1 به بالا پشتیبانی می‌کند و برای اتصال به نام کاربری و/یا گذرواژه نیاز دارد استفاده می‌شود. گزینه remote_password را نیز ببینید.

این گزینه جایگزین گزینه قدیمی "username" شده است تا از سردرگمی بین طرف‌های محلی/راه دور پل جلوگیری شود. گزینه "username" فعلاً معتبر باقی می‌ماند.

restart_timeout پایه سقف [پایدار], restart_timeout ثابت

مدت زمانی را تنظیم می‌کند که یک پل با نوع راه‌اندازی خودکار (automatic) قبل از تلاش برای اتصال مجدد منتظر می‌ماند.

این گزینه را می‌توان برای استفاده از یک زمان تاخیر ثابت بر حسب ثانیه، یا استفاده از مکانیزم بازگشت مبتنی بر "Decorrelated Jitter" پیکربندی کرد که درجه‌ای از تصادفی بودن را به زمان وقوع راه‌اندازی مجدد اضافه می‌کند، از پایه (base) شروع شده و تا سقف (cap) افزایش می‌یابد. زمان بازگشت پس از اتصال موفقیت‌آمیز به base بازنشانی می‌شود. وقتی stable مشخص شده باشد، زمان بازگشت تنها در صورتی بازنشانی می‌شود که اتصال حداقل به مدت stable ثانیه باز بماند. مقدار پایه حداقل 1 ثانیه و حداکثر 3600 ثانیه است. سقف حداقل برابر پایه و حداکثر 7200 ثانیه است.

تنظیم یک مهلت زمانی ثابت 20 ثانیه‌ای:

restart_timeout 20

تنظیم عقب‌نشینی با پایه (مقدار شروع) 10 ثانیه و سقف (حد بالا) 60 ثانیه:

restart_timeout 10 60

مشابه مثال قبل، اما قبل از بازنشانی عقب‌نشینی، حداقل 30 ثانیه منتظر پایدار ماندن اتصال بمانید:

restart_timeout 10 60 30

پیش‌فرض جیتر با پایه 5 ثانیه و سقف 30 ثانیه است.

round_robin [ true | false ]

اگر پل بیش از یک آدرس در پیکربندی address/addresses داشته باشد، گزینه round_robin رفتار پل را در هنگام خرابی اتصال پل مشخص می‌کند. اگر round_robin برابر false (مقدار پیش‌فرض) باشد، اولین آدرس به عنوان اتصال اصلی پل در نظر گرفته می‌شود. اگر اتصال با شکست مواجه شود، سایر آدرس‌های ثانویه به نوبت امتحان خواهند شد. در حین اتصال به پل ثانویه، پل به طور دوره‌ای تلاش می‌کند تا زمانی که موفق شود دوباره به پل اصلی متصل گردد.

اگر round_robin برابر true باشد، با همه آدرس‌ها به طور مساوی برخورد می‌شود. اگر اتصالی با شکست مواجه شود، آدرس بعدی امتحان می‌شود و در صورت موفقیت تا زمان شکست متصل باقی می‌ماند.

start_type [ automatic | lazy | once ]

نوع راه‌اندازی پل را مشخص می‌کند. این نحوه راه‌اندازی پل را کنترل می‌کند و می‌تواند یکی از سه نوع باشد: automatic، lazy و once. توجه داشته باشید که RSMB نوع راه‌اندازی چهارم "manual" را ارائه می‌دهد که در حال حاضر توسط mosquitto پشتیبانی نمی‌شود.

نوع automatic نوع راه‌اندازی پیش‌فرض است و به این معنی است که اتصال پل به طور خودکار هنگام شروع کارگزار آغاز می‌شود و در صورت قطع اتصال نیز پس از یک تأخیر کوتاه (30 ثانیه) راه‌اندازی مجدد می‌گردد.

پل‌هایی که از نوع شروع lazy استفاده می‌کنند، زمانی که تعداد پیام‌های صف‌بندی‌شده از عدد تعیین‌شده با گزینه threshold بیشتر شود، به طور خودکار راه‌اندازی می‌شوند. پس از مدت زمان تعیین‌شده توسط پارامتر idle_timeout به طور خودکار متوقف خواهد شد. اگر می‌خواهید اتصال فقط در صورت نیاز فعال باشد از این نوع راه‌اندازی استفاده کنید.

پلی که از نوع راه‌اندازی once استفاده می‌کند هنگام راه‌اندازی کارگزار به طور خودکار شروع به کار می‌کند اما در صورت قطع اتصال مجدداً راه‌اندازی نمی‌شود.

threshold تعداد

تعداد پیام‌هایی را تعیین می‌کند که برای راه‌اندازی مجدد پلی با نوع شروع lazy باید در صف قرار گیرند. پیش‌فرض 10 پیام است.

topic الگو [[[ out | in | both ] سطح-qos] پیشوند-محلی پیشوند-راه‌دور]

یک الگوی موضوعی را برای اشتراک‌گذاری بین دو کارگزار تعریف می‌کند. هر موضوعی که با الگو مطابقت داشته باشد (که ممکن است شامل نویسه‌های عام باشد) به اشتراک گذاشته می‌شود. در صورتی که الگو حاوی فاصله باشد، می‌تواند در دو گیومه محصور شود. پارامتر دوم جهتی را که پیام‌ها در آن به اشتراک گذاشته می‌شوند مشخص می‌کند، بنابراین می‌توان پیام‌ها را از یک کارگزار راه دور با استفاده از in وارد کرد، پیام‌ها را با استفاده از out به کارگزار راه دور صادر کرد یا پیام‌ها را در هر دو جهت به اشتراک گذاشت. اگر این پارامتر تعریف نشده باشد، از مقدار پیش‌فرض out استفاده می‌شود. سطح QoS، سطح QoS انتشار/اشتراک مورد استفاده برای این موضوع را تعیین می‌کند و به طور پیش‌فرض 0 است.

گزینه‌های local-prefix و remote-prefix اجازه می‌دهند موضوعات هنگام انتشار به کارگزاران راه دور و دریافت از آنها بازنگاشت (remap) شوند. این اجازه می‌دهد تا درخت موضوعی از کارگزار محلی در یک مکان مناسب در درخت موضوعی کارگزار راه دور درج شود.

برای موضوعات ورودی، پل پیشوند راه دور را به ابتدای الگو اضافه کرده و در موضوع حاصل در کارگزار راه دور مشترک می‌شود. هنگامی که یک پیام ورودی منطبق دریافت شد، پیشوند راه دور از موضوع حذف شده و سپس پیشوند محلی اضافه می‌شود.

برای موضوعات خروجی، پل پیشوند محلی را به ابتدای الگو اضافه کرده و در موضوع حاصل در کارگزار محلی مشترک می‌شود. هنگامی که یک پیام خروجی پردازش شد، پیشوند محلی از موضوع حذف شده و سپس پیشوند راه دور اضافه می‌شود.

هنگام استفاده از نگاشت موضوع، می‌توان با استفاده از نشانگر "" یک پیشوند خالی تعریف کرد. استفاده از نشانگر خالی برای خود موضوع نیز معتبر است. جدول زیر مشخص می‌کند چه ترکیبی از خالی یا مقدار معتبر است. ستون‌های موضوع کامل محلی (Full Local Topic) و موضوع کامل راه دور (Full Remote Topic) موضوعات حاصلی را نشان می‌دهند که در انتهای محلی و راه دور پل استفاده می‌شوند. برای مثال، برای ردیف اول جدول اگر به L/topic روی کارگزار محلی پیامی منتشر کنید، کارگزار راه دور پیامی در مورد موضوع R/topic دریافت خواهد کرد.

الگو (Pattern) پیشوند محلی (Local Prefix) پیشوند راه دور (Remote Prefix) اعتبار (Validity) موضوع کامل محلی (Full Local Topic) موضوع کامل راه دور (Full Remote Topic)
pattern L/ R/ معتبر (valid) L/pattern R/pattern
pattern L/ "" معتبر (valid) L/pattern pattern
pattern "" R/ معتبر (valid) pattern R/pattern
pattern "" "" معتبر (بدون نگاشت مجدد) pattern pattern
"" local remote معتبر (نگاشت مجدد یک موضوع محلی به راه دور) local remote
"" local "" نامعتبر (invalid)    
"" "" remote نامعتبر (invalid)    
"" "" "" نامعتبر (invalid)    

برای نگاشت مجدد کل یک درخت موضوعی، به عنوان مثال از این دستور استفاده کنید:

topic # both 2 local/topic/ remote/topic/

این گزینه می‌تواند چندین بار برای هر پل مشخص شود.

باید دقت شود که با این گزینه حلقه‌ای ایجاد نشود. اگر بار پردازشی بالایی را روی پردازنده از یک کارگزار تجربه می‌کنید، ممکن است حلقه‌ای داشته باشید که در آن هر کارگزار دائماً پیام‌های یکسانی را برای دیگری ارسال می‌کند.

در صورتی که هنگام استفاده از موضوعات ورودی، پیام‌ها روی موضوعات غیرمنتظره‌ای می‌رسند، گزینه cleansession را نیز ببینید.

مثال: نگاشت مجدد موضوع پل. پیکربندی زیر یک پل را به کارگزار در test.mosquitto.org متصل می‌کند. این پل در موضوع راه دور $SYS/broker/clients/total مشترک می‌شود و پیام‌های دریافتی را در موضوع محلی test/mosquitto/org/clients/total بازنشر می‌کند.

connection test-mosquitto-org
address test.mosquitto.org
cleansession true
topic clients/total in 0 test/mosquitto/org/ $SYS/broker/

try_private [ true | false ]

اگر try_private روی true تنظیم شود، پل تلاش می‌کند به کارگزار راه دور نشان دهد که یک پل است و نه یک کلاینت معمولی. در صورت موفقیت، این بدان معنی است که تشخیص حلقه مؤثرتر خواهد بود و پیام‌های نگه‌داشته‌شده به درستی منتشر می‌شوند. همه کارگزاران از این ویژگی پشتیبانی نمی‌کنند، بنابراین در صورتی که پل شما به درستی متصل نشود ممکن است لازم باشد try_private را روی false تنظیم کنید.

پیش‌فرض true است.

bridge_reload_type [ lazy | immediate ]

اگر گزینه‌های پل را در فایل پیکربندی تغییر دهید، آن تغییرات پیکربندی در حین اتصال مجدد پل اعمال می‌شوند. گزینه bridge_reload_type تعیین می‌کند که اتصال مجدد چه زمانی اتفاق بیفتد، و می‌تواند روی lazy یا immediate تنظیم شود.

مقدار lazy پیش‌فرض است، و به این معنی است که هر پل متصل تا زمانی که یک اتصال مجدد طبیعی رخ دهد در حالت فعلی خود باقی می‌ماند، و در آن مرحله از پیکربندی جدید استفاده خواهد شد.

مقدار immediate اتصال مجدد را اجبار می‌کند و بنابراین بلافاصله از پیکربندی جدید استفاده می‌نماید.

گزینه‌های زیر برای همه پل‌ها جهت پیکربندی پشتیبانی از SSL/TLS در دسترس هستند.

bridge_alpn alpn

گزینه مذاکره پروتکل لایه کاربردی (ALPN) را برای نشست TLS پیکربندی می‌کند. برای کارگزارانی که از هر دو پروتکل WebSockets و MQTT روی یک درگاه پشتیبانی می‌کنند مفید است.

bridge_cafile مسیر فایل

حداقل یکی از گزینه‌های bridge_cafile، bridge_capath، یا bridge_tls_use_os_certs باید ارائه شود تا پشتیبانی SSL/TLS امکان‌پذیر باشد.

گزینه bridge_cafile برای تعریف مسیر فایلی حاوی گواهی‌های CA کدگذاری‌شده با PEM استفاده می‌شود که گواهی کارگزار راه دور را امضا کرده‌اند.

bridge_capath مسیر پوشه

حداقل یکی از گزینه‌های bridge_cafile، bridge_capath، یا bridge_tls_use_os_certs باید ارائه شود تا پشتیبانی SSL/TLS امکان‌پذیر باشد.

گزینه bridge_capath برای تعریف مسیر دایرکتوری حاوی گواهی‌های CA با کدگذاری PEM استفاده می‌شود که گواهی کارگزار راه دور را امضا کرده‌اند. برای اینکه bridge_capath به درستی کار کند، فایل‌های گواهی باید پسوند ".crt" داشته باشند و شما باید هر بار که گواهی اضافه یا حذف می‌کنید "openssl rehash <مسیر به bridge_capath>" را اجرا کنید.

bridge_certfile مسیر فایل

مسیر گواهی کلاینت با کدگذاری PEM برای این پل، در صورتی که توسط کارگزار راه دور الزامی باشد.

bridge_identity هویت

رمزگذاری با کلید از پیش اشتراک‌گذاری‌شده جایگزینی برای رمزگذاری مبتنی بر گواهی ارائه می‌دهد. یک پل را می‌توان با استفاده از گزینه‌های bridge_identity و bridge_psk برای استفاده از PSK پیکربندی کرد. این همان هویت کلاینت است که در رمزگذاری PSK استفاده می‌شود. تنها یکی از روش‌های رمزگذاری مبتنی بر گواهی و مبتنی بر PSK می‌تواند به طور همزمان روی یک پل استفاده شود.

bridge_insecure [ true | false ]

هنگام استفاده از TLS مبتنی بر گواهی، پل تلاش می‌کند تا نام میزبان ارائه‌شده در گواهی راه دور را با میزبان/آدرسی که به آن متصل است مطابقت دهد. این ممکن است در سناریوهای آزمایشی مشکلاتی ایجاد کند، بنابراین bridge_insecure می‌تواند روی true تنظیم شود تا اعتبارسنجی نام میزبان غیرفعال گردد.

تنظیم این گزینه روی true به این معنی است که یک شخص ثالث مخرب می‌تواند به طور بالقوه خود را به عنوان سرور شما جا بزند، بنابراین همیشه باید در محیط‌های عملیاتی روی false تنظیم شود.

bridge_keyfile مسیر فایل

مسیر کلید خصوصی با کدگذاری PEM برای این پل، در صورتی که توسط کارگزار راه دور الزامی باشد.

bridge_psk کلید

رمزگذاری کلید از پیش اشتراک‌گذاری‌شده جایگزینی برای رمزگذاری مبتنی بر گواهی فراهم می‌کند. یک پل را می‌توان با گزینه‌های bridge_identity و bridge_psk برای استفاده از PSK پیکربندی کرد. این همان کلید از پیش اشتراک‌گذاری‌شده در قالب هگزادسیمال بدون "0x" است. تنها یکی از روش‌های رمزگذاری مبتنی بر گواهی و PSK می‌تواند همزمان روی یک پل استفاده شود.

bridge_require_ocsp [ true | false ]

هنگامی که روی true تنظیم شود، پل نیازمند پروتکل OCSP روی اتصال TLS است که به عنوان کلاینت باز می‌کند.

bridge_tls_use_os_certs [ true | false ]

حداقل یکی از گزینه‌های bridge_cafile، bridge_capath، یا bridge_tls_use_os_certs باید ارائه شود تا پشتیبانی SSL/TLS امکان‌پذیر باشد.

گزینه bridge_tls_use_os_certs را روی true قرار دهید تا TLS برای این پل فعال شود و آن را طوری پیکربندی کنید که به گواهی‌های پیش‌فرض ارائه‌شده توسط openssl اعتماد کند. این معمولاً تعداد زیادی گواهی است. پیش‌فرض false است.

bridge_tls_version نسخه

نسخه پروتکل TLS را برای استفاده در این پل پیکربندی می‌کند. مقادیر ممکن عبارتند از tlsv1.3 و tlsv1.2. پیش‌فرض tlsv1.2 است. کارگزار راه دور برای برقراری موفقیت‌آمیز اتصال باید از همان نسخه TLS پشتیبانی کند.

bridge_ciphers فهرست_رمزها

فهرست الگوریتم‌های رمزنگاری مجاز برای این پل، فقط برای TLS v1.2 و قبل‌تر، که هر کدام با دونقطه جدا شده‌اند. رمزهای موجود را می‌توان با استفاده از دستور "openssl ciphers" به دست آورد.

bridge_ciphers_tls1.3 فهرست_مجموعه‌رمزها

فهرست مجموعه‌رمزهای مجاز برای این پل برای TLS v1.3 که هر کدام با دونقطه جدا شده‌اند.

mosquitto.conf

اطلاعات مربوط به باگ‌های mosquitto را می‌توان در نشانی زیر یافت: https://github.com/eclipse-mosquitto/mosquitto/issues

mosquitto(7), mosquitto(8), mosquitto_passwd(1), mosquitto-tls(7), mqtt(7), limits.conf(5)

Roger Light <roger@atchoo.org>

04/03/2026 Mosquitto Project