'\" t .\" Title: mosquitto.conf .\" Author: [see the "Author" section] .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 04/03/2026 .\" Manual: File formats and conventions .\" Source: Mosquitto Project .\" Language: Persian .\" .TH "MOSQUITTO\&.CONF" "5" "04/03/2026" "Mosquitto Project" "قالب‌های فایل و قراردادها" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "نام (NAME)" mosquitto.conf \- فایل پیکربندی برای mosquitto .SH "خلاصه دستور (SYNOPSIS)" .HP \w'\fBmosquitto\&.conf\fR\ 'u \fBmosquitto\&.conf\fR .SH "توضیحات (DESCRIPTION)" .PP \fBmosquitto\&.conf\fR فایل پیکربندی برای mosquitto است\&. تا زمانی که mosquitto دسترسی خواندن آن را داشته باشد، این فایل می‌تواند در هر مکانی قرار گیرد\&. به‌طور پیش‌فرض، mosquitto نیازی به فایل پیکربندی ندارد و از مقادیر پیش‌فرض فهرست‌شده در زیر استفاده خواهد کرد\&. برای اطلاعات بیشتر در مورد نحوه بارگذاری فایل پیکربندی، \fBmosquitto\fR(8) را ببینید\&. .PP می‌توان به mosquitto دستور داد تا با ارسال سیگنال SIGHUP مطابق آنچه در بخش Signals از \fBmosquitto\fR(8) توضیح داده شده است، فایل پیکربندی را دوباره بارگذاری کند\&. همه گزینه‌های پیکربندی قابل بارگذاری مجدد نیستند، همان‌طور که در توضیحات گزینه‌های زیر مشخص شده است\&. .SH "بخش‌ها (SECTIONS)" .PP ادامه این صفحه راهنما به بخش‌های زیر تقسیم شده است: .PP \fBقالب فایل (File Format)\fR شرحی از ساختار نوشتاری فایل پیکربندی\&. .RS 4 .RE .PP \fBاحراز هویت (Authentication)\fR بررسی گزینه‌های احراز هویت در دسترس\&. .RS 4 .RE .PP \fBگزینه‌های عمومی (General Options)\fR گزینه‌های عمومی برای پیکربندی Mosquitto\&. .RS 4 .RE .PP \fBشنوندگان (Listeners)\fR گزینه‌های عمومی برای پیکربندی شنوندگان، که راه‌های اتصال کلاینت‌های MQTT به Mosquitto هستند، و همچنین گزینه‌های SSL/TLS مبتنی بر گواهی و کلید از پیش اشتراک‌گذاری‌شده (PSK)\&. .RS 4 .RE .PP \fBپیکربندی پل‌ها (Configuring Bridges)\fR گزینه‌های عمومی برای پیکربندی پل‌ها، که روشی برای اتصال چندین کارگزار (broker) به یکدیگر است، و همچنین گزینه‌های SSL/TLS مبتنی بر گواهی و کلید از پیش اشتراک‌گذاری‌شده\&. .RS 4 .RE .PP \fBسایر (Other)\fR بخش‌های فایل‌ها، باگ‌ها و همچنین ببینید\&. .RS 4 .RE .SH "قالب فایل (FILE FORMAT)" .PP تمام خطوطی که اولین نویسه آن‌ها # باشد، به عنوان توضیح (کامنت) در نظر گرفته می‌شوند\&. .PP خطوط پیکربندی با یک نام متغیر شروع می‌شوند\&. مقدار متغیر با یک فاصله (space) از نام متغیر جدا می‌شود\&. .SH "احراز هویت (AUTHENTICATION)" .PP گزینه‌های احراز هویت شرح داده شده در زیر در ترکیب با گزینه‌های شنونده (listener) امکانات گسترده‌ای را فراهم می‌کنند\&. هدف این بخش روشن ساختن این امکانات است\&. یک نمای کلی نیز در آدرس زیر در دسترس است: \m[blue]\fB\%https://mosquitto.org/documentation/authentication-methods/\fR\m[] .PP ساده‌ترین حالت، عدم استفاده از هیچ‌گونه احراز هویت است\&. در صورتی که گزینه دیگری تعیین نشده باشد، این حالت پیش‌فرض خواهد بود\&. پشتیبانی از رمزگذاری بدون احراز هویت با استفاده از گزینه‌های SSL/TLS مبتنی بر گواهی certfile و keyfile فراهم می‌شود\&. .PP پروتکل MQTT احراز هویت نام کاربری/گذرواژه را به عنوان بخشی از پروتکل ارائه می‌دهد\&. از گزینه password_file برای تعیین نام‌های کاربری و گذرواژه‌های معتبر استفاده کنید\&. اگر از این گزینه استفاده می‌کنید، حتماً از رمزگذاری شبکه بهره ببرید؛ در غیر این صورت نام کاربری و گذرواژه در برابر شنود آسیب‌پذیر خواهند بود\&. از گزینه \fBper_listener_settings\fR برای کنترل اینکه آیا گذرواژه‌ها به صورت سراسری الزامی باشند یا بر اساس هر شنونده، استفاده کنید\&. .PP نرم‌افزار Mosquitto افزونه Dynamic Security را ارائه می‌دهد که احراز هویت نام کاربری/گذرواژه و کنترل دسترسی را بسیار انعطاف‌پذیرتر از یک فایل گذرواژه مدیریت می‌کند\&. آدرس زیر را ببینید: \m[blue]\fB\%https://mosquitto.org/documentation/dynamic-security/\fR\m[] .PP هنگام استفاده از رمزگذاری مبتنی بر گواهی، سه گزینه بر احراز هویت تأثیر می‌گذارند\&. گزینه اول 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\&. .PP هنگام استفاده از رمزگذاری مبتنی بر کلید از پیش اشتراک‌گذاری‌شده از طریق گزینه‌های psk_hint و psk_file، کلاینت باید قبل از برقراری هرگونه ارتباط MQTT، یک هویت و کلید معتبر برای اتصال به کارگزار ارائه دهد\&. اگر use_identity_as_username برابر true باشد، هویت PSK به جای نام کاربری MQTT برای اهداف کنترل دسترسی استفاده می‌شود\&. اگر use_identity_as_username برابر false باشد، کلاینت در صورت استفاده از گزینه password_file همچنان می‌تواند با استفاده از نام کاربری/گذرواژه MQTT احراز هویت کند\&. .PP هر دو رمزگذاری مبتنی بر گواهی و مبتنی بر PSK به ازای هر شنونده پیکربندی می‌شوند\&. .PP می‌توان افزونه‌های احراز هویت ایجاد کرد تا گزینه‌های password_file، acl_file و psk_file را با جستجوهای مبتنی بر مثلاً SQL ارتقا دهند\&. .PP پشتیبانی همزمان از چندین طرح احراز هویت امکان‌پذیر است\&. می‌توان پیکربندی‌ای ایجاد کرد که برای تمامی گزینه‌های رمزگذاری مختلف شرح داده شده در بالا دارای یک شنونده باشد و بنابراین روش‌های متعددی برای احراز هویت ارائه دهد\&. .SH "گزینه‌های عمومی (GENERAL OPTIONS)" .PP \fBacl_file\fR \fIمسیر فایل\fR .RS 4 \fIنکته:\fR پیشنهاد می‌شود به جای این گزینه از افزونه \fBmosquitto_acl_file\fR استفاده کنید\&. استفاده از افزونه‌ها برای احراز هویت و اعطای مجوز امکان کنترل بیشتری بر روی اعمال آن‌ها به شنوندگان مختلف، بدون نیاز به گزینه منسوخ‌شده \fBper_listener_settings\fR فراهم می‌کند\&. .sp مسیر یک فایل فهرست کنترل دسترسی (ACL) را تنظیم می‌کند\&. در صورت تعریف، محتوای فایل برای کنترل دسترسی کلاینت به موضوعات (topics) روی کارگزار استفاده می‌شود\&. .sp اگر این پارامتر تعریف شود، فقط به موضوعات فهرست‌شده دسترسی داده خواهد شد\&. دسترسی به موضوع با خطوطی با قالب زیر اضافه می‌شود: .sp topic [read|write|readwrite|deny] .sp نوع دسترسی با استفاده از "read"، "write"، "readwrite" یا "deny" کنترل می‌شود\&. این پارامتر اختیاری است (مگر اینکه شامل نویسه فاصله باشد) \- در صورت عدم تعیین، دسترسی read/write خواهد بود\&. می‌تواند مانند اشتراک‌ها شامل نویسه‌های عام + یا # باشد\&. گزینه "deny" می‌تواند برای رد صریح دسترسی به موضوعی استفاده شود که در غیر این صورت با دستور گسترده‌تر read/write/readwrite مجاز می‌شد\&. هر موضوع "deny" قبل از موضوعاتی که دسترسی خواندن/نوشتن می‌دهند پردازش می‌شود\&. .sp اولین مجموعه موضوعات، با فرض اینکه \fBallow_anonymous\fR برابر true باشد، به کلاینت‌های ناشناس اعمال می‌شود\&. فهرست‌های دسترسی مربوط به کاربران خاص بعد از خط کاربر به صورت زیر اضافه می‌شوند: .sp user .sp نام کاربری ذکر شده در اینجا همان نام کاربری در \fBpassword_file\fR است، نه شناسه کلاینت (clientid)\&. .sp همچنین می‌توان ACLها را بر اساس جایگزینی الگو در موضوع تعریف کرد\&. قالب آن مانند کلمه کلیدی topic است، اما از pattern به عنوان کلمه کلیدی استفاده می‌شود\&. .sp pattern [read|write|readwrite|deny] .sp الگوهای موجود برای جایگزینی عبارتند از: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} %c برای تطبیق با شناسه کلاینت (client id) .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} %u برای تطبیق با نام کاربری کلاینت .RE .sp الگوی جایگزینی باید تنها متن در آن سطح از سلسله‌مراتب باشد\&. الگوهای ACL برای همه کاربران اعمال می‌شوند حتی اگر کلمه کلیدی "user" پیش‌تر داده شده باشد\&. .sp مثال: .sp pattern write sensor/%u/data .sp اجازه دسترسی برای پیام‌های اتصال پل: .sp pattern write $SYS/broker/connection/%c/state .sp اگر اولین نویسه یک خط از فایل ACL علامت # باشد، به عنوان توضیح در نظر گرفته می‌شود\&. .sp اگر \fBper_listener_settings\fR برابر \fItrue\fR باشد، این گزینه تنها به شنونده‌ای که در حال حاضر پیکربندی می‌شود اعمال خواهد شد\&. اگر \fBper_listener_settings\fR برابر \fIfalse\fR باشد، این گزینه برای تمام شنوندگان اعمال می‌شود\&. .sp نکته: به‌طور کلی امکان اعطای دسترسی نوشتن به موضوعات درون درخت موضوعی $SYS وجود ندارد\&. استثنای آن \fI$SYS/broker/connection/+/state\fR است\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. داده‌های ACL بارگذاری‌شده فعلی آزاد شده و دوباره بارگذاری خواهند شد\&. اشتراک‌های موجود پس از بارگذاری مجدد تحت تأثیر قرار خواهند گرفت\&. .sp همچنین ببینید: \m[blue]\fB\%https://mosquitto.org/documentation/dynamic-security/\fR\m[] .RE .PP \fBallow_anonymous\fR [ true | false ] .RS 4 مقدار بولی سراسری که تعیین می‌کند آیا کلاینت‌هایی که بدون ارائه نام کاربری متصل می‌شوند اجازه اتصال دارند یا خیر\&. در صورت تنظیم روی \fIfalse\fR باید ابزار اتصال دیگری برای کنترل دسترسی کلاینت احراز هویت‌شده ایجاد شود\&. .sp مقدار پیش‌فرض \fIfalse\fR است، مگر اینکه هیچ شنونده‌ای در فایل پیکربندی تعریف نشده باشد، که در این صورت روی \fItrue\fR تنظیم می‌شود، اما اتصالات فقط از ماشین محلی مجاز خواهند بود\&. .sp اگر می‌خواهید این تنظیم را برای هر شنونده به طور جداگانه کنترل کنید، از گزینه \fBlistener_allow_anonymous\fR استفاده نمایید\&. .sp (نکته: منسوخ‌شده) اگر \fBper_listener_settings\fR برابر \fItrue\fR باشد، این گزینه فقط برای شنونده فعلی که در حال پیکربندی است اعمال می‌شود\&. اگر \fBper_listener_settings\fR برابر \fIfalse\fR باشد، این گزینه برای همه شنوندگان اعمال خواهد شد\&. .if n \{\ .sp .\} .RS 4 .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBمهم\fR .ps -1 .br در نسخه 1\&.6\&.x و قبل‌تر، این گزینه به طور پیش‌فرض روی \fItrue\fR بود مگر اینکه گزینه امنیتی دیگری تنظیم شده باشد\&. .sp .5v .RE با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBallow_duplicate_messages\fR [ true | false ] .RS 4 این گزینه منسوخ شده است و در نسخه آینده حذف خواهد شد\&. رفتار آن به صورت پیش‌فرض true خواهد بود\&. .sp اگر کلاینتی در چندین اشتراک مشترک شده باشد که هم‌پوشانی دارند، به عنوان مثال foo/# و foo/+/baz ، آنگاه MQTT انتظار دارد هنگامی که کارگزار پیامی در مورد موضوعی دریافت می‌کند که با هر دو اشتراک مطابقت دارد، مانند foo/bar/baz، کلاینت باید فقط یک بار پیام را دریافت کند\&. .sp نرم‌افزار Mosquitto برای برآورده کردن این نیاز ردیابی می‌کند که پیام به کدام کلاینت‌ها ارسال شده است\&. این گزینه اجازه می‌دهد این رفتار غیرفعال شود، که ممکن است در صورتی که تعداد زیادی کلاینت دارید که در یک مجموعه موضوع مشابه مشترک هستند و می‌خواهید مصرف حافظه را به حداقل برسانید، مفید باشد\&. .sp اگر از قبل می‌دانید که کلاینت‌های شما هرگز اشتراک‌های هم‌پوشان نخواهند داشت، می‌توان با خیال راحت آن را روی \fItrue\fR تنظیم کرد، در غیر این صورت کلاینت‌های شما باید بتوانند حتی زمانی که QoS=2 دارند پیام‌های تکراری را به درستی پردازش کنند\&. .sp پیش‌فرض روی \fItrue\fR است\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBallow_zero_length_clientid\fR [ true | false ] .RS 4 پروتکل‌های MQTT 3\&.1\&.1 و MQTT 5 به کلاینت‌ها اجازه می‌دهند با یک شناسه کلاینت با طول صفر متصل شوند و از کارگزار بخواهند یک شناسه کلاینت برای آن‌ها ایجاد کند\&. از این گزینه برای مجاز/غیرمجاز کردن این رفتار استفاده کنید\&. پیش‌فرض true است\&. .sp گزینه \fBauto_id_prefix\fR را نیز ببینید\&. .sp اگر \fBper_listener_settings\fR برابر \fItrue\fR باشد، این گزینه تنها به شنونده فعلی که در حال پیکربندی است اعمال می‌شود\&. اگر \fBper_listener_settings\fR برابر \fIfalse\fR باشد، این گزینه به تمامی شنوندگان اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBauth_plugin_deny_special_chars\fR [ true | false ] .RS 4 اگر \fItrue\fR باشد، قبل از انجام بررسی ACL، نام کاربری/شناسه کلاینت متقاضی بررسی، برای وجود نویسه‌های \*(Aq+\*(Aq یا \*(Aq#\*(Aq جستجو می‌شود\&. اگر هر یک از این نویسه‌ها در نام کاربری یا شناسه کلاینت پیدا شود، بررسی ACL قبل از ارسال به افزونه رد می‌شود\&. .sp این بررسی از مواردی جلوگیری می‌کند که در آن یک کاربر مخرب می‌تواند با استفاده از یکی از این نویسه‌ها به عنوان نام کاربری یا شناسه کلاینت خود، یک بررسی ACL را دور بزند\&. این همان مشکلی است که برای خود mosquitto با عنوان CVE\-2017\-7650 گزارش شد\&. .sp اگر کاملاً مطمئن هستید که افزونه‌ای که استفاده می‌کنید در برابر این حمله آسیب‌پذیر نیست (یعنی اگر هرگز از نام‌های کاربری یا شناسه‌های کلاینت در موضوعات استفاده نمی‌کنید) می‌توانید با تنظیم این گزینه روی \fIfalse\fR این بررسی اضافه را غیرفعال کرده و بنابراین تمام بررسی‌های ACL را به افزونه خود تحویل دهید\&. .sp پیش‌فرض روی \fItrue\fR است\&. .sp به افزونه احراز هویت فعلی که در حال پیکربندی است اعمال می‌شود\&. .sp در حال حاضر با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBauto_id_prefix\fR \fIپیشوند\fR .RS 4 این گزینه منسوخ شده است، لطفاً به جای آن از \fBlistener_auto_id_prefix\fR استفاده کنید\&. .sp اگر \fBallow_zero_length_clientid\fR برابر \fItrue\fR باشد، این گزینه به شما امکان می‌دهد رشته‌ای را تنظیم کنید که به ابتدای شناسه‌های کلاینت ایجادشده به صورت خودکار اضافه شود تا دیده‌شدن آن‌ها در گزارش‌ها آسان‌تر شود\&. پیش‌فرض \fBauto\-\fR است\&. .sp اگر \fBper_listener_settings\fR برابر \fItrue\fR باشد، این گزینه فقط برای شنونده فعلی که در حال پیکربندی است اعمال می‌شود\&. اگر \fBper_listener_settings\fR برابر \fIfalse\fR باشد، این گزینه برای همه شنوندگان اعمال خواهد شد\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBautosave_interval\fR \fIثانیه\fR .RS 4 تعداد ثانیه‌هایی که mosquitto بین هر بار ذخیره پایگاه داده درون حافظه روی دیسک منتظر می‌ماند\&. اگر روی 0 تنظیم شود، پایگاه داده درون حافظه فقط زمانی ذخیره می‌شود که mosquitto خارج شود یا سیگنال SIGUSR1 را دریافت کند\&. توجه داشته باشید که این تنظیم فقط در صورتی تأثیر دارد که پایداری (persistence) توکار فعال باشد\&. پیش‌فرض 1800 ثانیه (30 دقیقه) است\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBautosave_on_changes\fR [ true | false ] .RS 4 اگر \fItrue\fR باشد، mosquitto تعداد تغییرات اشتراک، پیام‌های نگه‌داشته‌شده (retained) دریافت شده و پیام‌های صف‌بندی‌شده را می‌شمارد و اگر مجموع از \fBautosave_interval\fR بیشتر شود، پایگاه داده درون حافظه روی دیسک ذخیره خواهد شد\&. اگر \fIfalse\fR باشد، mosquitto با تلقی کردن \fBautosave_interval\fR به عنوان زمان بر حسب ثانیه، پایگاه داده درون حافظه را روی دیسک ذخیره می‌کند\&. .sp تنها به پایداری توکار اعمال می‌شود\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBcheck_retain_source\fR [ true | false ] .RS 4 این گزینه بر سناریویی تأثیر می‌گذارد که کلاینتی در یک موضوع که دارای پیام‌های نگه‌داشته‌شده است مشترک می‌شود\&. ممکن است کلاینتی که پیام نگه‌داشته‌شده را در موضوع منتشر کرده است، در زمان انتشار دسترسی داشته باشد، اما این دسترسی متعاقباً حذف شده باشد\&. اگر \fBcheck_retain_source\fR روی true (پیش‌فرض) تنظیم شده باشد، منبع یک پیام نگه‌داشته‌شده قبل از انتشار مجدد برای بررسی حقوق دسترسی بررسی می‌شود\&. وقتی روی false تنظیم شود، هیچ بررسی انجام نخواهد شد و پیام نگه‌داشته‌شده همیشه منتشر می‌شود\&. .sp این گزینه صرف نظر از گزینه \fBper_listener_settings\fR به صورت سراسری اعمال می‌شود\&. .RE .PP \fBclientid_prefixes\fR \fIپیشوند\fR .RS 4 این گزینه منسوخ شده است و در نسخه آینده حذف خواهد شد\&. .sp در صورت تعریف، فقط کلاینت‌هایی که شناسه کلاینت با پیشوندی مطابق با clientid_prefixes دارند، اجازه اتصال به کارگزار را خواهند داشت\&. برای مثال، تنظیم "secure\-" در اینجا به این معنی است که کلاینت "secure\-client" می‌تواند متصل شود اما کلاینت دیگری با شناسه "mqtt" نمی‌تواند\&. به‌طور پیش‌فرض، همه شناسه‌های کلاینت معتبر هستند\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. توجه داشته باشید که کلاینت‌هایی که در حال حاضر متصل هستند تحت تأثیر هیچ تغییری قرار نخواهند گرفت\&. .RE .PP \fBconnection_messages\fR [ true | false ] .RS 4 اگر روی \fItrue\fR تنظیم شود، لاگ شامل ورودی‌هایی در هنگام اتصال و قطع اتصال کلاینت‌ها خواهد بود\&. اگر روی \fIfalse\fR تنظیم شود، این ورودی‌ها ظاهر نمی‌شوند\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBenable_control_api\fR [ true | false ] .RS 4 اگر روی \fItrue\fR تنظیم شود، مسیر \fB$CONTROL/broker/v1\fR فعال خواهد شد\&. این در حال حاضر امکان بررسی اینکه کدام افزونه‌ها فعال هستند را می‌دهد، اما در آینده امکان دسترسی به پیکربندی گزینه‌های عمومی کارگزار را فراهم خواهد کرد\&. اگر این را فعال کنید، باید مطمئن شوید که احراز هویت و کنترل دسترسی مناسب پیکربندی شده است، یعنی فقط اجازه دسترسی به \fB$CONTROL/broker/#\fR را برای مجموعه محدودی از کاربران بدهید\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBglobal_max_clients\fR \fIتعداد\fR .RS 4 حداکثر تعداد نشست‌های کلاینت مجاز در سراسر کارگزار\&. در این زمینه، یک نشست کلاینت به معنای کلاینتی است که در حال حاضر از طریق شبکه متصل است، یا کلاینتی که clean_session = False (در MQTT v3\&.x) دارد و قطع شده است، یا قطع شده و هنوز از بازه انقضای نشست خود فراتر نرفته است (در MQTT v5)\&. .sp تنظیم \fBmax_connections\fR را نیز ببینید که برای شنوندگان اعمال می‌شود\&. اگر \fBglobal_max_clients\fR را روی 1000 و \fBmax_connections\fR روی یک شنونده را روی 10 تنظیم کنید، این بدان معناست که تنها 10 اتصال همزمان در یک زمان مجاز خواهد بود، با حداکثر کلی 1000 نشست کلاینت\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp پیش‌فرض \-1 (نامحدود) است\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBglobal_max_connections\fR \fIتعداد\fR .RS 4 حداکثر تعداد کلاینت‌های متصل همزمان مجاز در سراسر کارگزار\&. .sp تنظیمات \fBglobal_max_clients\fR و \fBmax_connections\fR را نیز ببینید\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp پیش‌فرض \-1 (نامحدود) است\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBglobal_plugin\fR \fIمسیر فایل\fR .RS 4 یک ماژول خارجی برای گسترش ویژگی‌های کارگزار بارگذاری می‌کند\&. این افزونه‌ها را برای استفاده در تمام شنوندگان، صرف نظر از مقدار گزینه \fBper_listener_settings\fR بارگذاری می‌کند\&. این گزینه از همه جهات دیگر عملکردی مشابه گزینه \fBplugin\fR دارد\&. .sp اگر \fBper_listener_settings true\fR را تنظیم کرده و سپس هر دو گزینه \fBglobal_plugin\fR و یک \fBplugin\fR (که به یک شنونده خاص متصل خواهد شد) را تعریف کنید، افزونه سراسری همیشه ابتدا پردازش می‌شود\&. .sp اگر \fBper_listener_settings false\fR را تنظیم کنید، آنگاه \fBglobal_plugin\fR دقیقاً مانند \fBplugin\fR عمل می‌کند\&. .RE .PP \fBinclude_dir\fR \fIمسیر پوشه\fR .RS 4 فایل‌های پیکربندی خارجی را می‌توان با استفاده از گزینه include_dir اضافه کرد\&. این گزینه یک دایرکتوری را تعریف می‌کند که برای فایل‌های پیکربندی جستجو خواهد شد\&. همه فایل‌هایی که به \*(Aq\&.conf\*(Aq ختم می‌شوند به عنوان یک فایل پیکربندی بارگذاری می‌شوند\&. بهتر است این گزینه را به عنوان آخرین گزینه در فایل اصلی قرار دهید\&. این گزینه فقط از فایل پیکربندی اصلی پردازش می‌شود\&. دایرکتوری مشخص‌شده نباید شامل فایل پیکربندی اصلی باشد\&. .sp فایل‌های پیکربندی در \fBinclude_dir\fR به ترتیب الفبایی حساس به حروف بزرگ و کوچک بارگذاری می‌شوند، به‌طوری‌که حروف بزرگ هر حرف قبل از حروف کوچک همان حرف مرتب می‌شوند\&. .PP \fBمثال: ترتیب بارگذاری برای include_dir\&.\fR با داشتن فایل‌های \fIb\&.conf\fR، \fIA\&.conf\fR، \fI01\&.conf\fR، \fIa\&.conf\fR، \fIB\&.conf\fR، و \fI00\&.conf\fR درون \fBinclude_dir\fR، فایل‌های پیکربندی به این ترتیب بارگذاری می‌شوند: .sp .if n \{\ .RS 4 .\} .nf 00\&.conf 01\&.conf A\&.conf a\&.conf B\&.conf b\&.conf .fi .if n \{\ .RE .\} اگر این گزینه چندین بار استفاده شود، هر گزینه \fBinclude_dir\fR به طور کامل به ترتیبی که در فایل پیکربندی اصلی نوشته شده‌اند پردازش می‌شود\&. .PP \fBمثال: ترتیب بارگذاری برای چندین include_dir\&.\fR با فرض دایرکتوری \fIone\&.d\fR شامل فایل‌های \fIB\&.conf\fR و \fIC\&.conf\fR، و دایرکتوری دوم \fItwo\&.d\fR شامل فایل‌های \fIA\&.conf\fR و \fID\&.conf\fR، و یک پیکربندی: .sp .if n \{\ .RS 4 .\} .nf include_dir one\&.d include_dir two\&.d .fi .if n \{\ .RE .\} .sp سپس فایل‌های پیکربندی به این ترتیب بارگذاری می‌شوند: .sp .if n \{\ .RS 4 .\} .nf # فایل‌ها از one\&.d B\&.conf C\&.conf # فایل‌ها از two\&.d A\&.conf D\&.conf .fi .if n \{\ .RE .\} .RE .PP \fBlog_dest\fR \fIمقاصد\fR .RS 4 پیام‌های لاگ را به یک مقصد خاص ارسال می‌کند\&. مقاصد ممکن عبارتند از: \fBstdout\fR \fBstderr\fR \fBsyslog\fR \fBtopic\fR \fBfile\fR \fBdlt\fR \fBandroid\fR\&. .sp گزینه‌های \fBstdout\fR و \fBstderr\fR گزارش‌ها را در کنسول روی خروجی نام‌گذاری‌شده ثبت می‌کنند\&. .sp گزینه \fBsyslog\fR از امکانات syslog فضای کاربری استفاده می‌کند که معمولاً در /var/log/messages یا موارد مشابه قرار می‌گیرد\&. .sp گزینه \fBtopic\fR در موضوع کارگزار \*(Aq$SYS/broker/log/\*(Aq لاگ می‌اندازد، که در آن 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) هرگز در موضوعات ثبت نمی‌شوند\&. .sp مقصد \fBfile\fR به یک پارامتر اضافی نیاز دارد که فایلی است که گزارش‌ها در آن ثبت می‌شوند، به عنوان مثال "log_dest file /var/log/mosquitto\&.log"\&. وقتی کارگزار سیگنال HUP دریافت کند، فایل بسته شده و دوباره باز می‌شود\&. تنها یک مقصد فایل می‌تواند پیکربندی شود\&. .sp مقصد \fBdlt\fR برای ابزار خودروسازی `Diagnostic Log and Trace` است\&. این نیاز دارد که Mosquitto با پشتیبانی از DLT کامپایل شده باشد\&. .sp مقصد \fBandroid\fR فقط برای اندروید است و به دیمن logd خروجی می‌دهد\&. .sp اگر می‌خواهید ثبت گزارش را غیرفعال کنید از "log_dest none" استفاده کنید\&. پیش‌فرض stderr است\&. این گزینه می‌تواند چندین بار مشخص شود\&. .sp توجه داشته باشید که اگر کارگزار به عنوان یک سرویس ویندوز اجرا شود، به طور پیش‌فرض روی "log_dest none" قرار می‌گیرد و نه ثبت در stdout و نه در stderr در دسترس نخواهد بود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBlog_facility\fR \fIبخش محلی\fR .RS 4 در صورت استفاده از ثبت در syslog (نه در ویندوز)، پیام‌ها به طور پیش‌فرض در بخش "daemon" ثبت می‌شوند\&. از گزینه \fBlog_facility\fR برای انتخاب اینکه به جای آن در کدام‌یک از local0 تا local7 لاگ انداخته شود، استفاده کنید\&. مقدار گزینه باید یک مقدار عدد صحیح باشد، مثلاً "log_facility 5" برای استفاده از local5\&. .RE .PP \fBlog_timestamp\fR [ true | false ] .RS 4 مقدار بولی؛ اگر روی \fItrue\fR تنظیم شود، یک مقدار برچسب زمان به هر ورودی لاگ اضافه می‌شود\&. پیش‌فرض \fItrue\fR است\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBlog_timestamp_format\fR \fIقالب\fR .RS 4 قالب برچسب زمان گزارش را تنظیم می‌کند\&. اگر تنظیم نشده رها شود، تعداد ثانیه‌های سپری‌شده از مبدأ یونیکس (Unix epoch) خواهد بود\&. این گزینه یک رشته متنی آزاد است که به عنوان مشخص‌کننده قالب به تابع strftime ارسال می‌شود\&. برای مثال، برای دریافت تاریخ‌زمان ISO 8601: .sp .if n \{\ .RS 4 .\} .nf log_timestamp_format %Y\-%m\-%dT%H:%M:%S .fi .if n \{\ .RE .\} .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBlog_type\fR \fIانواع\fR .RS 4 انواع پیام‌ها را برای ثبت انتخاب می‌کند\&. انواع ممکن عبارتند از: \fIdebug\fR، \fIerror\fR، \fIwarning\fR، \fInotice\fR، \fIinformation\fR، \fIsubscribe\fR، \fIunsubscribe\fR، \fIwebsockets\fR، \fInone\fR، \fIall\fR\&. .sp پیش‌فرض \fIerror\fR، \fIwarning\fR، \fInotice\fR و \fIinformation\fR است\&. این گزینه می‌تواند چندین بار مشخص شود\&. توجه داشته باشید که نوع \fIdebug\fR (که برای رمزگشایی بسته‌های شبکه ورودی/خروجی استفاده می‌شود) هرگز در موضوعات ثبت نمی‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBmax_inflight_bytes\fR \fIتعداد\fR .RS 4 پیام‌های خروجی QoS 1 و 2 مجاز خواهند بود تا زمانی که به این محدودیت بایت برسند در جریان ارسال (in flight) باشند\&. این امکان کنترل نرخ پیام خروجی را بر اساس اندازه پیام به جای تعداد پیام فراهم می‌کند\&. اگر محدودیت روی 100 تنظیم شود، پیام‌های بیش از 100 بایت همچنان مجاز هستند، اما تنها یک پیام می‌تواند در یک زمان در جریان باشد\&. پیش‌فرض 0 است (بدون محدودیت)\&. .sp گزینه \fBmax_inflight_messages\fR را نیز ببینید\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBmax_inflight_messages\fR \fIتعداد\fR .RS 4 حداکثر تعداد پیام‌های خروجی QoS 1 یا 2 که می‌توانند به طور همزمان در حال انتقال باشند\&. این شامل پیام‌هایی است که در حال حاضر دست‌تکانی (handshake) را طی می‌کنند و پیام‌هایی که در حال تلاش مجدد هستند\&. پیش‌فرض 20 است\&. برای نامحدود بودن روی 0 تنظیم کنید\&. اگر روی 1 تنظیم شود، تحویل مرتب پیام‌ها را تضمین می‌کند\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBmax_keepalive\fR \fIمقدار\fR .RS 4 برای کلاینت‌های MQTT v5، این امکان وجود دارد که سرور یک مقدار "server keepalive" ارسال کند که مقدار نگه‌داری اتصال تنظیم‌شده توسط کلاینت را بازنویسی کند\&. این در نظر گرفته شده است تا به عنوان مکانیزمی استفاده شود که بگوید سرور کلاینت را زودتر از آنچه پیش‌بینی کرده بود قطع خواهد کرد و کلاینت باید از مقدار جدید keepalive استفاده کند\&. گزینه max_keepalive به شما امکان می‌دهد مشخص کنید کلاینت‌ها فقط می‌توانند با مقدار keepalive کمتر یا مساوی این مقدار متصل شوند، در غیر این صورت یک server keepalive برای آنها ارسال می‌شود که به آنها می‌گوید از max_keepalive استفاده کنند\&. این فقط برای کلاینت‌های MQTT v5 اعمال می‌شود\&. حداکثر مقدار 65535 است\&. برای مجاز کردن keepalive بی‌نهایت روی 0 تنظیم کنید\&. پیش‌فرض 0 است\&. .sp تنظیم روی 0 به کلاینت‌ها اجازه می‌دهد keepalive = 0 را تنظیم کنند، به این معنی که هیچ بررسی keepalive انجام نمی‌شود و در صورت عدم دریافت پیام، کلاینت هرگز توسط کارگزار قطع نخواهد شد\&. باید کاملاً مطمئن باشید که این همان رفتاری است که می‌خواهید\&. .sp برای کلاینت‌های MQTT v3\&.1\&.1 و v3\&.1، هیچ مکانیزمی برای گفتن به کلاینت در مورد اینکه از چه مقدار keepalive باید استفاده کند وجود ندارد\&. اگر یک کلاینت MQTT v3\&.1\&.1 یا v3\&.1 زمان نگه‌داری اتصال بیشتری از max_keepalive مشخص کند، یک پیام CONNACK با کد دلیل "identifier rejected" برای آن ارسال شده و اتصال قطع می‌شود\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBmax_packet_size\fR \fIمقدار\fR .RS 4 برای کلاینت‌های MQTT v5، این امکان وجود دارد که سرور یک مقدار "maximum packet size" ارسال کند که به کلاینت دستور می‌دهد بسته‌های MQTT با اندازه بزرگتر از \fBvalue\fR بایت را نمی‌پذیرد\&. این امر برای کل بسته MQTT اعمال می‌شود، نه فقط بدنه داده (payload)\&. تنظیم این گزینه روی یک مقدار مثبت، حداکثر اندازه بسته را روی آن تعداد بایت تنظیم می‌کند\&. اگر کلاینتی بسته‌ای ارسال کند که بزرگتر از این مقدار باشد، ارتباط آن قطع خواهد شد\&. این امر برای همه کلاینت‌ها بدون در نظر گرفتن نسخه پروتکلی که استفاده می‌کنند اعمال می‌شود، اما کلاینت‌های v3\&.1\&.1 و نسخه‌های قبل‌تر مسلماً اطلاعات حداکثر اندازه بسته را دریافت نکرده‌اند\&. .sp از نسخه 2\&.1 به بعد پیش‌فرض 2000000 بایت است\&. نسخه‌های قبل‌تر به طور پیش‌فرض بدون محدودیت بودند\&. .sp این گزینه برای همه کلاینت‌ها اعمال می‌شود، نه فقط کلاینت‌هایی که از MQTT v5 استفاده می‌کنند، اما اطلاع‌رسانی محدودیت به کلاینت‌هایی که از MQTT v3\&.1\&.1 یا MQTT v3\&.1 استفاده می‌کنند امکان‌پذیر نیست\&. .sp تنظیم زیر 20 بایت ممنوع است زیرا حتی با محموله‌های کوچک نیز احتمالاً در عملکرد عادی کلاینت اختلال ایجاد می‌کند\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBmax_queued_bytes\fR \fIتعداد\fR .RS 4 تعداد بایت‌های پیام‌های خروجی QoS 1 و 2 فراتر از پیام‌هایی که در حال حاضر در جریان هستند، توسط کارگزار (به ازای هر کلاینت) صف‌بندی می‌شوند\&. هنگامی که این محدودیت پر شود، پیام‌های بعدی بدون اعلام حذف خواهند شد (silently dropped)\&. این گزینه مهمی است اگر پیام‌ها را با نرخ بالایی ارسال می‌کنید و/یا کلاینت‌هایی دارید که دیر پاسخ می‌دهند یا ممکن است برای مدت طولانی آفلاین باشند\&. پیش‌فرض 0 است (بدون محدودیت)\&. .sp گزینه \fBmax_queued_messages\fR را نیز ببینید\&. اگر هر دو گزینه max_queued_messages و max_queued_bytes مشخص شوند، بسته‌ها تا زمانی که به اولین محدودیت برسند صف‌بندی می‌شوند\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBmax_queued_messages\fR \fIتعداد\fR .RS 4 حداکثر تعداد پیام‌های QoS 1 یا 2 برای نگه‌داری در صف (به ازای هر کلاینت) علاوه بر پیام‌هایی که در حال حاضر در جریان هستند\&. پیش‌فرض 1000 است\&. برای عدم محدودیت روی 0 تنظیم کنید (توصیه نمی‌شود)\&. گزینه‌های \fBqueue_qos0_messages\fR و \fBmax_queued_bytes\fR را نیز ببینید\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBmemory_limit\fR \fIمحدودیت\fR .RS 4 این گزینه حداکثر تعداد بایت‌های حافظه هیپ (heap) را که کارگزار تخصیص می‌دهد تنظیم می‌کند و بنابراین یک محدودیت سخت‌گیرانه برای استفاده از حافظه توسط کارگزار تعیین می‌نماید\&. درخواست‌های حافظه که بیش از این مقدار باشند رد خواهند شد\&. تأثیر بسته به آنچه رد شده است متفاوت خواهد بود\&. اگر یک پیام ورودی در حال پردازش باشد، پیام حذف شده و کلاینت منتشرکننده قطع خواهد شد\&. اگر یک پیام خروجی در حال ارسال باشد، پیام منفرد حذف شده و کلاینت دریافت‌کننده قطع خواهد شد\&. پیش‌فرض بدون محدودیت است\&. .sp این گزینه تنها در صورتی در دسترس است که پشتیبانی از ردیابی حافظه به صورت کامپایل‌شده وجود داشته باشد\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. تنظیم روی مقدار کمتر و بارگذاری مجدد منجر به آزادسازی حافظه نخواهد شد\&. .RE .PP \fBmessage_size_limit\fR \fIمحدودیت\fR .RS 4 این گزینه حداکثر اندازه بدنه داده پیام انتشاری (publish payload) را که کارگزار مجاز می‌داند تنظیم می‌کند\&. پیام‌های دریافتی که بیش از این اندازه باشند توسط کارگزار پذیرفته نخواهند شد\&. این بدان معنی است که پیام برای کلاینت‌های مشترک ارسال نخواهد شد، اما جریان QoS برای پیام‌های QoS 1 یا QoS 2 تکمیل خواهد شد\&. کلاینت‌های MQTT v5 که از QoS 1 یا QoS 2 استفاده می‌کنند، یک PUBACK یا PUBREC با کد دلیل "implementation specific error" دریافت خواهند کرد\&. .sp مقدار پیش‌فرض 0 است، به این معنی که تمام پیام‌های معتبر MQTT پذیرفته می‌شوند\&. پروتکل MQTT حداکثر اندازه محموله 268435455 بایت را تحمیل می‌کند\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBpassword_file\fR \fIمسیر فایل\fR .RS 4 \fIنکته:\fR پیشنهاد می‌شود به جای این گزینه از افزونه \fBmosquitto_password_file\fR استفاده کنید\&. استفاده از افزونه‌ها برای احراز هویت و اعطای مجوز امکان کنترل بیشتری بر روی اعمال آن‌ها به شنوندگان مختلف، بدون نیاز به گزینه منسوخ‌شده \fBper_listener_settings\fR فراهم می‌کند\&. .sp مسیر فایل گذرواژه را تعیین می‌کند\&. در صورت تعریف، محتویات فایل برای کنترل دسترسی کلاینت به کارگزار استفاده می‌شود\&. این فایل را می‌توان با استفاده از ابزار \fBmosquitto_passwd\fR(1) ایجاد کرد\&. اگر mosquitto بدون پشتیبانی TLS کامپایل شده باشد (توصیه می‌شود پشتیبانی TLS گنجانده شود)، فایل گذرواژه باید یک فایل متنی باشد که هر خط آن در قالب "username:password" است، که در آن دونقطه و گذرواژه اختیاری اما توصیه شده است\&. اگر \fBallow_anonymous\fR روی \fIfalse\fR تنظیم شود، فقط کاربرانی که در این فایل تعریف شده‌اند قادر به اتصال خواهند بود\&. تنظیم \fBallow_anonymous\fR روی \fItrue\fR در صورت تعریف \fIpassword_file\fR معتبر است و می‌تواند همراه با acl_file برای داشتن مثلاً حساب‌های مهمان/ناشناس فقط‌خواندنی و کاربران تعریف‌شده‌ای که می‌توانند پیام منتشر کنند، استفاده شود\&. .sp اگر \fBper_listener_settings\fR برابر \fItrue\fR باشد، این گزینه تنها به شنونده فعلی که در حال پیکربندی است اعمال خواهد شد\&. اگر \fBper_listener_settings\fR برابر \fIfalse\fR باشد، این گزینه برای همه شنوندگان اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. داده‌های نام کاربری و گذرواژه که در حال حاضر بارگذاری شده‌اند آزاد شده و دوباره بارگذاری خواهند شد\&. کلاینت‌هایی که قبلاً متصل شده‌اند تحت تأثیر قرار نخواهند گرفت\&. .sp همچنین ببینید: \fBmosquitto_passwd\fR(1) و \m[blue]\fB\%https://mosquitto.org/documentation/dynamic-security/\fR\m[] .RE .PP \fBper_listener_settings\fR [ true | false ] .RS 4 اگر \fItrue\fR باشد، تنظیمات احراز هویت و کنترل دسترسی به ازای هر شنونده کنترل می‌شود\&. گزینه‌های زیر تحت تأثیر قرار می‌گیرند: .sp \fBpassword_file\fR، \fBacl_file\fR، \fBpsk_file\fR، \fBallow_anonymous\fR، \fBallow_zero_length_clientid\fR، \fBauto_id_prefix\fR\&. \fBplugin\fR، \fBplugin_opt_*\fR، توجه داشته باشید که اگر روی true تنظیم شود، یک کلاینت پایدار (یعنی با تنظیم clean session روی false) که قطع شده است، از تنظیمات ACL تعریف‌شده برای شنونده‌ای استفاده می‌کند که اخیراً به آن متصل بوده است\&. .sp رفتار پیش‌فرض برای این گزینه \fIfalse\fR است که رفتار تنظیمات نسخه‌های قبلی mosquitto را حفظ می‌کند\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBpersistence\fR [ true | false ] .RS 4 اگر \fItrue\fR باشد، پایداری (persistence) توکار فعال می‌شود\&. توصیه می‌شود به جای آن از پایداری مبتنی بر افزونه استفاده شود\&. .sp در صورت فعال بودن، داده‌های اتصال، اشتراک و پیام در mosquitto\&.db در مکانی که توسط persistence_location تعیین شده است، روی دیسک نوشته می‌شود\&. وقتی mosquitto راه‌اندازی مجدد شود، اطلاعات ذخیره‌شده در mosquitto\&.db را دوباره بارگذاری می‌کند\&. داده‌ها هنگام بسته شدن mosquitto و همچنین در فواصل زمانی مشخص‌شده توسط autosave_interval روی دیسک نوشته می‌شوند\&. نوشتن پایگاه داده پایداری را نیز می‌توان با ارسال سیگنال SIGUSR1 به mosquitto اجبار کرد\&. اگر \fIfalse\fR باشد، داده‌ها فقط در حافظه ذخیره می‌شوند\&. پیش‌فرض \fIfalse\fR است\&. .sp فایل پایداری ممکن است قالب خود را در یک نسخه جدید تغییر دهد\&. کارگزار در حال حاضر می‌تواند تمام قالب‌های قدیمی را بخواند، اما فقط در آخرین قالب ذخیره می‌کند\&. ارتقا باید همیشه امن باشد، اما کاربران محتاط ممکن است مایل باشند قبل از نصب نسخه جدید یک کپی از فایل پایداری تهیه کنند تا در صورت لزوم بتوانند به نسخه قبلی بازگردند\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBpersistence_file\fR \fIنام فایل\fR .RS 4 نام فایلی که برای پایگاه داده ماندگار توکار استفاده می‌شود\&. پیش‌فرض mosquitto\&.db است\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBpersistence_location\fR \fIمسیر\fR .RS 4 مسیری که افزونه‌ها باید هر گونه داده پایداری را در آن ذخیره کنند، و مسیری که پایداری توکار داده‌های خود را در آن ذخیره خواهد کرد\&. اگر داده نشود، از دایرکتوری فعلی استفاده می‌شود\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBpersistent_client_expiration\fR \fIمدت زمان\fR .RS 4 این گزینه به نشست کلاینت‌های ماندگار (آن‌هایی که clean session روی false تنظیم شده است) \fIکه در حال حاضر متصل نیستند\fR اجازه می‌دهد در صورتی که در یک بازه زمانی معین مجدداً متصل نشوند، حذف شوند\&. این یک گزینه غیر استاندارد در MQTT v3\&.1 است\&. نسخه‌های MQTT v3\&.1\&.1 و v5\&.0 به کارگزاران اجازه می‌دهند نشست‌های کلاینت را حذف کنند\&. .sp کلاینت‌هایی با طراحی ضعیف ممکن است clean session را روی false قرار دهند در حالی که از شناسه کلاینت تولیدشده به صورت تصادفی استفاده می‌کنند\&. این منجر به کلاینت‌های ماندگاری می‌شود که یک بار متصل می‌شوند و هرگز دوباره متصل نمی‌شوند\&. این گزینه اجازه می‌دهد این کلاینت‌ها حذف شوند\&. .sp دوره انقضا باید یک عدد صحیح باشد و به دنبال آن یکی از حروف s h d w m y به ترتیب برای ثانیه، ساعت، روز، هفته، ماه و سال بیاید\&. برای مثال: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} persistent_client_expiration 2m .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} persistent_client_expiration 14d .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} persistent_client_expiration 1y .RE .sp اگرچه امکان تعیین زمان انقضا بر حسب ثانیه وجود دارد، این به این معنی نیست که باید از یک بازه انقضای کوتاه استفاده کنید\&. اگر سیستمی دارید که فکر می‌کنید کلاینت‌ها باید به طور خودکار در مدت زمان کوتاهی منقضی شوند، در صورت امکان باید مشکل کلاینت‌ها را برطرف کنید\&. .sp از آنجا که این یک گزینه غیر استاندارد است، مقدار پیش‌فرض در صورت عدم تنظیم این است که هرگز کلاینت‌های ماندگار منقضی نشوند\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBpid_file\fR \fIمسیر فایل\fR .RS 4 یک فایل pid در فایل مشخص‌شده می‌نویسد\&. اگر داده نشود (پیش‌فرض)، هیچ فایل pid نوشته نخواهد شد\&. اگر فایل pid قابل نوشتن نباشد، mosquitto خارج خواهد شد\&. .sp اگر mosquitto به طور خودکار توسط یک اسکریپت init راه‌اندازی می‌شود معمولاً نوشتن یک فایل pid الزامی خواهد بود\&. سپس این باید به عنوان مثال /var/run/mosquitto/mosquitto\&.pid پیکربندی شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBplugin_opt_*\fR \fIمقدار\fR .RS 4 گزینه‌هایی که باید به جدیدترین \fBplugin\fR تعریف‌شده در فایل پیکربندی منتقل شوند\&. برای جزئیات گزینه‌های موجود، دستورالعمل‌های خاص افزونه را ببینید\&. .sp برای افزونه/global_plugin فعلی که در حال پیکربندی است اعمال می‌شود\&. .sp این همچنین به عنوان گزینه \fBauth_opt_*\fR نیز در دسترس است، اما این استفاده منسوخ شده و در نسخه آینده حذف خواهد شد\&. .RE .PP \fBplugin\fR \fIمسیر فایل\fR .RS 4 یک ماژول خارجی را برای استفاده در احراز هویت، کنترل دسترسی و سایر ویژگی‌ها مشخص می‌کند\&. این اجازه می‌دهد توابع نام کاربری/گذرواژه و کنترل دسترسی سفارشی ایجاد شده و رفتارهای دیگر اصلاح شوند\&. .sp می‌توان چندین بار برای بارگذاری چندین افزونه مشخص کرد\&. افزونه‌ها به ترتیبی که مشخص شده‌اند پردازش می‌شوند\&. .sp اگر \fBpassword_file\fR یا \fBacl_file\fR در فایل پیکربندی در کنار \fBplugin\fR استفاده شوند، بررسی‌های افزونه قبل از بررسی‌های توکار اجرا می‌شوند\&. .sp در حال حاضر با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .sp اگر \fBper_listener_settings\fR روی \fItrue\fR تنظیم شده باشد، این افزونه فقط برای شنونده فعلی بارگذاری خواهد شد\&. .sp همچنین ببینید: \m[blue]\fB\%https://mosquitto.org/documentation/dynamic-security/\fR\m[] و گزینه \fBglobal_plugin\fR\&. .sp این همچنین به عنوان گزینه \fBauth_plugin\fR نیز در دسترس است، اما این استفاده منسوخ شده و در نسخه آینده حذف خواهد شد\&. .RE .PP \fBpsk_file\fR \fIمسیر فایل\fR .RS 4 مسیر یک فایل کلید از پیش اشتراک‌گذاری‌شده (PSK) را تنظیم می‌کند\&. این گزینه نیازمند این است که یک شنونده پشتیبانی PSK را فعال کرده باشد\&. در صورت تعریف، محتویات فایل برای کنترل دسترسی کلاینت به کارگزار استفاده می‌شود\&. هر خط باید در قالب "identity:key" باشد، که در آن کلید یک رشته هگزادسیمال بدون "0x" در ابتدا است\&. کلاینتی که به شنونده‌ای با پشتیبانی PSK فعال متصل می‌شود، باید یک هویت و PSK منطبق ارائه دهد تا اتصال رمزگذاری‌شده ادامه یابد\&. .sp اگر \fBper_listener_settings\fR برابر \fItrue\fR باشد، این گزینه تنها به شنونده فعلی که در حال پیکربندی است اعمال می‌شود\&. اگر \fBper_listener_settings\fR برابر \fIfalse\fR باشد، این گزینه برای همه شنوندگان اعمال خواهد شد\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. داده‌های هویت و کلید که در حال حاضر بارگذاری شده‌اند آزاد شده و دوباره بارگذاری خواهند شد\&. کلاینت‌هایی که قبلاً متصل شده‌اند تحت تأثیر قرار نخواهند گرفت\&. .RE .PP \fBqueue_qos0_messages\fR [ true | false ] .RS 4 روی \fItrue\fR تنظیم کنید تا هنگام قطع اتصال کلاینت ماندگار، پیام‌های با سطح QoS 0 در صف قرار گیرند\&. هنگامی که موضوعات پل با سطح QoS 1 یا 2 پیکربندی می‌شوند، پیام‌های ورودی QoS 0 برای این موضوعات نیز در صف قرار می‌گیرند\&. این پیام‌ها در محدودیت تحمیل‌شده توسط max_queued_messages گنجانده می‌شوند\&. پیش‌فرض \fIfalse\fR است\&. .sp توجه داشته باشید که مشخصات MQTT v3\&.1\&.1 بیان می‌کند که فقط پیام‌های QoS 1 و 2 باید در این وضعیت ذخیره شوند، بنابراین این یک گزینه غیر استاندارد است\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBretain_available\fR [ true | false ] .RS 4 اگر روی false تنظیم شود، پیام‌های نگه‌داشته‌شده (retained) پشتیبانی نمی‌شوند\&. اگر این گزینه روی false تنظیم شده باشد، کلاینت‌هایی که پیامی با بیت retain ارسال می‌کنند قطع خواهند شد\&. پیش‌فرض true است\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBretain_expiry_interval\fR \fIدقیقه\fR .RS 4 رفتار پیش‌فرض mosquitto حذف پیام‌های نگه‌داشته‌شده‌ای است که در دسترسی بعدی به ویژگی message\-expiry\-interval خود رسیده‌اند \- چه با جایگزین شدن با یک پیام جدید، یا در اشتراک بعدی که با پیام مطابقت دارد\&. اگر الگویی برای انتشار پیام‌های نگه‌داشته‌شده متعدد با message\-expiry\-interval دارید اما در آن‌ها مشترک نمی‌شوید، پیام‌های نگه‌داشته‌شده منقضی‌شده در حافظه باقی می‌مانند\&. این گزینه کارگزار را پیکربندی می‌کند تا به طور دوره‌ای درخت پیام‌های نگه‌داشته‌شده را برای پیام‌های منقضی‌شده بررسی کند\&. .sp پیش‌فرض خاموش (off) است\&. تنظیم روی مقداری بزرگتر از صفر به این معنی است که کارگزار در بازه زمانی آن تعداد دقیقه بررسی را انجام خواهد داد\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBset_tcp_nodelay\fR [ true | false ] .RS 4 اگر روی true تنظیم شود، گزینه TCP_NODELAY روی سوکت‌های کلاینت تنظیم می‌شود تا الگوریتم Nagle غیرفعال شود\&. این کار باعث کاهش تأخیر برخی پیام‌ها با احتمال افزایش تعداد بسته‌های TCP ارسالی می‌شود\&. پیش‌فرض false است\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBsys_interval\fR \fIثانیه\fR .RS 4 تعداد ثانیه‌های صحیح بین به‌روزرسانی‌های سلسله‌مراتب اشتراک $SYS که اطلاعات وضعیت کارگزار را ارائه می‌دهد\&. اگر تنظیم نشود، پیش‌فرض 10 ثانیه است\&. .sp برای غیرفعال کردن کامل انتشار سلسله‌مراتب $SYS روی 0 تنظیم کنید\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBupgrade_outgoing_qos\fR [ true | false ] .RS 4 مشخصات MQTT ایجاب می‌کند که QoS پیامی که به یک مشترک تحویل داده می‌شود هرگز برای تطابق با QoS اشتراک ارتقا نیابد\&. فعال کردن این گزینه این رفتار را تغییر می‌دهد\&. اگر \fBupgrade_outgoing_qos\fR روی \fItrue\fR تنظیم شود، پیام‌های ارسالی به یک مشترک همیشه با QoS اشتراک آن مطابقت خواهد داشت\&. این یک گزینه غیر استاندارد است که در مشخصات پیش‌بینی نشده است\&. پیش‌فرض \fIfalse\fR است\&. .sp این گزینه به صورت سراسری اعمال می‌شود\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBuser\fR \fIنام کاربری\fR .RS 4 هنگام اجرا به عنوان کاربر ریشه (root)، در زمان راه‌اندازی به این کاربر و گروه اصلی آن تغییر می‌یابد\&. اگر روی "mosquitto" تنظیم شود یا تنظیم نشده رها شود، و اگر کاربر "mosquitto" وجود نداشته باشد، mosquitto به جای آن به کاربر "nobody" تغییر می‌یابد\&. اگر این روی مقدار دیگری تنظیم شود و mosquitto نتواند به این کاربر و گروه تغییر کند، با خطا خارج می‌شود\&. کاربر مشخص‌شده باید دسترسی خواندن/نوشتن به پایگاه داده پایداری داشته باشد اگر قرار است نوشته شود\&. اگر به عنوان یک کاربر غیر ریشه اجرا شود، این تنظیم هیچ تأثیری ندارد\&. پیش‌فرض mosquitto است\&. .sp این تنظیم روی ویندوز هیچ تأثیری ندارد و بنابراین باید mosquitto را به عنوان کاربری که می‌خواهید اجرا شود، اجرا کنید\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .SH "شنوندگان (LISTENERS)" .PP درگاه‌های شبکه‌ای که mosquitto روی آن‌ها گوش می‌دهد را می‌توان با استفاده از شنوندگان (listeners) کنترل کرد\&. گزینه‌های پیش‌فرض شنونده را می‌توان بازنویسی کرد و شنوندگان بیشتری ایجاد نمود\&. .SS "گزینه‌های عمومی (General Options)" .PP \fBaccept_protocol_versions\fR \fIنسخه‌ها\fR .RS 4 نسخه‌های پروتکل پذیرفته‌شده\&. این مشخص می‌کند چه نسخه‌هایی از پروتکل MQTT روی این شنونده پذیرفته می‌شوند\&. می‌تواند هر ترکیبی از 3، 4، 5 در یک لیست جدا شده با ویرگول باشد، مثلاً: .sp .if n \{\ .RS 4 .\} .nf # فقط نسخه v5\&.0 مجاز است: listener 1883 accept_protocol_versions 5 # نسخه‌های v3\&.1 و v3\&.1\&.1 مجاز هستند: listener 1884 accept_protocol_versions 3, 4 .fi .if n \{\ .RE .\} .sp پیش‌فرض اجازه دادن به همه نسخه‌ها است\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .RE .PP \fBbind_address\fR \fIآدرس\fR .RS 4 این گزینه منسوخ شده است و در نسخه آینده حذف خواهد شد\&. به جای آن از \fBlistener\fR استفاده کنید\&. .sp تنها به اتصالات شبکه ورودی روی آدرس IP/نام میزبان مشخص‌شده گوش می‌دهد\&. این برای محدود کردن دسترسی به برخی رابط‌های شبکه مفید است\&. برای محدود کردن دسترسی به mosquitto فقط به میزبان محلی، از "bind_address localhost" استفاده کنید\&. این فقط برای شنونده پیش‌فرض اعمال می‌شود\&. از گزینه \fBlistener\fR برای کنترل سایر شنوندگان استفاده کنید\&. .sp توصیه می‌شود به جای اتکا به گزینه‌های پیش‌فرض ضمنی شنونده مانند این، از یک \fBlistener\fR صریح استفاده کنید\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBbind_interface\fR \fIدستگاه\fR .RS 4 تنها روی رابط شبکه مشخص‌شده به اتصالات شبکه ورودی گوش می‌دهد\&. این شبیه به گزینه \fBbind_address\fR است اما زمانی مفید است که یک رابط دارای چندین آدرس باشد یا آدرس ممکن است تغییر کند\&. .sp اگر همزمان با \fBbind_address\fR برای شنونده پیش‌فرض یا بخش \fIbind address/host\fR از \fBlistener\fR استفاده شود، آنگاه \fBbind_interface\fR اولویت خواهد داشت\&. .sp این گزینه در ویندوز و AIX در دسترس نیست\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBenable_proxy_protocol\fR [ 2 | 1 ] .RS 4 پشتیبانی از پروتکل PROXY را برای این شنونده فعال می‌کند\&. نسخه‌های 1 و 2 پشتیبانی می‌شوند؛ اگر حق انتخاب دارید، نسخه 2 توصیه می‌شود زیرا به شما امکان دسترسی به اطلاعات TLS را می‌دهد و از سوکت‌های یونیکس پشتیبانی می‌کند\&. .sp این گزینه مستلزم استفاده از یک متعادل‌کننده بار/پروکسی مانند HAProxy در جلوی Mosquitto است، به‌طوری‌که پروکسی برای استفاده از پروتکل PROXY پیکربندی شده باشد\&. .sp پروتکل PROXY برای ارسال اطلاعات مربوط به اتصالات سوکت کلاینت از پروکسی به کارگزار استفاده می‌شود\&. بدون این، اطلاعات اتصال و لاگ‌ها در کارگزار شامل آدرس IP و درگاه خود پروکسی خواهد بود، نه کلاینت\&. .sp فعال کردن این گزینه فقط باید زمانی انجام شود که یک پروکسی قابل اعتماد در جلوی Mosquitto قرار داده شده باشد و هیچ دسترسی خارجی دیگری به Mosquitto امکان‌پذیر نباشد\&. دادن دسترسی خارجی به شنونده‌ای با این گزینه فعال، یک ریسک امنیتی است، به ویژه اگر از گواهی‌های کلاینت روی پروکسی استفاده می‌کنید\&. .sp هنگام استفاده از PROXY نسخه 2، این گزینه می‌تواند با خاتمه TLS (TLS termination) روی پروکسی استفاده شود\&. در این حالت، اطلاعات TLS نیز به کارگزار منتقل خواهد شد\&. از \fBproxy_protocol_v2_require_tls\fR برای رد کلاینت‌هایی که از TLS استفاده نمی‌کنند استفاده کنید \- این به شدت توصیه می‌شود\&. فعال کردن \fBrequire_certificate\fR روی شنونده باعث می‌شود کارگزار اطلاعات TLS ارائه‌شده را بررسی کند تا اطمینان حاصل شود که کلاینت یک گواهی معتبر ارائه داده است\&. فعال کردن \fBuse_identity_as_username\fR نیز باعث می‌شود مقدار \fIcommonName\fR از گواهی به جای نام کاربری ارائه‌شده در بسته CONNECT به عنوان نام کاربری کلاینت استفاده شود\&. در هر دو حالت، شنونده نباید دارای TLS پیکربندی‌شده باشد\&. .sp امکان استفاده از گزینه‌های \fBuse_subject_as_username\fR، \fBcertfile\fR، یا \fBkeyfile\fR در ترکیب با \fBenable_proxy_protocol\fR وجود ندارد\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBhttp_dir\fR \fIپوشه\fR .RS 4 هنگامی که یک شنونده از پروتکل http_api استفاده می‌کند، امکان ارائه داده‌های http نیز وجود دارد\&. \fBhttp_dir\fR را روی دایرکتوری‌ای که حاوی فایل‌هایی است که می‌خواهید ارائه دهید تنظیم کنید\&. اگر این گزینه مشخص نشده باشد، هیچ اتصال معمولی http امکان‌پذیر نخواهد بود\&. .sp این گزینه همچنین برای شنوندگان وب‌سوکت در صورتی که Mosquitto با پشتیبانی از وب‌سوکت ارائه‌شده توسط libwebsockets کامپایل شده باشد در دسترس است\&. این پیش‌فرض نیست و در نسخه 3\&.0 حذف خواهد شد\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBlistener\fR \fIدرگاه\fR \fI[آدرس bind/میزبان/مسیر سوکت یونیکس]\fR .RS 4 روی درگاه مشخص‌شده به اتصال شبکه ورودی گوش می‌دهد\&. یک آرگومان اختیاری دوم به شنونده اجازه می‌دهد تا به یک آدرس IP/نام میزبان خاص متصل شود\&. اگر از این متغیر استفاده شود و هیچ یک از گزینه‌های سراسری \fBbind_address\fR یا \fBport\fR استفاده نشوند، شنونده پیش‌فرض راه‌اندازی نخواهد شد\&. .sp گزینه \fBbind address/host\fR به این شنونده اجازه می‌دهد تا با ارسال یک آدرس IP یا نام میزبان به یک آدرس IP خاص متصل شود\&. برای شنوندگان وب‌سوکت، تنها امکان ارسال یک آدرس IP در اینجا وجود دارد\&. .sp در سیستم‌هایی که از Unix Domain Sockets پشتیبانی می‌کنند، این گزینه همچنین می‌تواند برای ایجاد یک سوکت یونیکس به جای باز کردن سوکت TCP استفاده شود\&. در این حالت، درگاه باید روی 0 تنظیم شود و مسیر سوکت یونیکس باید داده شود\&. .sp این گزینه می‌تواند چندین بار مشخص شود\&. گزینه \fBmount_point\fR را نیز ببینید\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBlistener_allow_anonymous\fR [ true | false ] .RS 4 مقدار بولی که تعیین می‌کند آیا کلاینت‌هایی که بدون ارائه نام کاربری متصل می‌شوند مجاز به اتصال به این شنونده خاص هستند یا خیر\&. در صورت تنظیم، این مقدار تنظیم‌شده توسط \fBallow_anonymous\fR را بازنویسی می‌کند\&. اگر روی \fIfalse\fR تنظیم شود، باید روش اتصال دیگری برای کنترل دسترسی کلاینت احراز هویت‌شده ایجاد شود\&. .sp اگر به صراحت تنظیم نشود، از مقدار \fBallow_anonymous\fR استفاده خواهد شد\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBauto_id_prefix\fR \fIپیشوند\fR .RS 4 این گزینه به شما امکان می‌دهد رشته‌ای را تنظیم کنید که به ابتدای شناسه‌های کلاینت ایجادشده به صورت خودکار (یعنی زمانی که یک کلاینت بدون ارائه شناسه کلاینت متصل می‌شود) اضافه شود تا دیده‌شدن در لاگ‌ها آسان‌تر شود\&. پیش‌فرض \fBauto\-\fR است\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBmax_connections\fR \fIتعداد\fR .RS 4 تعداد کل کلاینت‌های متصل برای شنونده فعلی را محدود می‌کند\&. برای داشتن اتصالات "نامحدود" روی \-1 تنظیم کنید\&. توجه داشته باشید که ممکن است محدودیت‌های دیگری خارج از کنترل mosquitto اعمال شود\&. به عنوان مثال \fBlimits.conf\fR() را ببینید\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBmax_qos\fR \fIمقدار\fR .RS 4 مقدار QoS مجاز برای کلاینت‌های متصل به این شنونده را محدود می‌کند\&. پیش‌فرض 2 است، به این معنی که از هر QoS می‌توان استفاده کرد\&. برای محدود کردن به آن مقادیر QoS روی 0 یا 1 تنظیم کنید\&. این از ویژگی MQTT v5 برای اطلاع‌رسانی محدودیت به کلاینت‌ها استفاده می‌کند\&. کلاینت‌های MQTT v3\&.1\&.1 از این محدودیت آگاه نخواهند بود\&. کلاینت‌هایی که با یک QoS بیش از حد بالا در این شنونده پیام منتشر می‌کنند قطع خواهند شد\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBmax_topic_alias_broker\fR \fIعدد\fR .RS 4 هنگام انتشار به کلاینت‌های MQTT v5، نرم‌افزار Mosquitto می‌تواند نام‌های مستعار موضوع (topic aliases) را بر اساس اولویت ورود ایجاد کند، یعنی موضوعاتی که ابتدا به یک کلاینت منتشر می‌شوند دارای نام مستعار می‌شوند\&. این گزینه تعداد نام‌های مستعار را به ازای هر کلاینت کنترل می‌کند\&. این گزینه به ازای هر شنونده اعمال می‌شود\&. .sp توجه داشته باشید که این رفتار تضمین نمی‌شود که یکسان باقی بماند\&. ممکن است نسخه‌های آینده مکانیزم‌هایی را برای کنترل اینکه کدام موضوعات نام مستعار دریافت می‌کنند معرفی کنند\&. .sp این گزینه حداکثر تعداد نام‌های مستعار موضوع را که Mosquitto برای یک کلاینت MQTT v5 ایجاد می‌کند تنظیم می‌کند، حتی اگر کلاینت تعداد بیشتری را مجاز بداند\&. .sp برای مثال، اگر کلاینت topic\-alias\-maximum را روی 100 تنظیم کند و این گزینه روی 10 تنظیم شود، کارگزار حداکثر 10 نام مستعار موضوع ایجاد خواهد کرد\&. به همین ترتیب، اگر کلاینت topic\-alias\-maximum را روی 20 تنظیم کند و این گزینه روی 100 تنظیم شود، کارگزار حداکثر 20 نام مستعار موضوع ایجاد خواهد کرد\&. .sp پیش‌فرض 10 است\&. حداکثر 65535\&. برای غیرفعال کردن کامل نام‌های مستعار موضوع از کارگزار به کلاینت روی 0 تنظیم کنید\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBmax_topic_alias\fR \fIعدد\fR .RS 4 این گزینه حداکثر تعداد نام‌های مستعار موضوع را که یک کلاینت MQTT v5 مجاز به ایجاد آن است تنظیم می‌کند\&. این گزینه به ازای هر شنونده اعمال می‌شود\&. پیش‌فرض 10 است\&. برای عدم پذیرش نام‌های مستعار موضوع از سوی کلاینت‌ها روی 0 تنظیم کنید\&. حداکثر مقدار ممکن 65535 است\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBmount_point\fR \fIپیشوند موضوع\fR .RS 4 این گزینه با گزینه listener برای جداسازی گروه‌هایی از کلاینت‌ها استفاده می‌شود\&. هنگامی که یک کلاینت به شنونده‌ای متصل می‌شود که از این گزینه استفاده می‌کند، آرگومان رشته‌ای به ابتدای تمام موضوعات برای این کلاینت متصل می‌شود\&. این پیشوند زمانی که هر پیامی به کلاینت ارسال می‌شود حذف می‌گردد\&. این بدان معنی است که کلاینت متصل به شنونده‌ای با نقطه اتصال (mount point) \fIexample\fR تنها می‌تواند پیام‌هایی را ببیند که در سلسله‌مراتب موضوع \fIexample\fR و زیرمجموعه‌های آن منتشر شده‌اند\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBport\fR \fIشماره درگاه\fR .RS 4 این گزینه منسوخ شده است و در نسخه آینده حذف خواهد شد\&. به جای آن از \fBlistener\fR استفاده کنید\&. .sp درگاه شبکه را برای شنونده پیش‌فرض جهت گوش دادن تنظیم می‌کند\&. پیش‌فرض 1883 است\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .sp توصیه می‌شود به جای اتکا به گزینه‌های پیش‌فرض ضمنی شنونده مانند این، از یک \fBlistener\fR صریح استفاده کنید\&. .RE .PP \fBprotocol\fR \fIمقدار\fR .RS 4 پروتکل پذیرش را برای شنونده فعلی تنظیم می‌کند\&. می‌تواند \fBmqtt\fR (پیش‌فرض)، \fBwebsockets\fR، یا \fBhttp_api\fR باشد\&. .sp \fBmqtt\fR: شنونده استاندارد MQTT\&. .sp \fBwebsockets\fR: پروتکل MQTT تونل‌شده روی وب‌سوکت\&. اگر از پشتیبانی قدیمی وب‌سوکت با استفاده از libwebsockets استفاده شود، تنها مجموعه ویژگی‌های کاهش‌یافته TLS در دسترس خواهد بود، یعنی \fBcafile\fR، \fBcertfile\fR، \fBkeyfile\fR، \fBciphers\fR، و \fBciphers_tls1\&.3\fR\&. .sp \fBhttp_api\fR: این شنونده را به عنوان یک وب‌سرور بسیار ساده راه‌اندازی می‌کند (گزینه \fBhttp_dir\fR را ببینید) که می‌تواند به برخی از درخواست‌های HTTP API نیز پاسخ دهد\&. پروتکل TLS برای این شنونده پشتیبانی می‌شود، با این حال فقط گزینه‌های \fBcertfile\fR و \fBkeyfile\fR مجاز هستند\&. احراز هویت در حال حاضر امکان‌پذیر نیست \- برای استفاده از این شنونده اکیداً توصیه می‌شود که شنونده را به رابط loopback متصل کرده و سپس یک پروکسی معکوس با رمزگذاری و احراز هویت مناسب پیکربندی کنید\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBproxy_protocol_v2_require_tls\fR [ true | false ] .RS 4 هنگامی که یک شنونده از پروتکل PROXY استفاده می‌کند، می‌توان از این گزینه برای الزام کلاینت به استفاده از TLS استفاده کرد\&. اگر روی true تنظیم شود، هدر پروتکل PROXY باید حاوی نشانگر TLS باشد\&. اگر نباشد، اتصال بسته خواهد شد\&. پیش‌فرض false است\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBsocket_domain\fR [ ipv4 | ipv6 ] .RS 4 به‌طور پیش‌فرض، یک شنونده تلاش می‌کند روی تمام نسخه‌های پروتکل IP پشتیبانی‌شده گوش دهد\&. اگر رابط IPv4 یا IPv6 ندارید، ممکن است بخواهید پشتیبانی از هر یک از آن نسخه‌های پروتکل را غیرفعال کنید\&. به‌ویژه، توجه داشته باشید که به دلیل محدودیت‌های کتابخانه وب‌سوکت، اگر پشتیبانی IPv6 کامپایل شده باشد تنها تلاش می‌کند سوکت‌های IPv6 را باز کند، و بنابراین اگر IPv6 در دسترس نباشد شکست خواهد خورد\&. .sp برای اجبار شنونده به استفاده انحصاری از IPv4 روی \fBipv4\fR تنظیم کنید، یا برای اجبار به استفاده از IPv6 روی \fBipv6\fR تنظیم نمایید\&. اگر می‌خواهید از هر دو نسخه IPv4 و IPv6 پشتیبانی شود، از گزینه \fBsocket_domain\fR استفاده نکنید\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBuse_username_as_clientid\fR [ true | false ] .RS 4 گزینه \fBuse_username_as_clientid\fR را روی true قرار دهید تا شناسه‌ای که کلاینت با آن متصل شده با نام کاربری آن جایگزین شود\&. این اجازه می‌دهد تا احراز هویت به شناسه کلاینت گره بخورد، به این معنی که می‌توان از قطع اتصال یک کلاینت توسط کلاینت دیگر با استفاده از همان شناسه کلاینت جلوگیری کرد\&. پیش‌فرض false است\&. .sp اگر یک کلاینت بدون نام کاربری متصل شود، هنگامی که این گزینه روی true تنظیم شده باشد به عنوان غیرمجاز قطع خواهد شد\&. در ترکیب با \fBclientid_prefixes\fR استفاده نکنید\&. .sp این به صورت سراسری اعمال نمی‌شود، بلکه به ازای هر شنونده اعمال می‌شود\&. .sp همچنین ببینید: \fBuse_identity_as_username\fR\&. .sp با سیگنال بارگذاری مجدد دوباره بارگذاری نمی‌شود\&. .RE .PP \fBpacket_buffer_size\fR \fIاندازه\fR, \fBwebsockets_headers_size\fR \fIاندازه\fR .RS 4 اندازه بافر استفاده‌شده هنگام خواندن از شبکه را قبل از مشخص شدن اندازه بسته MQTT تغییر می‌دهد\&. پیش‌فرض 4096 است\&. بسته‌های دریافتی که کوچکتر از این مقدار هستند در اصل فقط به یک فراخوانی read() نیاز دارند که خواندن بسته‌ها را کارآمدتر می‌کند\&. .sp این همچنین به عنوان گزینه‌ای عمل می‌کند که اندازه بافر مورداستفاده توسط وب‌سوکت‌ها را هنگام خواندن هدر اولیه تنظیم می‌کند\&. اگر داده‌های هدر بزرگ مانند کوکی‌ها را ارسال می‌کنید، ممکن است لازم باشد این مقدار را افزایش دهید\&. .RE .PP \fBwebsockets_log_level\fR \fIسطح\fR .RS 4 سطح ثبت وقایع وب‌سوکت‌ها را تغییر می‌دهد\&. این یک گزینه سراسری است و امکان تنظیم آن به ازای هر شنونده وجود ندارد\&. این یک عدد صحیح است که توسط libwebsockets به عنوان ماسک بیتی برای شمارشگر lws_log_levels آن تفسیر می‌شود\&. برای جزئیات بیشتر مستندات libwebsockets را ببینید\&. .sp برای استفاده از این گزینه، \fBlog_type websockets\fR نیز باید فعال باشد\&. پیش‌فرض 0 است\&. .RE .PP \fBwebsockets_origin\fR \fIمبدأ\fR .RS 4 در صورت تنظیم، هنگامی که یک اتصال تلاش می‌کند به WebSockets ارتقا یابد، این با هدر مبدأ http مقایسه می‌شود\&. فقط مبداهای منطبق مجاز خواهند بود\&. از رشته دقیقی که توسط مرورگر در هدر مبدأ ارائه شده است استفاده کنید، به عنوان مثال \fIhttp://example\&.com:8080\fR\&. می‌تواند چندین بار برای هر شنونده مشخص شود\&. .sp اگر تنظیم نشود، اتصالات از هر مبدئی مجاز خواهند بود\&. .sp نیازمند libwebsockets نسخه 3\&.1\&.0 یا بالاتر است\&. .RE .SS "پشتیبانی از SSL/TLS مبتنی بر گواهی (Certificate based SSL/TLS Support)" .PP گزینه‌های زیر برای همه شنوندگان جهت پیکربندی پشتیبانی SSL مبتنی بر گواهی در دسترس هستند\&. همچنین بخش «پشتیبانی از SSL/TLS مبتنی بر کلید از پیش اشتراک‌گذاری‌شده» را ببینید\&. .PP \fBcafile\fR \fIمسیر فایل\fR .RS 4 گزینه \fBcafile\fR برای تعریف مسیر فایلی شامل گواهی‌های CA کدگذاری‌شده با PEM استفاده می‌شود که هنگام بررسی گواهی‌های کلاینت ورودی مورد اعتماد هستند\&. .RE .PP \fBcapath\fR \fIمسیر پوشه\fR .RS 4 گزینه \fBcapath\fR برای تعریف دایرکتوری شامل گواهی‌های CA کدگذاری‌شده با PEM استفاده می‌شود که هنگام بررسی گواهی‌های کلاینت ورودی مورد اعتماد هستند\&. برای اینکه \fBcapath\fR به درستی کار کند، فایل‌های گواهی باید پسوند "\&.pem" داشته باشند و شما باید هر بار که گواهی اضافه یا حذف می‌کنید "openssl rehash <مسیر به capath>" را اجرا کنید\&. .sp گزینه \fBcapath\fR برای وب‌سوکت‌ها پشتیبانی نمی‌شود\&. .RE .PP \fBcertfile\fR \fIمسیر فایل\fR .RS 4 مسیر گواهی سرور با کدگذاری PEM\&. این گزینه و \fBkeyfile\fR باید وجود داشته باشند تا رمزگذاری TLS مبتنی بر گواهی فعال شود\&. .sp گواهی مشخص‌شده توسط این گزینه هنگامی که Mosquitto یک سیگنال SIGHUP دریافت کند، دوباره بارگذاری می‌شود\&. این می‌تواند برای بارگذاری گواهی‌های جدید قبل از انقضای گواهی‌های موجود استفاده شود\&. .RE .PP \fBciphers\fR \fIفهرست_رمزها\fR .RS 4 فهرست الگوریتم‌های رمزنگاری (ciphers) مجاز برای این شنونده، فقط برای TLS v1\&.2 و قبل‌تر، که هر کدام با یک دونقطه جدا شده‌اند\&. الگوریتم‌های رمزنگاری موجود را می‌توان با استفاده از دستور "openssl ciphers" به دست آورد\&. .RE .PP \fBciphers_tls1\&.3\fR \fIفهرست_مجموعه‌رمزها\fR .RS 4 فهرست مجموعه‌رمزهای مجاز برای این شنونده برای TLS v1\&.3 که هر کدام با دونقطه جدا شده‌اند\&. .RE .PP \fBcrlfile\fR \fIمسیر فایل\fR .RS 4 اگر \fBrequire_certificate\fR را روی \fItrue\fR تنظیم کرده‌اید، می‌توانید یک فایل فهرست ابطال گواهی (CRL) برای لغو دسترسی به گواهی‌های کلاینت خاص ایجاد کنید\&. اگر این کار را انجام داده‌اید، از crlfile برای اشاره به فایل ابطال با کدگذاری PEM استفاده کنید\&. .RE .PP \fBdhparamfile\fR \fIمسیر فایل\fR .RS 4 برای امکان استفاده از تبادل کلید گذرای دیفی-هلمن (ephemeral DH) که امنیت رو به جلو (forward security) را فراهم می‌کند، شنونده باید پارامترهای DH را بارگذاری کند\&. این را می‌توان با گزینه dhparamfile مشخص کرد\&. فایل dhparamfile را می‌توان به عنوان مثال با این دستور تولید کرد: .sp .if n \{\ .RS 4 .\} .nf openssl dhparam \-out dhparam\&.pem 2048 .fi .if n \{\ .RE .\} .RE .PP \fBdisable_client_cert_date_checks\fR [ true | false ] .RS 4 در صورت تنظیم روی true، گزینه \fBdisable_client_cert_date_checks\fR رفتار اعتبارسنجی گواهی را تغییر می‌دهد تا گواهی‌های کلاینت منقضی‌شده یا گواهی‌هایی را که هنوز معتبر نشده‌اند، هنگام استفاده از \fBrequire_certificate true\fR بپذیرد\&. .sp پیش‌فرض \fBfalse\fR است\&. .RE .PP \fBkeyfile\fR \fIمسیر فایل\fR .RS 4 اگر \fBtls_keyform\fR برابر "pem" باشد، این مسیر کلید خصوصی سرور با کدگذاری PEM است\&. این گزینه و \fBcertfile\fR باید وجود داشته باشند تا رمزگذاری TLS مبتنی بر گواهی فعال شود\&. اگر \fBtls_keyform\fR برابر "engine" باشد، این نشان‌دهنده دستگیره موتور (engine handle) کلید خصوصی است\&. .sp کلید خصوصی اشاره‌شده توسط این گزینه با دریافت سیگنال SIGHUP توسط Mosquitto دوباره بارگذاری می‌شود\&. این می‌تواند برای بارگذاری کلیدهای جدید قبل از انقضای کلیدهای موجود استفاده شود\&. .RE .PP \fBrequire_certificate\fR [ true | false ] .RS 4 به‌طور پیش‌فرض، شنونده‌ای که SSL/TLS روی آن فعال است به روشی مشابه با وب‌سرور دارای https عمل می‌کند، به این صورت که سرور دارای گواهی امضا شده توسط یک CA است و کلاینت تأیید می‌کند که این یک گواهی معتبر است\&. هدف کلی رمزگذاری ترافیک شبکه است\&. با تنظیم \fBrequire_certificate\fR روی \fItrue\fR، کلاینتی که به این شنونده متصل می‌شود باید یک گواهی معتبر ارائه دهد تا اتصال شبکه برقرار شود\&. این امکان را فراهم می‌کند که دسترسی به کارگزار خارج از مکانیزم‌های ارائه‌شده توسط MQTT کنترل شود\&. .RE .PP \fBtls_engine\fR \fIشناسه موتور\fR .RS 4 یک شناسه موتور openssl معتبر\&. این موارد را می‌توان با دستور openssl engine فهرست کرد\&. .RE .PP \fBtls_engine_kpass_sha1\fR \fIهش_sha1_گذرواژه_موتور\fR .RS 4 هش SHA1 گذرواژه کلید خصوصی هنگام استفاده از موتور TLS\&. برخی از موتورهای TLS مانند موتور TPM ممکن است برای دسترسی به گذرواژه نیاز داشته باشند\&. این گزینه اجازه می‌دهد یک هش SHA1 با کدگذاری هگز از گذرواژه مستقیماً به موتور ارسال شود، به جای اینکه گذرواژه از کاربر پرسیده شود\&. .RE .PP \fBtls_keyform\fR [ pem | engine ] .RS 4 نوع کلید خصوصی مورد استفاده هنگام برقراری اتصالات TLS را مشخص می‌کند\&. این می‌تواند "pem" یا "engine" باشد\&. این پارامتر زمانی مفید است که یک ماژول TPM استفاده می‌شود و کلید خصوصی با آن ایجاد شده است\&. پیش‌فرض "pem" است که به معنای استفاده از فایل‌های کلید خصوصی معمولی است\&. .RE .PP \fBtls_version\fR \fIنسخه\fR .RS 4 حداقل نسخه پروتکل TLS را برای استفاده در این شنونده پیکربندی می‌کند\&. مقادیر ممکن عبارتند از \fItlsv1\&.3\fR و \fItlsv1\&.2\fR\&. در صورت تنظیم نشدن، پیش‌فرض اجازه دادن به TLS v1\&.3 و v1\&.2 است\&. .sp در نسخه 1\&.6\&.x و قبل‌تر Mosquitto، این گزینه تنها نسخه پروتکل TLS مجاز را تنظیم می‌کرد، نه حداقل نسخه را\&. .RE .PP \fBuse_identity_as_username\fR [ true | false ] .RS 4 اگر \fBrequire_certificate\fR برابر \fItrue\fR باشد، می‌توانید \fBuse_identity_as_username\fR را روی \fItrue\fR تنظیم کنید تا از مقدار CN از گواهی کلاینت به عنوان نام کاربری استفاده شود\&. اگر این \fItrue\fR باشد، گزینه \fBpassword_file\fR برای این شنونده استفاده نخواهد شد\&. .sp اگر هر دو روی \fItrue\fR تنظیم شده باشند، این گزینه بر \fBuse_subject_as_username\fR اولویت دارد\&. .sp گزینه \fBuse_subject_as_username\fR را نیز ببینید\&. .RE .PP \fBuse_subject_as_username\fR [ true | false ] .RS 4 اگر \fBrequire_certificate\fR برابر \fItrue\fR باشد، می‌توانید \fBuse_subject_as_username\fR را روی \fItrue\fR تنظیم کنید تا از مقدار کامل موضوع (subject) از گواهی کلاینت به عنوان نام کاربری استفاده شود\&. اگر این \fItrue\fR باشد، گزینه \fBpassword_file\fR برای این شنونده استفاده نخواهد شد\&. .sp موضوع در قالبی مشابه زیر تولید خواهد شد: \fBCN=test client,OU=Production,O=Server,L=Nottingham,ST=Nottinghamshire,C=GB\fR\&. .sp گزینه \fBuse_identity_as_username\fR را نیز ببینید\&. .RE .SS "پشتیبانی از SSL/TLS مبتنی بر کلید از پیش اشتراک‌گذاری‌شده (Pre-shared-key based SSL/TLS Support)" .PP گزینه‌های زیر برای همه شنوندگان جهت پیکربندی پشتیبانی SSL مبتنی بر کلید از پیش اشتراک‌گذاری‌شده در دسترس هستند\&. همچنین «پشتیبانی از SSL/TLS مبتنی بر گواهی» را ببینید\&. .PP \fBciphers\fR \fIفهرست_رمزها\fR .RS 4 هنگام استفاده از PSK، رمزهای رمزگذاری مورداستفاده از لیست رمزهای PSK موجود انتخاب می‌شوند\&. اگر می‌خواهید کنترل کنید کدام رمزها در دسترس باشند، از این گزینه استفاده کنید\&. فهرست رمزهای موجود را می‌توان با استفاده از دستور "openssl ciphers" به دست آورد و باید در همان قالب خروجی آن دستور ارائه شود\&. .RE .PP \fBpsk_hint\fR \fIراهنما (hint)\fR .RS 4 گزینه \fBpsk_hint\fR پشتیبانی از کلید از پیش اشتراک‌گذاری‌شده را برای این شنونده فعال می‌کند و همچنین به عنوان یک شناسه برای این شنونده عمل می‌کند\&. این راهنما به کلاینت‌ها ارسال می‌شود و ممکن است به صورت محلی برای کمک به احراز هویت استفاده شود\&. این راهنما یک رشته آزاد است که به خودی خود معنای چندانی ندارد، بنابراین در انتخاب آن آزاد هستید\&. .sp اگر این گزینه ارائه شده است، برای تعریف کلیدهای از پیش اشتراک‌گذاری‌شده مورد استفاده یا ایجاد یک افزونه امنیتی برای مدیریت آن‌ها، \fBpsk_file\fR را ببینید\&. .RE .PP \fBtls_version\fR \fIنسخه\fR .RS 4 حداقل نسخه پروتکل TLS را برای استفاده در این شنونده پیکربندی می‌کند\&. مقادیر ممکن عبارتند از \fItlsv1\&.3\fR و \fItlsv1\&.2\fR\&. در صورت تنظیم نشدن، پیش‌فرض اجازه دادن به TLS v1\&.3 و v1\&.2 است\&. .sp در نسخه 1\&.6\&.x و قبل‌تر Mosquitto، این گزینه تنها نسخه پروتکل TLS مجاز را تنظیم می‌کرد، نه حداقل نسخه را\&. .RE .PP \fBuse_identity_as_username\fR [ true | false ] .RS 4 گزینه \fBuse_identity_as_username\fR را تنظیم کنید تا هویت psk ارسال شده توسط کلاینت به عنوان نام کاربری آن استفاده شود\&. نام کاربری مانند حالت عادی بررسی می‌شود، بنابراین باید از \fBpassword_file\fR یا ابزار دیگری برای بررسی احراز هویت استفاده شود\&. هیچ گذرواژه‌ای استفاده نخواهد شد\&. .RE .SH "پیکربندی پل‌ها (CONFIGURING BRIDGES)" .PP چندین پل (اتصال به سایر کارگزارها) را می‌توان با استفاده از متغیرهای زیر پیکربندی کرد\&. .PP با سیگنال بارگذاری مجدد دوباره بارگذاری می‌شود\&. .PP \fBaddress\fR \fIآدرس[:درگاه]\fR \fI[آدرس[:درگاه]]\fR, \fBaddresses\fR \fIآدرس[:درگاه]\fR \fI[آدرس[:درگاه]]\fR .RS 4 آدرس و به صورت اختیاری درگاه پلی را که باید به آن متصل شود مشخص می‌کند\&. این باید برای هر اتصال پل داده شود\&. اگر درگاه مشخص نشده باشد، از درگاه پیش‌فرض 1883 استفاده می‌شود\&. .sp اگر از آدرس IPv6 استفاده می‌کنید، تعیین درگاه اختیاری نیست و الزامی است\&. .sp چندین آدرس میزبان را می‌توان در پیکربندی address مشخص کرد\&. برای جزئیات بیشتر در مورد رفتار پل‌ها با چندین آدرس، گزینه \fBround_robin\fR را ببینید\&. .RE .PP \fBbridge_attempt_unsubscribe\fR [ true | false ] .RS 4 اگر یک پل موضوعاتی با جهت "out" داشته باشد، رفتار پیش‌فرض این است که یک درخواست لغو اشتراک (unsubscribe) به کارگزار راه دور در آن موضوع ارسال کند\&. این بدان معنی است که تغییر جهت موضوع از "in" به "out" باعث ادامه دریافت پیام‌های ورودی نخواهد شد\&. ارسال این درخواست‌های لغو اشتراک همیشه مطلوب نیست؛ تنظیم \fBbridge_attempt_unsubscribe\fR روی \fIfalse\fR ارسال درخواست لغو اشتراک را غیرفعال می‌کند\&. پیش‌فرض \fItrue\fR است\&. .RE .PP \fBbridge_bind_address\fR \fIآدرس آی‌پی\fR .RS 4 اگر لازم است که پل از طریق یک رابط شبکه خاص متصل شود، از bridge_bind_address استفاده کنید تا به پل بگویید سوکت باید به کدام آدرس IP محلی متصل شود، مثلاً \fBbridge_bind_address 192\&.168\&.1\&.10\fR\&. .RE .PP \fBbridge_max_packet_size\fR \fIمقدار\fR .RS 4 اگر می‌خواهید اندازه پیام‌های ارسالی به یک پل راه دور را محدود کنید، از این گزینه استفاده نمایید\&. این حداکثر تعداد بایت را برای کل پیام، شامل سرآیندها و بدنه پیام تنظیم می‌کند\&. توجه داشته باشید که کارگزاران MQTT v5 ممکن است ویژگی maximum\-packet\-size مخصوص به خود را ارائه دهند\&. در این حالت، محدودیت کوچکتر از بین این دو اعمال خواهد شد\&. برای حالت "نامحدود" روی 0 تنظیم کنید\&. .RE .PP \fBbridge_max_topic_alias\fR \fIمقدار\fR .RS 4 اگر پل از MQTT v5 استفاده می‌کند، این گزینه حداکثر تعداد نام‌های مستعار موضوع را که پل به کارگزار راه دور اجازه پیکربندی می‌دهد، تعیین می‌کند\&. پیش‌فرض 10 است، حداکثر 65535\&. برای غیرفعال کردن کامل نام‌های مستعار موضوعات ورودی، روی 0 تنظیم کنید\&. .RE .PP \fBbridge_outgoing_retain\fR [ true | false ] .RS 4 برخی از کارگزاران MQTT پیام‌های نگه‌داشته‌شده (retained) را مجاز نمی‌دانند\&. پروتکل MQTT v5 مکانیزمی را در اختیار کارگزاران قرار می‌دهد تا به کلاینت‌ها اعلام کنند از پیام‌های نگه‌داشته‌شده پشتیبانی نمی‌کنند، اما این کار برای MQTT v3\&.1\&.1 یا v3\&.1 امکان‌پذیر نیست\&. اگر نیاز به اتصال به یک کارگزار v3\&.1\&.1 یا v3\&.1 دارید که از پیام‌های نگه‌داشته‌شده پشتیبانی نمی‌کند، گزینه \fBbridge_outgoing_retain\fR را روی \fIfalse\fR تنظیم کنید\&. این کار بدون در نظر گرفتن هرگونه تنظیم دیگر، بیت retain را در تمام پیام‌های خروجی به آن پل حذف می‌کند\&. پیش‌فرض \fItrue\fR است\&. .RE .PP \fBbridge_protocol_version\fR \fIنسخه\fR .RS 4 نسخه پروتکل MQTT را برای استفاده با این پل تنظیم می‌کند\&. می‌تواند یکی از موارد \fImqttv50\fR، \fImqttv311\fR یا \fImqttv31\fR باشد\&. پیش‌فرض \fImqttv311\fR است\&. .RE .PP \fBbridge_receive_maximum\fR \fIتعداد\fR .RS 4 اگر پل از MQTT v5\&.0 استفاده می‌کند، از \fBbridge_receive_maximum\fR برای محدود کردن تعداد پیام‌های QoS 1 یا 2 که می‌توانند همزمان در جریان باشند استفاده کنید\&. باید بین 1 تا 65535 باشد\&. پیش‌فرض \fBmax_inflight_messages\fR است که مقدار پیش‌فرض آن 20 می‌باشد\&. .RE .PP \fBbridge_session_expiry_interval\fR \fIبازه زمانی\fR .RS 4 اگر پل از MQTT v5\&.0 استفاده می‌کند، از \fBbridge_session_expiry_interval\fR برای تنظیم بازه انقضای نشست استفاده کنید\&. روی \fI0\fR تنظیم کنید تا با قطع اتصال، نشست بلافاصله منقضی شود\&. روی \fI0xFFFFFFFF\fR تنظیم کنید تا بازه انقضای نامحدود داشته باشد\&. در غیر این صورت، بازه انقضا روی تعداد ثانیه‌هایی که مشخص می‌کنید تنظیم می‌شود\&. پیش‌فرض 0 است\&. .RE .PP \fBbridge_tcp_keepalive\fR \fIبیکاری\fR \fIفاصله\fR \fIشمارنده\fR .RS 4 پارامترهای TCP keepalive را برای این اتصال پل تنظیم می‌کند\&. از این گزینه استفاده کنید تا بتوانید مقدار طولانی برای نگه‌داری اتصال در پروتکل MQTT تنظیم کنید، در حالی که همچنان قادر به تشخیص قطع اتصال در یک زمان معقول باشید\&. .sp این گزینه ممکن است هنگام اتصال به سرویس‌هایی که برای پیام‌های PINGREQ هزینه دریافت می‌کنند مفید باشد\&. .sp به‌طور پیش‌فرض غیرفعال است\&. .RE .PP \fBbridge_tcp_user_timeout\fR \fIمهلت زمانی\fR .RS 4 حداکثر مدت زمانی (بر حسب میلی‌ثانیه) را مشخص می‌کند که داده‌های ارسال‌شده ممکن است در سطح TCP بدون تأیید باقی بمانند\&. توزیع‌های محبوب لینوکس به نظر می‌رسد این زمان را روی "حداکثر تا 20 دقیقه با پیش‌فرض‌های سیستم" تنظیم می‌کنند (برگرفته از صفحه راهنمای tcp لینوکس)\&. زمان پیش‌فرض به tcp_retries2 مربوط می‌شود\&. کاهش این مقدار به تشخیص سریع‌تر اتصالات قطع‌شده کمک می‌کند\&. .sp توجه داشته باشید که وقتی در ترکیب با TCP Keepalive استفاده می‌شود، ممکن است رفتار دومی را تغییر دهد\&. .sp می‌توانید جزئیات بیشتر درباره این تنظیم را در اینجا بیابید: \m[blue]\fB\%https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/\fR\m[] .sp فقط در لینوکس موجود است\&. .RE .PP \fBcleansession\fR [ true | false ] .RS 4 گزینه clean session را برای این پل تنظیم می‌کند\&. تنظیم روی \fIfalse\fR (پیش‌فرض) به این معنی است که تمام اشتراک‌ها در کارگزار راه دور در صورت قطع اتصال شبکه حفظ می‌شوند\&. اگر روی \fItrue\fR تنظیم شود، تمام اشتراک‌ها و پیام‌ها در کارگزار راه دور در صورت قطع اتصال پاکسازی خواهند شد\&. توجه داشته باشید که تنظیم روی \fItrue\fR ممکن است باعث ارسال حجم زیادی از پیام‌های نگه‌داشته‌شده در هر بار اتصال مجدد پل شود\&. .sp اگر از پل‌هایی با \fBcleansession\fR تنظیم‌شده روی \fIfalse\fR (پیش‌فرض) استفاده می‌کنید، در صورت تغییر موضوعاتی که در آن‌ها مشترک می‌شوید ممکن است رفتار غیرمنتظره‌ای از موضوعات ورودی مشاهده کنید\&. این به این دلیل است که کارگزار راه دور اشتراک موضوع قبلی را نگه می‌دارد\&. اگر این مشکل را دارید، پل خود را با \fBcleansession\fR تنظیم‌شده روی \fItrue\fR متصل کنید، سپس به حالت معمول با cleansession تنظیم‌شده روی \fIfalse\fR مجدداً متصل شوید\&. .RE .PP \fBlocal_cleansession\fR [ true | false] .RS 4 گزینه معمول \fBcleansession\fR هم اشتراک‌های محلی و هم اشتراک‌های راه دور را پوشش می‌دهد\&. local_cleansession امکان تفکیک این دو را فراهم می‌کند\&. تنظیم روی \fIfalse\fR به این معنی است که اتصال محلی اشتراک را مستقل از اتصال راه دور حفظ خواهد کرد\&. .sp پیش‌فرض مقدار bridge\&.cleansession است مگر اینکه به صراحت مشخص شده باشد\&. .RE .PP \fBconnection\fR \fIنام\fR .RS 4 این متغیر شروع اتصال جدید یک پل را مشخص می‌کند\&. همچنین برای دادن نامی به پل استفاده می‌شود که به عنوان شناسه کلاینت در کارگزار راه دور استفاده می‌گردد\&. .RE .PP \fBkeepalive_interval\fR \fIثانیه\fR .RS 4 تعداد ثانیه‌هایی را تنظیم می‌کند که پس از آن در صورت عدم وقوع ترافیک دیگر، پل باید پینگ ارسال کند\&. پیش‌فرض 60 است\&. حداقل مقدار مجاز 5 ثانیه است\&. .RE .PP \fBidle_timeout\fR \fIثانیه\fR .RS 4 مدت زمانی را تعیین می‌کند که یک پل با نوع راه‌اندازی lazy باید قبل از متوقف شدن در حالت بیکار بماند\&. پیش‌فرض 60 ثانیه است\&. .RE .PP \fBlocal_clientid\fR \fIشناسه\fR .RS 4 شناسه کلاینت را برای استفاده در کارگزار محلی تنظیم می‌کند\&. در صورت عدم تعریف، پیش‌فرض \fBlocal\&.\fR است\&. اگر یک کارگزار را به خودش متصل می‌کنید، مهم است که local_clientid و remote_clientid یکسان نباشند\&. .RE .PP \fBlocal_password\fR \fIگذرواژه\fR .RS 4 گذرواژه‌ای را پیکربندی می‌کند که هنگام اتصال این پل به کارگزار محلی استفاده می‌شود\&. این ممکن است در هنگام استفاده از احراز هویت و ACLها مهم باشد\&. .RE .PP \fBlocal_username\fR \fIنام کاربری\fR .RS 4 نام کاربری را برای اتصال این پل به کارگزار محلی پیکربندی می‌کند\&. این ممکن است در هنگام استفاده از احراز هویت و ACLها مهم باشد\&. .RE .PP \fBnotifications\fR [ true | false ] .RS 4 اگر روی \fItrue\fR تنظیم شود، پیام‌های اعلان حاوی اطلاعاتی در مورد وضعیت اتصال پل را به کارگزاران محلی و راه دور منتشر می‌کند\&. پیام‌های نگه‌داشته‌شده در موضوع $SYS/broker/connection//state منتشر می‌شوند مگر اینکه با \fBnotification_topic\fR طور دیگری تنظیم شده باشد\&. اگر پیام 1 باشد اتصال فعال است و اگر 0 باشد اتصال با شکست مواجه شده است\&. پیش‌فرض \fItrue\fR است\&. .sp این گزینه از قابلیت وصیت‌نامه (Last Will and Testament یا LWT) استفاده می‌کند\&. .RE .PP \fBnotifications_local_only\fR [ true | false ] .RS 4 اگر روی \fItrue\fR تنظیم شود، فقط پیام‌های اعلان مربوط به وضعیت اتصال پل را به کارگزار محلی ارسال می‌کند\&. پیش‌فرض \fIfalse\fR است\&. .RE .PP \fBnotification_topic\fR \fIموضوع\fR .RS 4 موضوعی را انتخاب می‌کند که اعلان‌ها برای این پل در آن منتشر خواهند شد\&. در صورت عدم تنظیم، پیام‌ها در موضوع $SYS/broker/connection//state ارسال خواهند شد\&. .RE .PP \fBremote_clientid\fR \fIشناسه\fR .RS 4 شناسه کلاینت را برای این اتصال پل تنظیم می‌کند\&. اگر تعریف نشود، به طور پیش‌فرض روی \*(Aqname\&.hostname\*(Aq قرار می‌گیرد که در آن name نام اتصال و hostname نام میزبان این رایانه است\&. .sp این گزینه جایگزین گزینه قدیمی "clientid" شده است تا از سردرگمی بین طرف‌های محلی/راه دور پل جلوگیری شود\&. گزینه "clientid" فعلاً معتبر باقی می‌ماند\&. .RE .PP \fBremote_password\fR \fIمقدار\fR .RS 4 یک گذرواژه برای پل پیکربندی می‌کند\&. این برای اهداف احراز هویت هنگام اتصال به کارگزاری که از MQTT v3\&.1 به بالا پشتیبانی می‌کند و برای اتصال به نام کاربری و/یا گذرواژه نیاز دارد استفاده می‌شود\&. این گزینه فقط در صورتی معتبر است که remote_username نیز ارائه شده باشد\&. .sp این گزینه جایگزین گزینه قدیمی "password" شده است تا از سردرگمی بین طرف‌های محلی/راه دور پل جلوگیری شود\&. گزینه "password" فعلاً معتبر باقی می‌ماند\&. .RE .PP \fBremote_username\fR \fIنام\fR .RS 4 یک نام کاربری برای پل پیکربندی می‌کند\&. این برای اهداف احراز هویت هنگام اتصال به کارگزاری که از MQTT v3\&.1 به بالا پشتیبانی می‌کند و برای اتصال به نام کاربری و/یا گذرواژه نیاز دارد استفاده می‌شود\&. گزینه \fBremote_password\fR را نیز ببینید\&. .sp این گزینه جایگزین گزینه قدیمی "username" شده است تا از سردرگمی بین طرف‌های محلی/راه دور پل جلوگیری شود\&. گزینه "username" فعلاً معتبر باقی می‌ماند\&. .RE .PP \fBrestart_timeout\fR \fIپایه سقف [پایدار]\fR, \fBrestart_timeout\fR \fIثابت\fR .RS 4 مدت زمانی را تنظیم می‌کند که یک پل با نوع راه‌اندازی خودکار (automatic) قبل از تلاش برای اتصال مجدد منتظر می‌ماند\&. .sp این گزینه را می‌توان برای استفاده از یک زمان تاخیر ثابت بر حسب ثانیه، یا استفاده از مکانیزم بازگشت مبتنی بر "Decorrelated Jitter" پیکربندی کرد که درجه‌ای از تصادفی بودن را به زمان وقوع راه‌اندازی مجدد اضافه می‌کند، از پایه (base) شروع شده و تا سقف (cap) افزایش می‌یابد\&. زمان بازگشت پس از اتصال موفقیت‌آمیز به \fIbase\fR بازنشانی می‌شود\&. وقتی \fIstable\fR مشخص شده باشد، زمان بازگشت تنها در صورتی بازنشانی می‌شود که اتصال حداقل به مدت \fIstable\fR ثانیه باز بماند\&. مقدار پایه حداقل 1 ثانیه و حداکثر 3600 ثانیه است\&. سقف حداقل برابر پایه و حداکثر 7200 ثانیه است\&. .sp تنظیم یک مهلت زمانی ثابت 20 ثانیه‌ای: .sp .if n \{\ .RS 4 .\} .nf restart_timeout 20 .fi .if n \{\ .RE .\} .sp تنظیم عقب‌نشینی با پایه (مقدار شروع) 10 ثانیه و سقف (حد بالا) 60 ثانیه: .sp .if n \{\ .RS 4 .\} .nf restart_timeout 10 60 .fi .if n \{\ .RE .\} .sp مشابه مثال قبل، اما قبل از بازنشانی عقب‌نشینی، حداقل 30 ثانیه منتظر پایدار ماندن اتصال بمانید: .sp .if n \{\ .RS 4 .\} .nf restart_timeout 10 60 30 .fi .if n \{\ .RE .\} .sp پیش‌فرض جیتر با پایه 5 ثانیه و سقف 30 ثانیه است\&. .RE .PP \fBround_robin\fR [ true | false ] .RS 4 اگر پل بیش از یک آدرس در پیکربندی address/addresses داشته باشد، گزینه round_robin رفتار پل را در هنگام خرابی اتصال پل مشخص می‌کند\&. اگر round_robin برابر \fIfalse\fR (مقدار پیش‌فرض) باشد، اولین آدرس به عنوان اتصال اصلی پل در نظر گرفته می‌شود\&. اگر اتصال با شکست مواجه شود، سایر آدرس‌های ثانویه به نوبت امتحان خواهند شد\&. در حین اتصال به پل ثانویه، پل به طور دوره‌ای تلاش می‌کند تا زمانی که موفق شود دوباره به پل اصلی متصل گردد\&. .sp اگر round_robin برابر \fItrue\fR باشد، با همه آدرس‌ها به طور مساوی برخورد می‌شود\&. اگر اتصالی با شکست مواجه شود، آدرس بعدی امتحان می‌شود و در صورت موفقیت تا زمان شکست متصل باقی می‌ماند\&. .RE .PP \fBstart_type\fR [ automatic | lazy | once ] .RS 4 نوع راه‌اندازی پل را مشخص می‌کند\&. این نحوه راه‌اندازی پل را کنترل می‌کند و می‌تواند یکی از سه نوع باشد: \fIautomatic\fR، \fIlazy\fR و \fIonce\fR\&. توجه داشته باشید که RSMB نوع راه‌اندازی چهارم "manual" را ارائه می‌دهد که در حال حاضر توسط mosquitto پشتیبانی نمی‌شود\&. .sp نوع \fIautomatic\fR نوع راه‌اندازی پیش‌فرض است و به این معنی است که اتصال پل به طور خودکار هنگام شروع کارگزار آغاز می‌شود و در صورت قطع اتصال نیز پس از یک تأخیر کوتاه (30 ثانیه) راه‌اندازی مجدد می‌گردد\&. .sp پل‌هایی که از نوع شروع \fIlazy\fR استفاده می‌کنند، زمانی که تعداد پیام‌های صف‌بندی‌شده از عدد تعیین‌شده با گزینه \fBthreshold\fR بیشتر شود، به طور خودکار راه‌اندازی می‌شوند\&. پس از مدت زمان تعیین‌شده توسط پارامتر \fBidle_timeout\fR به طور خودکار متوقف خواهد شد\&. اگر می‌خواهید اتصال فقط در صورت نیاز فعال باشد از این نوع راه‌اندازی استفاده کنید\&. .sp پلی که از نوع راه‌اندازی \fIonce\fR استفاده می‌کند هنگام راه‌اندازی کارگزار به طور خودکار شروع به کار می‌کند اما در صورت قطع اتصال مجدداً راه‌اندازی نمی‌شود\&. .RE .PP \fBthreshold\fR \fIتعداد\fR .RS 4 تعداد پیام‌هایی را تعیین می‌کند که برای راه‌اندازی مجدد پلی با نوع شروع lazy باید در صف قرار گیرند\&. پیش‌فرض 10 پیام است\&. .RE .PP \fBtopic\fR \fIالگو\fR [[[ out | in | both ] سطح-qos] پیشوند-محلی پیشوند-راه‌دور] .RS 4 یک الگوی موضوعی را برای اشتراک‌گذاری بین دو کارگزار تعریف می‌کند\&. هر موضوعی که با الگو مطابقت داشته باشد (که ممکن است شامل نویسه‌های عام باشد) به اشتراک گذاشته می‌شود\&. در صورتی که الگو حاوی فاصله باشد، می‌تواند در دو گیومه محصور شود\&. پارامتر دوم جهتی را که پیام‌ها در آن به اشتراک گذاشته می‌شوند مشخص می‌کند، بنابراین می‌توان پیام‌ها را از یک کارگزار راه دور با استفاده از \fIin\fR وارد کرد، پیام‌ها را با استفاده از \fIout\fR به کارگزار راه دور صادر کرد یا پیام‌ها را در هر دو جهت به اشتراک گذاشت\&. اگر این پارامتر تعریف نشده باشد، از مقدار پیش‌فرض \fIout\fR استفاده می‌شود\&. سطح QoS، سطح QoS انتشار/اشتراک مورد استفاده برای این موضوع را تعیین می‌کند و به طور پیش‌فرض 0 است\&. .sp گزینه‌های \fIlocal\-prefix\fR و \fIremote\-prefix\fR اجازه می‌دهند موضوعات هنگام انتشار به کارگزاران راه دور و دریافت از آنها بازنگاشت (remap) شوند\&. این اجازه می‌دهد تا درخت موضوعی از کارگزار محلی در یک مکان مناسب در درخت موضوعی کارگزار راه دور درج شود\&. .sp برای موضوعات ورودی، پل پیشوند راه دور را به ابتدای الگو اضافه کرده و در موضوع حاصل در کارگزار راه دور مشترک می‌شود\&. هنگامی که یک پیام ورودی منطبق دریافت شد، پیشوند راه دور از موضوع حذف شده و سپس پیشوند محلی اضافه می‌شود\&. .sp برای موضوعات خروجی، پل پیشوند محلی را به ابتدای الگو اضافه کرده و در موضوع حاصل در کارگزار محلی مشترک می‌شود\&. هنگامی که یک پیام خروجی پردازش شد، پیشوند محلی از موضوع حذف شده و سپس پیشوند راه دور اضافه می‌شود\&. .sp هنگام استفاده از نگاشت موضوع، می‌توان با استفاده از نشانگر \fI""\fR یک پیشوند خالی تعریف کرد\&. استفاده از نشانگر خالی برای خود موضوع نیز معتبر است\&. جدول زیر مشخص می‌کند چه ترکیبی از خالی یا مقدار معتبر است\&. ستون‌های \fBموضوع کامل محلی (Full Local Topic)\fR و \fBموضوع کامل راه دور (Full Remote Topic)\fR موضوعات حاصلی را نشان می‌دهند که در انتهای محلی و راه دور پل استفاده می‌شوند\&. برای مثال، برای ردیف اول جدول اگر به \fBL/topic\fR روی کارگزار محلی پیامی منتشر کنید، کارگزار راه دور پیامی در مورد موضوع \fBR/topic\fR دریافت خواهد کرد\&. .TS allbox tab(:); lB lB lB lB lB lB. T{ \fIالگو (Pattern)\fR T}:T{ \fIپیشوند محلی (Local Prefix)\fR T}:T{ \fIپیشوند راه دور (Remote Prefix)\fR T}:T{ \fIاعتبار (Validity)\fR T}:T{ \fIموضوع کامل محلی (Full Local Topic)\fR T}:T{ \fIموضوع کامل راه دور (Full Remote Topic)\fR T} .T& l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l. T{ pattern T}:T{ L/ T}:T{ R/ T}:T{ معتبر (valid) T}:T{ L/pattern T}:T{ R/pattern T} T{ pattern T}:T{ L/ T}:T{ "" T}:T{ معتبر (valid) T}:T{ L/pattern T}:T{ pattern T} T{ pattern T}:T{ "" T}:T{ R/ T}:T{ معتبر (valid) T}:T{ pattern T}:T{ R/pattern T} T{ pattern T}:T{ "" T}:T{ "" T}:T{ معتبر (بدون نگاشت مجدد) T}:T{ pattern T}:T{ pattern T} T{ "" T}:T{ local T}:T{ remote T}:T{ معتبر (نگاشت مجدد یک موضوع محلی به راه دور) T}:T{ local T}:T{ remote T} T{ "" T}:T{ local T}:T{ "" T}:T{ نامعتبر (invalid) T}:T{ \ \& T}:T{ \ \& T} T{ "" T}:T{ "" T}:T{ remote T}:T{ نامعتبر (invalid) T}:T{ \ \& T}:T{ \ \& T} T{ "" T}:T{ "" T}:T{ "" T}:T{ نامعتبر (invalid) T}:T{ \ \& T}:T{ \ \& T} .TE .sp 1 برای نگاشت مجدد کل یک درخت موضوعی، به عنوان مثال از این دستور استفاده کنید: .sp .if n \{\ .RS 4 .\} .nf topic # both 2 local/topic/ remote/topic/ .fi .if n \{\ .RE .\} .sp این گزینه می‌تواند چندین بار برای هر پل مشخص شود\&. .sp باید دقت شود که با این گزینه حلقه‌ای ایجاد نشود\&. اگر بار پردازشی بالایی را روی پردازنده از یک کارگزار تجربه می‌کنید، ممکن است حلقه‌ای داشته باشید که در آن هر کارگزار دائماً پیام‌های یکسانی را برای دیگری ارسال می‌کند\&. .sp در صورتی که هنگام استفاده از موضوعات ورودی، پیام‌ها روی موضوعات غیرمنتظره‌ای می‌رسند، گزینه \fBcleansession\fR را نیز ببینید\&. .PP \fBمثال: نگاشت مجدد موضوع پل\&.\fR پیکربندی زیر یک پل را به کارگزار در \fBtest\&.mosquitto\&.org\fR متصل می‌کند\&. این پل در موضوع راه دور \fB$SYS/broker/clients/total\fR مشترک می‌شود و پیام‌های دریافتی را در موضوع محلی \fBtest/mosquitto/org/clients/total\fR بازنشر می‌کند\&. .sp .if n \{\ .RS 4 .\} .nf connection test\-mosquitto\-org address test\&.mosquitto\&.org cleansession true topic clients/total in 0 test/mosquitto/org/ $SYS/broker/ .fi .if n \{\ .RE .\} .RE .PP \fBtry_private\fR [ true | false ] .RS 4 اگر try_private روی \fItrue\fR تنظیم شود، پل تلاش می‌کند به کارگزار راه دور نشان دهد که یک پل است و نه یک کلاینت معمولی\&. در صورت موفقیت، این بدان معنی است که تشخیص حلقه مؤثرتر خواهد بود و پیام‌های نگه‌داشته‌شده به درستی منتشر می‌شوند\&. همه کارگزاران از این ویژگی پشتیبانی نمی‌کنند، بنابراین در صورتی که پل شما به درستی متصل نشود ممکن است لازم باشد \fBtry_private\fR را روی \fIfalse\fR تنظیم کنید\&. .sp پیش‌فرض \fItrue\fR است\&. .RE .PP \fBbridge_reload_type\fR [ lazy | immediate ] .RS 4 اگر گزینه‌های پل را در فایل پیکربندی تغییر دهید، آن تغییرات پیکربندی در حین اتصال مجدد پل اعمال می‌شوند\&. گزینه \fBbridge_reload_type\fR تعیین می‌کند که اتصال مجدد چه زمانی اتفاق بیفتد، و می‌تواند روی \fIlazy\fR یا \fIimmediate\fR تنظیم شود\&. .sp مقدار \fIlazy\fR پیش‌فرض است، و به این معنی است که هر پل متصل تا زمانی که یک اتصال مجدد طبیعی رخ دهد در حالت فعلی خود باقی می‌ماند، و در آن مرحله از پیکربندی جدید استفاده خواهد شد\&. .sp مقدار \fIimmediate\fR اتصال مجدد را اجبار می‌کند و بنابراین بلافاصله از پیکربندی جدید استفاده می‌نماید\&. .RE .SS "پشتیبانی از SSL/TLS (SSL/TLS Support)" .PP گزینه‌های زیر برای همه پل‌ها جهت پیکربندی پشتیبانی از SSL/TLS در دسترس هستند\&. .PP \fBbridge_alpn\fR \fIalpn\fR .RS 4 گزینه مذاکره پروتکل لایه کاربردی (ALPN) را برای نشست TLS پیکربندی می‌کند\&. برای کارگزارانی که از هر دو پروتکل WebSockets و MQTT روی یک درگاه پشتیبانی می‌کنند مفید است\&. .RE .PP \fBbridge_cafile\fR \fIمسیر فایل\fR .RS 4 حداقل یکی از گزینه‌های \fBbridge_cafile\fR، \fBbridge_capath\fR، یا \fBbridge_tls_use_os_certs\fR باید ارائه شود تا پشتیبانی SSL/TLS امکان‌پذیر باشد\&. .sp گزینه bridge_cafile برای تعریف مسیر فایلی حاوی گواهی‌های CA کدگذاری‌شده با PEM استفاده می‌شود که گواهی کارگزار راه دور را امضا کرده‌اند\&. .RE .PP \fBbridge_capath\fR \fIمسیر پوشه\fR .RS 4 حداقل یکی از گزینه‌های \fBbridge_cafile\fR، \fBbridge_capath\fR، یا \fBbridge_tls_use_os_certs\fR باید ارائه شود تا پشتیبانی SSL/TLS امکان‌پذیر باشد\&. .sp گزینه bridge_capath برای تعریف مسیر دایرکتوری حاوی گواهی‌های CA با کدگذاری PEM استفاده می‌شود که گواهی کارگزار راه دور را امضا کرده‌اند\&. برای اینکه bridge_capath به درستی کار کند، فایل‌های گواهی باید پسوند "\&.crt" داشته باشند و شما باید هر بار که گواهی اضافه یا حذف می‌کنید "openssl rehash <مسیر به bridge_capath>" را اجرا کنید\&. .RE .PP \fBbridge_certfile\fR \fIمسیر فایل\fR .RS 4 مسیر گواهی کلاینت با کدگذاری PEM برای این پل، در صورتی که توسط کارگزار راه دور الزامی باشد\&. .RE .PP \fBbridge_identity\fR \fIهویت\fR .RS 4 رمزگذاری با کلید از پیش اشتراک‌گذاری‌شده جایگزینی برای رمزگذاری مبتنی بر گواهی ارائه می‌دهد\&. یک پل را می‌توان با استفاده از گزینه‌های \fBbridge_identity\fR و \fBbridge_psk\fR برای استفاده از PSK پیکربندی کرد\&. این همان هویت کلاینت است که در رمزگذاری PSK استفاده می‌شود\&. تنها یکی از روش‌های رمزگذاری مبتنی بر گواهی و مبتنی بر PSK می‌تواند به طور همزمان روی یک پل استفاده شود\&. .RE .PP \fBbridge_insecure\fR [ true | false ] .RS 4 هنگام استفاده از TLS مبتنی بر گواهی، پل تلاش می‌کند تا نام میزبان ارائه‌شده در گواهی راه دور را با میزبان/آدرسی که به آن متصل است مطابقت دهد\&. این ممکن است در سناریوهای آزمایشی مشکلاتی ایجاد کند، بنابراین \fBbridge_insecure\fR می‌تواند روی \fItrue\fR تنظیم شود تا اعتبارسنجی نام میزبان غیرفعال گردد\&. .sp تنظیم این گزینه روی \fItrue\fR به این معنی است که یک شخص ثالث مخرب می‌تواند به طور بالقوه خود را به عنوان سرور شما جا بزند، بنابراین همیشه باید در محیط‌های عملیاتی روی \fIfalse\fR تنظیم شود\&. .RE .PP \fBbridge_keyfile\fR \fIمسیر فایل\fR .RS 4 مسیر کلید خصوصی با کدگذاری PEM برای این پل، در صورتی که توسط کارگزار راه دور الزامی باشد\&. .RE .PP \fBbridge_psk\fR \fIکلید\fR .RS 4 رمزگذاری کلید از پیش اشتراک‌گذاری‌شده جایگزینی برای رمزگذاری مبتنی بر گواهی فراهم می‌کند\&. یک پل را می‌توان با گزینه‌های \fBbridge_identity\fR و \fBbridge_psk\fR برای استفاده از PSK پیکربندی کرد\&. این همان کلید از پیش اشتراک‌گذاری‌شده در قالب هگزادسیمال بدون "0x" است\&. تنها یکی از روش‌های رمزگذاری مبتنی بر گواهی و PSK می‌تواند همزمان روی یک پل استفاده شود\&. .RE .PP \fBbridge_require_ocsp\fR [ true | false ] .RS 4 هنگامی که روی true تنظیم شود، پل نیازمند پروتکل OCSP روی اتصال TLS است که به عنوان کلاینت باز می‌کند\&. .RE .PP \fBbridge_tls_use_os_certs\fR [ true | false ] .RS 4 حداقل یکی از گزینه‌های \fBbridge_cafile\fR، \fBbridge_capath\fR، یا \fBbridge_tls_use_os_certs\fR باید ارائه شود تا پشتیبانی SSL/TLS امکان‌پذیر باشد\&. .sp گزینه \fBbridge_tls_use_os_certs\fR را روی true قرار دهید تا TLS برای این پل فعال شود و آن را طوری پیکربندی کنید که به گواهی‌های پیش‌فرض ارائه‌شده توسط openssl اعتماد کند\&. این معمولاً تعداد زیادی گواهی است\&. پیش‌فرض false است\&. .RE .PP \fBbridge_tls_version\fR \fIنسخه\fR .RS 4 نسخه پروتکل TLS را برای استفاده در این پل پیکربندی می‌کند\&. مقادیر ممکن عبارتند از \fItlsv1\&.3\fR و \fItlsv1\&.2\fR\&. پیش‌فرض \fItlsv1\&.2\fR است\&. کارگزار راه دور برای برقراری موفقیت‌آمیز اتصال باید از همان نسخه TLS پشتیبانی کند\&. .RE .PP \fBbridge_ciphers\fR \fIفهرست_رمزها\fR .RS 4 فهرست الگوریتم‌های رمزنگاری مجاز برای این پل، فقط برای TLS v1\&.2 و قبل‌تر، که هر کدام با دونقطه جدا شده‌اند\&. رمزهای موجود را می‌توان با استفاده از دستور "openssl ciphers" به دست آورد\&. .RE .PP \fBbridge_ciphers_tls1\&.3\fR \fIفهرست_مجموعه‌رمزها\fR .RS 4 فهرست مجموعه‌رمزهای مجاز برای این پل برای TLS v1\&.3 که هر کدام با دونقطه جدا شده‌اند\&. .RE .SH "فایل‌ها (FILES)" .PP mosquitto\&.conf .SH "گزارش باگ‌ها (BUGS)" .PP اطلاعات مربوط به باگ‌های \fBmosquitto\fR را می‌توان در نشانی زیر یافت: \m[blue]\fB\%https://github.com/eclipse-mosquitto/mosquitto/issues\fR\m[] .SH "همچنین ببینید (SEE ALSO)" \fBmosquitto\fR(7), \fBmosquitto\fR(8), \fBmosquitto_passwd\fR(1), \fBmosquitto-tls\fR(7), \fBmqtt\fR(7), \fBlimits.conf\fR(5) .SH "نویسندگان (AUTHORS)" .PP Roger Light