به دلیل حوزه فعالیتم در این چند سال با پرتکل هایی که عملا قابلیت Live را در اختیار ما قرار می دهد، برخورد زیاد داشتم.
نکته مهم : قبل از خوندن این مطلب باید در مورد MQTT مطالعه کرده باشید.
چه نرم افزارهای بزرگی از ان استفاده می کنند: اسنپ، دیجیکالا برای رهگیری رفتار کلاینت در صفحات، اینترنت اشیا و ...
signalr: یکی از اولین ها بود که من شخصا در پروژه های زیادی از ان استفاده کردم. از این تکنولوژی برای بروز رسانی زنده چارت ها, صفحات مانیتورینگ، چت، بروز رسانی صفحات درصورت تغییر و یا رخداد یک اتفاق و ... استفاده کرده ام.
mqtt : از چندین سال گذشته که وارد حوزه اینترنت اشبا شدم، با این تکنولوژی جهت ارتباط بین ابزارها و سرورها استفاده زیادی کرده ام و البته بعد از ان هرجایی هم که از signalr استفاده می کردم به mqtt تغییر دادم.
توجه : تمام مطالب این نوشته نظر شخصی من و حاصل تجربه من است.
شاید سوال واستون بشه که چرا من mqtt را به signalr ترجیح دادم.
خوش دست تر بودن:
mqtt به دلیل دارابون قابلیت های topic به شدت برای من خوش دست تر بود. همچنین در برکر می تونیم خیلی راحتتر دسترسی کلاینت هارو به تاپیک های مختلف کنترل کنیم و در هنگام اتصال مدیریت اجازه دسترسی هارو انجام بدیم.
خیلی راحت متناسب با نیازم تاپیک ها رو ایجاد می کردم و از طریق کلاینت به تاپیک های مورد نظرم گوش می کردم.
سرعت بالاتر و نیاز به منابع سرور کمتر:
mqtt عملا برای به منابع سرور کمتری نیاز است و این تکنولوژی عزیز ساخته شده برای مدیریت انبوه اتصالات.
دارا بودن سه سطح QoS:
سطح 0 (QoS=0): : حداکثر یک بار تحویل. این یعنی اگر گیرنده پیام را از دست بدهد، پیام مجددا ارسال نخواهد شد. به عبارت دیگرT سرور (کارگزار) پیام را ارسال می کند و انتظار تصدیق مشتری یا کلاینت را ندارد.
• سطح 1 ( QoS=1 ): حداقل یک بار تحویل. این یعنی کارگزار تا زمانی که تصدیق دریافت نکند، ارسال پیام خود را به مشترک ادامه می دهد. این ممکن است منجر به دریافت پیام بیش از یک‌بار از جانب مشترکین شود.
• سطح 2 ( QoS=2 ): دقیقاً یک بار تحویل. این سطح تضمین می کند که یک پیام به طور دقیق به مشترک ارسال می شود.
امکان تنظیم دریافت آخرین پیام:
حال سوال اینجاست که اگر مشتری / مشترک متصل نباشد چه اتفاقی خواهد افتاد؟ آیا وقتی مشترک دوباره وصل شود، پیام ها از بین می روند یا بعداً دریافت خواهند شد؟ پاسخ این است: بستگی دارد. این بستگی به گزینه ای به نام Clean Session دارد که در بسته اتصال مشخص شده است. در صورتی که کاربر این بیت را تنظیم کند، هر بار که مشتری (شناخته شده با یک شناسه) متصل شود، سرور جلسات قبلی (از جمله پیام) را ذخیره نمی کند و یک مورد جدید را شروع می کند. در حالی که اگر این بیت صفر باشد، سرور پیام ها را ذخیره می کند.
بازی با تاپیک ها با دو علا + و #:
یکی از موارد خوب این پروتکل اینه که دستتون برای الگوریتم نویسی بسیار باز هست! می تونید مشخص کنید به چه پترن هایی از تاپیک ها گوش بده یا پابلیش کنه.
رمز گذاری :
یکی از موارد عالی این پروتکل پشتیباین از انواع رمز نگاری ها است. البته من از خودم از شیوه رمز گذاری مختص هر ابزار با سرور با SHA256 استفاده کردم که هر ابزارم کلید رمزنگاری منحصربه فرد خودش رو داره.
کلاینت ای دی عزیز:
این کلاینت ایدی یکی از خاصیت های خوب هست که اگر درست به بازیش بگیرید خیلی و خیلی نیازتون کم میشه که مدام به دیتابیس سر بزنید. بعد از اتصال ابزار به سرور و لاگین کردن ابزار این کلاینت ایدی دیگه قابل تغییر نیست و با اطمینان کامل هرچی داده مدام نیاز دارید بزارید داخل این کلاینت ای دی عزیز.
قابلیت کنترل subscribe تاپیک ها:
شما می تونید اجازه ندبد که کلاینت ها به تاپیک هایی که مال اونها نیست گوش بدن.
پایداری:
این پروتکل به خد قابل توجه ای پایدار است و اگر خدمات زیر ساخت خوب باشه قطعی تو کارش نیست
بسته های کنترلی MQTT کوچک ترین واحد انتقال داده در MQTT هستند. کلاینت ها و سرورهای ام کیو تی تی بسته های کنترلی را برای انجام کار خود مانند اشتراک در موضوعات و انتشار پیام ها مبادله می کنند.
در حال حاضر 15 نوع بسته کنترل در MQTT تعریف شده است. اگر آنها را براساس عملکردشان طبقه بندی کنیم، می توانیم این بسته ها را به سه دسته اتصال، انتشار و اشتراک دسته بندی کنیم.
در میان این 15 مورد، بسته CONNECT برای شروع اتصال به سرور توسط کلاینت استفاده می شود و بسته CONNACK به عنوان پاسخی برای نشان دادن نتیجه اتصال، ارسال می شود. اگر کسی بخواهد ارتباط را قطع کند یا اتصال با خطایی مواجه شود که مستلزم قطع اتصال است، کلاینت و سرور می توانند بسته DISCONNECT را ارسال کنند و سپس اتصال شبکه را ببندند.
بسته AUTH نوع جدیدی از بسته است که در MQTT 5.0 معرفی شده است و فقط برای احراز هویت پیشرفته استفاده می شود. این بسته احراز هویت امن تری را برای کلاینت ها و سرورها فراهم می کند.
بسته های PINGREQ و PINGRESP برای حفظ زنده بودن اتصال و کاوش استفاده می شود. کلاینت به صورت دوره ای یک بسته PINGREQ را به سرور ارسال می کند تا مشخص کند که هنوز فعال است، سپس با توجه به اینکه آیا بسته PINGRESP به موقع بازگردانده شده است یا خیر، فعال یا غیرفعال بودن سرور را نتیجه گیری می کند.
بسته PUBLISH برای انتشار پیام ها استفاده می شود و چهار دسته باقی مانده برای تایید پیام های QoS 1 و 2 استفاده می شود.
بسته SUBSCRIBE توسط کلاینت برای اشتراک در موضوعات استفاده می شود، در حالی که بسته USUBSCRIBE دقیقا برعکس عمل کرده و مشترک نبودن در موضوعات را بررسی می کند. بسته های SUBACK و UNSUBACK به ترتیب برای بازگرداندن نتایج اشتراک و لغو اشتراک استفاده می شود.
قابل استفاده در تمام پلتفرم ها:
من در همه پلتفرم ها به راحتی از این پروتکل استفادت کردم
چرا signalr نه (از نظر من) :
سوال اینه من چرا با این چپ افتادم؟ واقعیت اینه خیلی راه دست من نبود و برای من منطق نداشت برعکس mqtt و همچنین سبک بودن mqtt و قابلیت های ذاتی خودش باعث شد من خیلی علاقه مند بشم بهش و حتی برای نرم افزارهایی که می خوام Live باشن هم به سمت mqtt برم و دیگه با signalr کار نکنم من حتی با اینترنت 3g هم یک کیفیت پایدار دریافت کردم.
