MQTT - AWS IoT Core
Menghubungkan dengan MQTT menggunakan SDK Perangkat AWS IoTOpsi Kualitas Layanan (QoS) MQTTSesi persisten MQTTPesan yang disimpan MQTTPesan MQTT Last Will and Testament (LWT)Menggunakan ConnectAttributesFitur yang didukung MQTT 5MQTT 5 propertiKode alasan MQTTAWS IoT perbedaan dari spesifikasi MQTT

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

MQTT

MQTT (Message Queuing Telemetry Transport) adalah protokol pesan ringan dan diadopsi secara luas yang dirancang untuk perangkat terbatas. AWS IoT Core dukungan untuk MQTT didasarkan pada spesifikasi MQTT v3.1.1 dan spesifikasi MQTT v5.0, dengan beberapa perbedaan, seperti yang didokumentasikan dalam. AWS IoT perbedaan dari spesifikasi MQTT Sebagai versi terbaru dari standar, MQTT 5 memperkenalkan beberapa fitur utama yang membuat sistem berbasis MQTT lebih kuat, termasuk peningkatan skalabilitas baru, pelaporan kesalahan yang ditingkatkan dengan respons kode alasan, pengatur waktu kedaluwarsa pesan dan sesi, dan header pesan pengguna khusus. Untuk informasi selengkapnya tentang fitur MQTT 5 yang AWS IoT Core mendukung, lihat fitur yang didukung MQTT 5. AWS IoT Core juga mendukung komunikasi lintas versi MQTT (MQTT 3 dan MQTT 5). Penerbit MQTT 3 dapat mengirim pesan MQTT 3 ke pelanggan MQTT 5 yang akan menerima pesan publikasi MQTT 5, dan sebaliknya.

AWS IoT Core mendukung koneksi perangkat yang menggunakan protokol MQTT dan MQTT melalui protokol WSS dan yang diidentifikasi oleh ID klien. AWS IoT SDK perangkatDukungan kedua protokol dan merupakan cara yang disarankan untuk menghubungkan perangkat ke. AWS IoT Core AWS IoT Perangkat SDK mendukung fungsi yang diperlukan untuk perangkat dan klien untuk terhubung dan mengakses AWS IoT layanan. Perangkat SDK mendukung protokol otentikasi yang diperlukan AWS IoT layanan dan persyaratan ID koneksi yang diperlukan oleh protokol MQTT dan MQTT melalui protokol WSS. Untuk informasi tentang cara menyambung AWS IoT menggunakan SDK AWS Perangkat dan tautan ke contoh AWS IoT dalam bahasa yang didukung, lihatMenghubungkan dengan MQTT menggunakan SDK Perangkat AWS IoT. Untuk informasi selengkapnya tentang metode otentikasi dan pemetaan port untuk pesan MQTT, lihat. Protokol, pemetaan port, dan otentikasi

Meskipun kami menyarankan untuk menggunakan SDK AWS IoT Perangkat untuk terhubung AWS IoT, mereka tidak diperlukan. Namun, jika Anda tidak menggunakan SDK AWS IoT Perangkat, Anda harus menyediakan keamanan koneksi dan komunikasi yang diperlukan. Klien harus mengirimkan ekstensi TLS Server Name Indication (SNI) dalam permintaan koneksi. Upaya koneksi yang tidak termasuk SNI ditolak. Untuk informasi selengkapnya, lihat Keamanan Transportasi di AWS IoT. Klien yang menggunakan pengguna IAM dan AWS kredensialnya untuk mengautentikasi klien harus memberikan otentikasi Signature Version 4 yang benar.

Menghubungkan dengan MQTT menggunakan SDK Perangkat AWS IoT

Bagian ini berisi tautan ke SDK AWS IoT Perangkat dan kode sumber program contoh yang menggambarkan cara menghubungkan perangkat. AWS IoT Contoh aplikasi yang ditautkan di sini menunjukkan cara terhubung AWS IoT menggunakan protokol MQTT dan MQTT melalui WSS.

catatan

AWS IoT Perangkat SDK telah merilis klien MQTT 5.

C++

Menggunakan SDK Perangkat AWS IoT C ++ untuk menghubungkan perangkat

Python

Menggunakan AWS IoT Device SDK untuk Python untuk menghubungkan perangkat

JavaScript

Menggunakan AWS IoT Device SDK JavaScript untuk menghubungkan perangkat

Java

Menggunakan AWS IoT Device SDK for Java untuk menghubungkan perangkat

catatan

AWS IoT Device SDK for Java v2 sekarang mendukung pengembangan Android. Untuk informasi selengkapnya, lihat SDK AWS IoT perangkat untuk Android.

Embedded C

Menggunakan AWS IoT Device SDK untuk Embedded C untuk menghubungkan perangkat

penting

SDK ini dimaksudkan untuk digunakan oleh pengembang perangkat lunak tertanam yang berpengalaman.

Opsi Kualitas Layanan (QoS) MQTT

AWS IoT dan SDK AWS IoT Perangkat mendukung tingkat MQTT Quality of Service (QoS) dan. 0 1 Protokol MQTT mendefinisikan tingkat ketiga QoS, level2, tetapi tidak mendukungnya. AWS IoT Hanya protokol MQTT yang mendukung fitur QoS. HTTPS mendukung QoS dengan meneruskan parameter string kueri ?qos=qos di mana nilainya bisa 0 atau 1.

Tabel ini menjelaskan bagaimana setiap level QoS memengaruhi pesan yang dipublikasikan ke dan oleh broker pesan.

Dengan tingkat QoS...

Pesannya adalah...

Komentar

QoS tingkat 0

Dikirim nol atau lebih kali

Level ini harus digunakan untuk pesan yang dikirim melalui tautan komunikasi yang andal atau yang dapat dilewatkan tanpa masalah.

QoS tingkat 1

Dikirim setidaknya satu kali, dan kemudian berulang kali sampai PUBACK tanggapan diterima

Pesan tidak dianggap lengkap sampai pengirim menerima PUBACK tanggapan untuk menunjukkan pengiriman yang berhasil.

Sesi persisten MQTT

Sesi persisten menyimpan langganan dan pesan klien, dengan Quality of Service (QoS) 1, yang belum diakui oleh klien. Ketika perangkat terhubung kembali ke sesi persisten, sesi dilanjutkan, langganan dipulihkan, dan pesan berlangganan yang tidak diakui diterima dan disimpan sebelum koneksi ulang dikirim ke klien.

Pemrosesan pesan yang disimpan direkam dalam CloudWatch dan CloudWatch Log. Untuk informasi tentang entri yang ditulis ke CloudWatch dan CloudWatch Log, lihat Metrik broker pesan danEntri log antrian.

Membuat sesi persisten

Di MQTT 3, Anda membuat sesi persisten MQTT dengan mengirim CONNECT pesan dan menyetel flag ke. cleanSession 0 Jika tidak ada sesi untuk klien yang mengirim CONNECT pesan, sesi persisten baru akan dibuat. Jika sesi sudah ada untuk klien, klien melanjutkan sesi yang ada. Untuk membuat sesi bersih, Anda mengirim CONNECT pesan dan mengatur cleanSession bendera ke1, dan broker tidak akan menyimpan status sesi apa pun saat klien terputus.

Di MQTT 5, Anda menangani sesi persisten dengan menyetel bendera danClean Start. Session Expiry Interval Clean Start mengontrol awal sesi penghubung dan akhir sesi sebelumnya. Ketika Anda menetapkan Clean Start =1, sesi baru dibuat dan sesi sebelumnya dihentikan jika ada. Saat Anda mengatur Clean Start =0, sesi penghubung melanjutkan sesi sebelumnya jika ada. Interval Kedaluwarsa Sesi mengontrol akhir sesi penghubung. Session Expiry Interval menentukan waktu, dalam detik (4-byte integer), bahwa sesi akan bertahan setelah terputus. Pengaturan Session Expiry interval = 0 menyebabkan sesi segera berakhir setelah terputus. Jika Interval Kedaluwarsa Sesi tidak ditentukan dalam pesan CONNECT, defaultnya adalah 0.

MQTT 5 Mulai Bersih dan Kedaluwarsa Sesi
Nilai properti Deskripsi
Clean Start= 1 Membuat sesi baru dan mengakhiri sesi sebelumnya jika ada.
Clean Start= 0 Melanjutkan sesi jika sesi sebelumnya ada.
Session Expiry Interval> 0 Bertahan sesi.
Session Expiry interval= 0 Tidak bertahan sesi.

Dalam MQTT 5, jika Anda mengatur Clean Start = 1 dan Session Expiry Interval =0, ini setara dengan sesi bersih MQTT 3. Jika Anda mengatur Clean Start = 0 dan Session Expiry Interval >0, ini setara dengan sesi persisten MQTT 3.

catatan

Versi Cross MQTT (MQTT 3 dan MQTT 5) sesi persisten tidak didukung. Sesi persisten MQTT 3 tidak dapat dilanjutkan sebagai sesi MQTT 5, dan sebaliknya.

Operasi selama sesi persisten

Klien menggunakan sessionPresent atribut dalam pesan koneksi yang diakui (CONNACK) untuk menentukan apakah ada sesi persisten. Jika sessionPresent ada1, sesi persisten hadir dan pesan yang disimpan untuk klien dikirim ke klien setelah klien menerimaCONNACK, seperti yang dijelaskan dalam lalu lintas Pesan setelah koneksi ulang ke sesi persisten. Jika sessionPresent ya1, klien tidak perlu berlangganan kembali. Namun, jika sessionPresent ada0, tidak ada sesi persisten yang hadir dan klien harus berlangganan kembali ke filter topiknya.

Setelah klien bergabung dengan sesi persisten, klien dapat mempublikasikan pesan dan berlangganan filter topik tanpa tanda tambahan pada setiap operasi.

Lalu lintas pesan setelah koneksi ulang ke sesi persisten

Sesi persisten mewakili hubungan yang sedang berlangsung antara klien dan broker pesan MQTT. Ketika klien terhubung ke broker pesan menggunakan sesi persisten, broker pesan menyimpan semua langganan yang dibuat klien selama koneksi. Ketika klien terputus, broker pesan menyimpan pesan QoS 1 yang tidak diakui dan pesan QoS 1 baru yang dipublikasikan ke topik yang menjadi langganan klien. Pesan disimpan sesuai dengan batas akun. Pesan yang melebihi batas akan dihapus. Untuk informasi selengkapnya tentang batas pesan persisten, lihat AWS IoT Core titik akhir dan kuota. Ketika klien terhubung kembali ke sesi persistennya, semua langganan dipulihkan dan semua pesan yang disimpan dikirim ke klien dengan kecepatan maksimum 10 pesan per detik. Di MQTT 5, jika QoS1 keluar dengan Interval Kedaluwarsa Pesan berakhir saat klien offline, setelah koneksi dilanjutkan, klien tidak akan menerima pesan kedaluwarsa.

Setelah koneksi ulang, pesan yang disimpan dikirim ke klien, dengan kecepatan yang dibatasi hingga 10 pesan tersimpan per detik, bersama dengan lalu lintas pesan saat ini hingga Publish requests per second per connectionbatas tercapai. Karena tingkat pengiriman pesan yang disimpan terbatas, akan memakan waktu beberapa detik untuk mengirimkan semua pesan yang disimpan jika sesi memiliki lebih dari 10 pesan tersimpan untuk dikirim setelah koneksi ulang.

Mengakhiri sesi persisten

Sesi persisten dapat diakhiri dengan cara-cara berikut:

  • Waktu kedaluwarsa sesi persisten berlalu. Timer kedaluwarsa sesi persisten dimulai ketika broker pesan mendeteksi bahwa klien telah terputus, baik oleh klien memutuskan sambungan atau waktu koneksi habis.

  • Klien mengirimkan CONNECT pesan yang menyetel cleanSession bendera ke1.

Di MQTT 3, nilai default dari waktu kedaluwarsa sesi persisten adalah satu jam, dan ini berlaku untuk semua sesi di akun.

Di MQTT 5, Anda dapat mengatur Interval Kedaluwarsa Sesi untuk setiap sesi pada paket CONNECT dan DISCONNECT.

Untuk Interval Kedaluwarsa Sesi pada paket DISCONNECT:

  • Jika sesi saat ini memiliki Interval Kedaluwarsa Sesi 0, Anda tidak dapat mengatur Interval Kedaluwarsa Sesi menjadi lebih besar dari 0 pada paket DISCONNECT.

  • Jika sesi saat ini memiliki Interval Kedaluwarsa Sesi lebih besar dari 0, dan Anda mengatur Interval Kedaluwarsa Sesi ke 0 pada paket DISCONNECT, sesi akan berakhir pada DISCONNECT.

  • Jika tidak, Interval Kedaluwarsa Sesi pada paket DISCONNECT akan memperbarui Interval Kedaluwarsa Sesi sesi saat ini.

catatan

Pesan yang disimpan menunggu untuk dikirim ke klien ketika sesi berakhir dibuang; Namun, mereka masih ditagih pada tingkat pesan standar, meskipun mereka tidak dapat dikirim. Untuk informasi selengkapnya tentang harga pesan, lihat AWS IoT Core Harga. Anda dapat mengonfigurasi interval waktu kedaluwarsa.

Koneksi ulang setelah sesi persisten telah kedaluwarsa

Jika klien tidak terhubung kembali ke sesi persistennya sebelum kedaluwarsa, sesi berakhir dan pesan yang disimpan akan dibuang. Ketika klien tersambung kembali setelah sesi kedaluwarsa dengan cleanSession tanda ke0, layanan akan membuat sesi persisten baru. Setiap langganan atau pesan dari sesi sebelumnya tidak tersedia untuk sesi ini karena mereka dibuang ketika sesi sebelumnya kedaluwarsa.

Biaya pesan sesi persisten

Pesan dibebankan kepada Anda Akun AWS ketika broker pesan mengirim pesan ke klien atau sesi persisten offline. Ketika perangkat offline dengan sesi persisten menghubungkan kembali dan melanjutkan sesi, pesan yang disimpan dikirim ke perangkat dan dibebankan ke akun Anda lagi. Untuk informasi selengkapnya tentang harga pesan, lihat AWS IoT Core harga - Pesan.

Waktu kedaluwarsa sesi persisten default satu jam dapat ditingkatkan dengan menggunakan proses peningkatan batas standar. Perhatikan bahwa meningkatkan waktu kedaluwarsa sesi dapat meningkatkan biaya pesan Anda karena waktu tambahan dapat memungkinkan lebih banyak pesan disimpan untuk perangkat offline dan pesan tambahan tersebut akan dibebankan ke akun Anda dengan tarif pesan standar. Waktu kedaluwarsa sesi adalah perkiraan dan sesi dapat bertahan hingga 30 menit lebih lama dari batas akun; Namun, sesi tidak akan lebih pendek dari batas akun. Untuk informasi selengkapnya tentang batas sesi, lihat AWS Service Quotas.

Pesan yang disimpan MQTT

AWS IoT Core mendukung flag REACH yang dijelaskan dalam protokol MQTT. Saat klien menyetel flag RETAIN pada pesan MQTT yang diterbitkannya, AWS IoT Core akan menyimpan pesan tersebut. Kemudian dapat dikirim ke pelanggan baru, diambil dengan memanggil GetRetainedMessageoperasi, dan dilihat di AWS IoT konsol.

Contoh menggunakan pesan yang dipertahankan MQTT
  • Sebagai pesan konfigurasi awal

    Pesan yang disimpan MQTT dikirim ke klien setelah klien berlangganan topik. Jika Anda ingin semua klien yang berlangganan topik menerima pesan yang disimpan MQTT tepat setelah langganan mereka, Anda dapat mempublikasikan pesan konfigurasi dengan set tanda RETAIN. Klien berlangganan juga menerima pembaruan konfigurasi itu setiap kali pesan konfigurasi baru diterbitkan.

  • Sebagai pesan status terakhir yang diketahui

    Perangkat dapat mengatur tanda RETAIN pada pesan status saat ini sehingga AWS IoT Core akan menyimpannya. Saat aplikasi terhubung atau terhubung kembali, mereka dapat berlangganan topik ini dan mendapatkan status terakhir yang dilaporkan segera setelah berlangganan topik pesan yang dipertahankan. Dengan cara ini mereka dapat menghindari keharusan menunggu hingga pesan berikutnya dari perangkat untuk melihat keadaan saat ini.

Tugas umum dengan pesan yang disimpan MQTT di AWS IoT Core

AWS IoT Core menyimpan pesan MQTT dengan set bendera RESTAIN. Pesan yang disimpan ini dikirim ke semua klien yang telah berlangganan topik, sebagai pesan MQTT normal, dan mereka juga disimpan untuk dikirim ke pelanggan baru ke topik tersebut.

Pesan yang disimpan MQTT memerlukan tindakan kebijakan khusus untuk memberi wewenang kepada klien untuk mengaksesnya. Untuk contoh penggunaan kebijakan pesan yang dipertahankan, lihatContoh kebijakan pesan yang dipertahankan.

Bagian ini menjelaskan operasi umum yang melibatkan pesan yang disimpan.

  • Membuat pesan yang disimpan

    Klien menentukan apakah pesan dipertahankan saat memublikasikan pesan MQTT. Klien dapat menyetel flag REACH saat memublikasikan pesan menggunakan Device SDK. Aplikasi dan layanan dapat mengatur tanda RETAIN saat mereka menggunakan Publishtindakan untuk mempublikasikan pesan MQTT.

    Hanya satu pesan per nama topik yang dipertahankan. Pesan baru dengan set tanda RETAIN yang dipublikasikan ke topik menggantikan pesan tertahan yang sudah ada yang dikirim ke topik sebelumnya.

    CATATAN: Anda tidak dapat memublikasikan ke topik yang dicadangkan dengan set tanda RETAIN.

  • Berlangganan topik pesan yang dipertahankan

    Klien berlangganan topik pesan yang dipertahankan seperti halnya topik pesan MQTT lainnya. Pesan yang disimpan yang diterima dengan berlangganan topik pesan yang dipertahankan memiliki tanda RETAIN disetel.

    Pesan yang disimpan akan dihapus dari AWS IoT Core saat klien menerbitkan pesan yang disimpan dengan muatan pesan 0-byte ke topik pesan yang dipertahankan. Klien yang telah berlangganan topik pesan yang dipertahankan juga akan menerima pesan 0-byte.

    Berlangganan filter topik wild card yang menyertakan topik pesan yang dipertahankan memungkinkan klien menerima pesan berikutnya yang dipublikasikan ke topik pesan yang disimpan, tetapi tidak mengirimkan pesan yang disimpan saat berlangganan.

    CATATAN: Untuk menerima pesan yang disimpan saat berlangganan, filter topik dalam permintaan langganan harus sama persis dengan topik pesan yang disimpan.

    Pesan yang disimpan yang diterima saat berlangganan topik pesan yang dipertahankan memiliki tanda RETAIN disetel. Pesan yang disimpan yang diterima oleh klien berlangganan setelah berlangganan, jangan.

  • Mengambil pesan yang disimpan

    Pesan yang disimpan dikirim ke klien secara otomatis ketika mereka berlangganan topik dengan pesan yang disimpan. Agar klien menerima pesan yang disimpan saat berlangganan, klien harus berlangganan nama topik yang tepat dari pesan yang disimpan. Berlangganan filter topik wild card yang menyertakan topik pesan yang dipertahankan memungkinkan klien menerima pesan berikutnya yang dipublikasikan ke topik pesan yang disimpan, tetapi tidak mengirimkan pesan yang disimpan saat berlangganan.

    Layanan dan aplikasi dapat mencantumkan dan mengambil pesan yang disimpan dengan menelepon ListRetainedMessagesdan. GetRetainedMessage

    Klien tidak dicegah untuk memublikasikan pesan ke topik pesan yang dipertahankan tanpa menyetel tanda RETAIN. Hal ini dapat menyebabkan hasil yang tidak terduga, seperti pesan yang disimpan tidak cocok dengan pesan yang diterima dengan berlangganan topik.

    Dengan MQTT 5, jika pesan yang disimpan memiliki Interval Kedaluwarsa Pesan yang disetel dan pesan yang disimpan kedaluwarsa, pelanggan baru yang berlangganan topik tersebut tidak akan menerima pesan yang disimpan setelah berlangganan berhasil.

  • Daftar topik pesan yang dipertahankan

    Anda dapat mencantumkan pesan yang disimpan dengan menelepon ListRetainedMessagesdan pesan yang disimpan dapat dilihat di konsol.AWS IoT

  • Mendapatkan detail pesan yang disimpan

    Anda bisa mendapatkan detail pesan yang disimpan dengan menelepon GetRetainedMessagedan mereka dapat dilihat di AWS IoT konsol.

  • Mempertahankan pesan Will

    MQTT Akan pesan yang dibuat ketika perangkat terhubung dapat dipertahankan dengan mengatur Will Retain bendera di bidang. Connect Flag bits

  • Menghapus pesan yang disimpan

    Perangkat, aplikasi, dan layanan dapat menghapus pesan yang disimpan dengan menerbitkan pesan dengan set tanda RETAIN dan muatan pesan kosong (0-byte) ke nama topik pesan yang disimpan untuk dihapus. Pesan semacam itu menghapus pesan yang disimpan dari AWS IoT Core, dikirim ke klien dengan berlangganan topik, tetapi tidak dipertahankan oleh. AWS IoT Core

    Pesan yang disimpan juga dapat dihapus secara interaktif dengan mengakses pesan yang disimpan di konsol.AWS IoT Pesan yang disimpan yang dihapus dengan menggunakan AWS IoT konsol juga mengirim pesan 0-byte ke klien yang telah berlangganan topik pesan yang dipertahankan.

    Pesan yang disimpan tidak dapat dipulihkan setelah dihapus. Klien perlu mempublikasikan pesan tertahan baru untuk menggantikan pesan yang dihapus.

  • Debugging dan pemecahan masalah pesan yang disimpan

    AWS IoT Konsol menyediakan beberapa alat untuk membantu Anda memecahkan masalah pesan yang disimpan:

    • Halaman pesan yang ditahan

      Halaman pesan yang disimpan di AWS IoT konsol menyediakan daftar paginasi pesan yang disimpan yang telah disimpan oleh Akun Anda di Wilayah saat ini. Dari halaman ini, Anda dapat:

      • Lihat detail setiap pesan yang disimpan, seperti payload pesan, QoS, waktu diterima.

      • Perbarui isi pesan yang disimpan.

      • Hapus pesan yang disimpan.

    • Klien uji MQTT

      Halaman klien pengujian MQTT di AWS IoT konsol dapat berlangganan dan mempublikasikan ke topik MQTT. Opsi terbitkan memungkinkan Anda menyetel tanda RETAIN pada pesan yang Anda terbitkan untuk mensimulasikan perilaku perangkat Anda.

    Beberapa hasil yang tidak terduga mungkin merupakan hasil dari aspek-aspek ini tentang bagaimana pesan yang disimpan diimplementasikan AWS IoT Core.

    • Batas pesan yang dipertahankan

      Ketika akun telah menyimpan jumlah maksimum pesan yang disimpan, AWS IoT Core mengembalikan respons terbatas ke pesan yang diterbitkan dengan set RETAIN dan muatan lebih besar dari 0 byte hingga beberapa pesan yang disimpan dihapus dan jumlah pesan yang dipertahankan turun di bawah batas.

    • Pesanan pengiriman pesan yang dipertahankan

      Urutan pesan yang disimpan dan pengiriman pesan berlangganan tidak dijamin.

Penagihan dan pesan yang disimpan

Menerbitkan pesan dengan tanda RETAIN yang disetel dari klien, menggunakan AWS IoT konsol, atau dengan menelepon Publishmenimbulkan biaya pesan tambahan yang dijelaskan dalam AWS IoT Core harga - Pesan.

Mengambil pesan yang disimpan oleh klien, dengan menggunakan AWS IoT konsol, atau dengan menelepon GetRetainedMessagemenimbulkan biaya pengiriman pesan selain biaya penggunaan API normal. Biaya tambahan dijelaskan dalam AWS IoT Core harga - Pesan.

MQTT Akan pesan yang dipublikasikan ketika perangkat terputus secara tak terduga dikenakan biaya pesan yang dijelaskan dalam harga - Pesan.AWS IoT Core

Untuk informasi selengkapnya tentang biaya pengiriman pesan, lihat AWS IoT Core harga - Pesan.

Membandingkan pesan yang dipertahankan MQTT dan sesi persisten MQTT

Pesan yang disimpan dan sesi persisten adalah fitur standar MQTT yang memungkinkan perangkat menerima pesan yang diterbitkan saat sedang offline. Pesan yang disimpan dapat dipublikasikan dari sesi persisten. Bagian ini menjelaskan aspek-aspek kunci dari fitur-fitur ini dan bagaimana mereka bekerja sama.

Pesan yang disimpan

Sesi persisten

Fitur utama

Pesan yang disimpan dapat digunakan untuk mengonfigurasi atau memberi tahu kelompok besar perangkat setelah terhubung.

Pesan yang disimpan juga dapat digunakan di mana Anda ingin perangkat hanya menerima pesan terakhir yang dipublikasikan ke topik setelah koneksi ulang.

Sesi persisten berguna untuk perangkat yang memiliki konektivitas intermiten dan dapat melewatkan beberapa pesan penting.

Perangkat dapat terhubung dengan sesi persisten untuk menerima pesan yang dikirim saat sedang offline.

Contoh

Pesan yang disimpan dapat memberikan informasi konfigurasi perangkat tentang lingkungan mereka ketika mereka online. Konfigurasi awal dapat mencakup daftar topik pesan lain yang harus berlangganan atau informasi tentang bagaimana seharusnya mengkonfigurasi zona waktu lokalnya.

Perangkat yang terhubung melalui jaringan seluler dengan konektivitas intermiten dapat menggunakan sesi persisten untuk menghindari hilangnya pesan penting yang dikirim saat perangkat berada di luar jangkauan jaringan atau perlu mematikan radio selulernya.

Pesan yang diterima saat berlangganan awal suatu topik

Setelah berlangganan topik dengan pesan yang disimpan, pesan tertahan terbaru diterima.

Setelah berlangganan topik tanpa pesan yang dipertahankan, tidak ada pesan yang diterima sampai seseorang dipublikasikan ke topik tersebut.

Topik berlangganan setelah koneksi ulang

Tanpa sesi persisten, klien harus berlangganan topik setelah koneksi ulang.

Topik berlangganan dipulihkan setelah koneksi ulang.

Pesan diterima setelah koneksi ulang

Setelah berlangganan topik dengan pesan yang disimpan, pesan tertahan terbaru diterima.

Semua pesan yang diterbitkan dengan QOS = 1 dan berlangganan dengan QOS =1 saat perangkat terputus dikirim setelah perangkat terhubung kembali.

Kedaluwarsa data/sesi

Di MQTT 3, pesan yang disimpan tidak kedaluwarsa. Mereka disimpan sampai diganti atau dihapus. Di MQTT 5, pesan yang disimpan akan kedaluwarsa setelah interval kedaluwarsa pesan yang Anda tetapkan. Untuk informasi selengkapnya, lihat Kedaluwarsa Pesan.

Sesi persisten kedaluwarsa jika klien tidak terhubung kembali dalam periode batas waktu. Setelah sesi persisten berakhir, langganan klien dan pesan tersimpan yang diterbitkan dengan QOS = 1 dan berlangganan dengan QOS =1 saat perangkat terputus akan dihapus. Pesan kedaluwarsa tidak akan terkirim. Untuk informasi selengkapnya tentang kedaluwarsa sesi dengan sesi persisten, lihat. Sesi persisten MQTT

Untuk informasi tentang sesi persisten, lihatSesi persisten MQTT.

Dengan Pesan Tertahan, klien penerbitan menentukan apakah pesan harus disimpan dan dikirim ke perangkat setelah tersambung, apakah pesan tersebut memiliki sesi sebelumnya atau tidak. Pilihan untuk menyimpan pesan dibuat oleh penerbit dan pesan yang disimpan dikirimkan ke semua klien saat ini dan masa depan yang berlangganan dengan langganan QoS 0 atau QoS 1. Pesan yang disimpan hanya menyimpan satu pesan pada topik tertentu pada satu waktu.

Ketika akun telah menyimpan jumlah maksimum pesan yang disimpan, AWS IoT Core mengembalikan respons terbatas ke pesan yang diterbitkan dengan set RETAIN dan muatan lebih besar dari 0 byte hingga beberapa pesan yang disimpan dihapus dan jumlah pesan yang dipertahankan turun di bawah batas.

MQTT menyimpan pesan dan Device Shadows AWS IoT

Pesan yang disimpan dan Device Shadows menyimpan data dari perangkat, tetapi berperilaku berbeda dan melayani tujuan yang berbeda. Bagian ini menjelaskan persamaan dan perbedaan mereka.

Pesan yang disimpan

Bayangan Perangkat

Payload pesan memiliki struktur atau skema yang telah ditentukan sebelumnya

 Seperti yang didefinisikan oleh implementasi. MQTT tidak menentukan struktur atau skema untuk muatan pesannya.

AWS IoT mendukung struktur data tertentu.

Memperbarui payload pesan menghasilkan pesan acara

 Menerbitkan pesan yang disimpan akan mengirimkan pesan ke klien berlangganan, tetapi tidak menghasilkan pesan pembaruan tambahan.

Memperbarui Device Shadow menghasilkan pesan pembaruan yang menjelaskan perubahan.

Pembaruan pesan diberi nomor

 Pesan yang disimpan tidak diberi nomor secara otomatis. Dokumen Device Shadow memiliki nomor versi otomatis dan stempel waktu.

Muatan pesan dilampirkan ke sumber daya benda

 Pesan yang disimpan tidak dilampirkan ke sumber daya sesuatu.

Device Shadows dilampirkan ke sumber daya benda.

Memperbarui elemen individual dari payload pesan

Elemen individual pesan tidak dapat diubah tanpa memperbarui seluruh payload pesan.

Elemen individual dari dokumen Device Shadow dapat diperbarui tanpa perlu memperbarui seluruh dokumen Device Shadow.

Klien menerima data pesan saat berlangganan

Klien secara otomatis menerima pesan yang disimpan setelah berlangganan topik dengan pesan yang disimpan.

Klien dapat berlangganan pembaruan Device Shadow, tetapi mereka harus meminta status saat ini dengan sengaja.

Pengindeksan dan kemampuan pencarian

Pesan yang disimpan tidak diindeks untuk pencarian.

Pengindeksan armada mengindeks data Device Shadow untuk pencarian dan agregasi.

Pesan MQTT Last Will and Testament (LWT)

Last Will and Testament (LWT) adalah fitur di MQTT. Dengan LWT, klien dapat menentukan pesan yang akan dipublikasikan broker ke topik yang ditentukan klien dan mengirimkannya ke semua klien yang berlangganan topik ketika pemutusan yang belum tahu terjadi. Pesan yang ditentukan klien disebut pesan LWT atau Pesan Will, dan topik yang ditentukan klien disebut sebagai Topik Will. Anda dapat menentukan pesan LWT saat perangkat terhubung ke broker. Pesan-pesan ini dapat dipertahankan dengan menyetel Will Retain bendera di Connect Flag bits bidang selama koneksi. Misalnya, jika Will Retain bendera disetel ke1, Pesan Will akan disimpan di broker di Topik Will terkait. Untuk informasi selengkapnya, lihat Akan Pesan.

Broker akan menyimpan Pesan Will sampai terjadi pemutusan yang belum diketahui. Ketika itu terjadi, broker akan mempublikasikan pesan ke semua klien yang berlangganan Topik Will untuk memberi tahu pemutusan. Jika klien terputus dari broker dengan pemutusan yang diprakarsai klien menggunakan pesan MQTT DISCONNECT, broker tidak akan mempublikasikan pesan LWT yang disimpan. Dalam semua kasus lain, pesan LWT akan dikirim. Untuk daftar lengkap skenario pemutusan saat broker akan mengirim pesan LWT, lihat peristiwa Hubungkan/Putuskan sambungan.

Menggunakan ConnectAttributes

ConnectAttributesmemungkinkan Anda untuk menentukan atribut apa yang ingin Anda gunakan dalam pesan connect Anda dalam kebijakan IAM Anda seperti PersistentConnect danLastWill. DenganConnectAttributes, Anda dapat membuat kebijakan yang tidak memberikan akses perangkat ke fitur baru secara default, yang dapat membantu jika perangkat dikompromikan.

connectAttributesmendukung fitur-fitur berikut:

PersistentConnect

Gunakan PersistentConnect fitur ini untuk menyimpan semua langganan yang dibuat klien selama koneksi ketika koneksi antara klien dan broker terputus.

LastWill

Gunakan LastWill fitur ini untuk mempublikasikan pesan ke LastWillTopic saat klien tiba-tiba terputus.

Secara default, kebijakan Anda memiliki koneksi non-persisten dan tidak ada atribut yang diteruskan untuk koneksi ini. Anda harus menentukan koneksi persisten dalam kebijakan IAM Anda jika Anda ingin memilikinya.

Untuk ConnectAttributes contoh, lihat Connect Policy Examples.

Fitur yang didukung MQTT 5

AWS IoT Core dukungan untuk MQTT 5 didasarkan pada spesifikasi MQTT v5.0 dengan beberapa perbedaan seperti yang didokumentasikan dalam. AWS IoT perbedaan dari spesifikasi MQTT

Langganan Bersama

AWS IoT Core mendukung Langganan Bersama untuk MQTT 3 dan MQTT 5. Langganan Bersama memungkinkan beberapa klien untuk berbagi langganan ke suatu topik dan hanya satu klien yang akan menerima pesan yang dipublikasikan ke topik tersebut menggunakan distribusi acak. Langganan Bersama dapat secara efektif memuat pesan MQTT saldo di sejumlah pelanggan. Misalnya, Anda memiliki 1.000 perangkat yang menerbitkan topik yang sama, dan 10 aplikasi backend yang memproses pesan tersebut. Dalam hal ini, aplikasi backend dapat berlangganan topik yang sama dan masing-masing akan secara acak menerima pesan yang diterbitkan oleh perangkat ke topik bersama. Ini secara efektif “berbagi” beban pesan-pesan itu. Langganan Bersama juga memungkinkan ketahanan yang lebih baik. Ketika aplikasi backend terputus, broker mendistribusikan beban ke pelanggan yang tersisa dalam grup.

Untuk menggunakan Langganan Bersama, klien berlangganan filter topik Langganan Bersama sebagai berikut:

$share/{ShareName}/{TopicFilter}

  • $shareadalah string literal untuk menunjukkan filter topik Berlangganan Bersama, yang harus dimulai dengan$share.

  • {ShareName}adalah string karakter untuk menentukan nama bersama yang digunakan oleh sekelompok pelanggan. Filter topik Langganan Bersama harus berisi ShareName dan diikuti oleh / karakter. Tidak {ShareName} boleh menyertakan karakter berikut:/,+, atau#. Ukuran maksimum untuk {ShareName} adalah 128 byte.

  • {TopicFilter}mengikuti sintaks filter topik yang sama dengan Langganan Non-Shared. Ukuran maksimum untuk {TopicFilter} adalah 256 byte.

  • Dua garis miring yang diperlukan (/) untuk $share/{ShareName}/{TopicFilter} tidak termasuk dalam Jumlah garis miring maksimum dalam batas filter topik dan topik.

Langganan yang memiliki hal yang sama {ShareName}/{TopicFilter} termasuk dalam grup Berlangganan Bersama yang sama. Anda dapat membuat beberapa grup Langganan Bersama dan tidak melebihi batas Langganan Bersama per grup. Untuk informasi selengkapnya, lihat AWS IoT Core titik akhir dan kuota dari Referensi AWS Umum.

Tabel berikut membandingkan Langganan Non-Bersama dan Langganan Bersama:

Langganan Deskripsi Contoh filter topik
Langganan yang tidak dibagikan Setiap klien membuat langganan terpisah untuk menerima pesan yang dipublikasikan. Saat pesan dipublikasikan ke suatu topik, semua pelanggan topik tersebut menerima salinan pesan tersebut. 
sports/tennis
sports/#
Langganan Bersama Beberapa klien dapat berbagi langganan ke topik dan hanya satu klien yang akan menerima pesan yang dipublikasikan ke topik itu pada distribusi acak. 
$share/consumer/sports/tennis
$share/consumer/sports/#
Alur Langganan yang tidak dibagikan Alur Langganan Bersama
Langganan reguler untuk MQTT 3 dan MQTT 5 in. AWS IoT Core
Langganan bersama untuk MQTT 3 dan MQTT 5 in. AWS IoT Core

Catatan penting untuk menggunakan Langganan Bersama

  • Ketika upaya publikasi ke pelanggan QoS0 gagal, tidak ada upaya coba lagi yang akan terjadi, dan pesan akan dihapus.

  • Ketika upaya publikasi ke pelanggan QoS1 dengan sesi bersih gagal, pesan akan dikirim ke pelanggan lain dalam grup untuk beberapa upaya coba lagi. Pesan yang gagal dikirimkan setelah semua upaya coba lagi akan dibatalkan.

  • Ketika upaya publikasi ke pelanggan QoS1 dengan sesi persisten gagal karena pelanggan sedang offline, pesan tidak akan antri dan akan dicoba ke pelanggan lain dalam grup. Pesan yang gagal dikirimkan setelah semua upaya coba lagi akan dibatalkan.

  • Langganan Bersama tidak menerima pesan yang disimpan.

  • Jika Langganan Bersama berisi karakter wildcard (# atau +), mungkin ada beberapa Langganan Bersama yang cocok dengan topik. Jika itu terjadi, broker pesan menyalin pesan penerbitan dan mengirimkannya ke klien acak di setiap Langganan Bersama yang cocok. Perilaku wildcard Langganan Bersama dapat dijelaskan dalam diagram berikut.

    Langganan bersama dengan karakter wildcard di. AWS IoT Core

    Dalam contoh ini, ada tiga Langganan Bersama yang cocok dengan topik MQTT penerbitan. sports/tennis Broker pesan menyalin pesan yang diterbitkan dan mengirim pesan ke klien acak di setiap grup yang cocok.

    Klien 1 dan klien 2 berbagi langganan: $share/consumer1/sports/tennis

    Klien 3 dan klien 4 berbagi langganan: $share/consumer1/sports/#

    Klien 5 dan klien 6 berbagi langganan: $share/consumer2/sports/tennis

Untuk informasi selengkapnya tentang batas Langganan Bersama, lihat AWS IoT Core titik akhir dan kuota dari Referensi Umum.AWS Untuk menguji Langganan Bersama menggunakan klien AWS IoT MQTT di konsol, lihat.AWS IoT Menguji Langganan Bersama di klien MQTT Untuk informasi selengkapnya tentang Langganan Bersama, lihat Langganan Bersama dari spesifikasi MQTTv5.0.

Mulai Bersih dan Kedaluwarsa Sesi

Anda dapat menggunakan Clean Start dan Session Expiry untuk menangani sesi persisten Anda dengan lebih fleksibel. Bendera Mulai Bersih menunjukkan apakah sesi harus dimulai tanpa menggunakan sesi yang ada. Interval Kedaluwarsa Sesi menunjukkan berapa lama untuk mempertahankan sesi setelah pemutusan. Interval kedaluwarsa sesi dapat dimodifikasi pada saat pemutusan. Untuk informasi selengkapnya, lihat Sesi persisten MQTT.

Kode Alasan pada semua ACK

Anda dapat men-debug atau memproses pesan kesalahan dengan lebih mudah menggunakan kode alasan. Kode alasan dikembalikan oleh broker pesan berdasarkan jenis interaksi dengan broker (Berlangganan, Publikasikan, Akui). Untuk informasi lebih lanjut, lihat kode alasan MQTT. Untuk daftar lengkap kode alasan MQTT, lihat Spesifikasi MQTT v5.

Alias Topik

Anda dapat mengganti nama topik dengan alias topik, yang merupakan bilangan bulat dua byte. Menggunakan alias topik dapat mengoptimalkan transmisi nama topik untuk berpotensi mengurangi biaya data pada layanan data terukur. AWS IoT Core memiliki batas default 8 alias topik. Untuk informasi selengkapnya, lihat AWS IoT Core titik akhir dan kuota dari Referensi AWS Umum.

Kedaluwarsa Pesan

Anda dapat menambahkan nilai kedaluwarsa pesan ke pesan yang dipublikasikan. Nilai-nilai ini mewakili interval kedaluwarsa pesan dalam hitungan detik. Jika pesan belum dikirim ke pelanggan dalam interval tersebut, pesan akan kedaluwarsa dan dihapus. Jika Anda tidak menyetel nilai kedaluwarsa pesan, pesan tidak akan kedaluwarsa.

Pada outbound, pelanggan akan menerima pesan dengan sisa waktu yang tersisa dalam interval kedaluwarsa. Misalnya, jika pesan publikasi masuk memiliki pesan kedaluwarsa 30 detik, dan dialihkan ke pelanggan setelah 20 detik, bidang kedaluwarsa pesan akan diperbarui menjadi 10. Dimungkinkan untuk pesan yang diterima oleh pelanggan untuk memiliki MEI yang diperbarui sebesar 0. Ini karena segera setelah waktu yang tersisa adalah 999 ms atau kurang, itu akan diperbarui ke 0.

Dalam AWS IoT Core, interval kedaluwarsa pesan minimum adalah 1. Jika interval diatur ke 0 dari sisi klien, itu akan disesuaikan ke 1. Interval kadaluwarsa pesan maksimum adalah 604800 (7 hari). Nilai apa pun yang lebih tinggi dari ini akan disesuaikan dengan nilai maksimum.

Dalam komunikasi lintas versi, perilaku kedaluwarsa pesan ditentukan oleh versi MQTT dari pesan publikasi masuk. Misalnya, pesan dengan kedaluwarsa pesan yang dikirim oleh sesi yang terhubung melalui MQTT5 dapat kedaluwarsa untuk perangkat yang berlangganan sesi MQTT3. Tabel di bawah ini mencantumkan cara kedaluwarsa pesan mendukung jenis pesan publikasi berikut:

Publikasikan Jenis Pesan Interval Kedaluwarsa Pesan
Publikasikan Reguler Jika server gagal mengirimkan pesan dalam waktu yang ditentukan, pesan yang kedaluwarsa akan dihapus dan pelanggan tidak akan menerimanya. Ini termasuk situasi seperti ketika perangkat tidak mempublikasikan pesan QoS 1 mereka.
Mempertahankan Jika pesan yang disimpan kedaluwarsa dan klien baru berlangganan topik, klien tidak akan menerima pesan saat berlangganan.
Kehendak Terakhir Interval untuk pesan terakhir akan dimulai setelah klien terputus dan server mencoba mengirimkan pesan wasiat terakhir kepada pelanggannya.
Pesan antrian Jika QoS1 keluar dengan Interval Kedaluwarsa Pesan kedaluwarsa saat klien offline, setelah sesi persisten dilanjutkan, klien tidak akan menerima pesan kedaluwarsa.

Fitur MQTT 5 lainnya

Putuskan sambungan server

Ketika pemutusan terjadi, server dapat secara proaktif mengirim klien DISCONNECT untuk memberi tahu penutupan koneksi dengan kode alasan untuk pemutusan.

Permintaan/Tanggapan

Penayang dapat meminta tanggapan dikirim oleh penerima ke topik yang ditentukan penerbit pada saat penerimaan.

Ukuran Paket Maksimum

Klien dan Server dapat secara independen menentukan ukuran paket maksimum yang mereka dukung.

Format payload dan jenis konten

Anda dapat menentukan format payload (biner, teks) dan jenis konten saat pesan dipublikasikan. Ini diteruskan ke penerima pesan.

MQTT 5 properti

Properti MQTT 5 adalah tambahan penting untuk standar MQTT untuk mendukung fitur MQTT 5 baru seperti Session Expiry dan pola Permintaan/Respons. Di AWS IoT Core, Anda dapat membuat aturan yang dapat meneruskan properti dalam pesan keluar, atau menggunakan HTTP Publish untuk mempublikasikan pesan MQTT dengan beberapa properti baru.

Tabel berikut mencantumkan semua properti MQTT 5 yang mendukung. AWS IoT Core

Properti Deskripsi Jenis masukan Paket
Indikator Format Muatan Nilai boolean yang menunjukkan apakah payload diformat sebagai UTF-8. Byte TERBITKAN, SAMBUNGKAN
Jenis Konten String UTF-8 yang menggambarkan isi muatan. Tali UTF-8 TERBITKAN, SAMBUNGKAN
Topik Respon String UTF-8 yang menjelaskan topik yang harus dipublikasikan oleh penerima sebagai bagian dari alur permintaan-respons. Topik tidak boleh memiliki karakter wildcard. Tali UTF-8 TERBITKAN, SAMBUNGKAN
Data Korelasi Data biner yang digunakan oleh pengirim pesan permintaan untuk mengidentifikasi permintaan pesan respons. Biner TERBITKAN, SAMBUNGKAN
Properti Pengguna Pasangan string UTF-8. Properti ini dapat muncul beberapa kali dalam satu paket. Penerima akan menerima pasangan kunci-nilai dalam urutan yang sama dengan yang dikirim. Pasangan string UTF-8 HUBUNGKAN, PUBLIKASIKAN, Akan Properti, BERLANGGANAN, PUTUSKAN SAMBUNGAN, BERHENTI BERLANGGANAN
Interval Kedaluwarsa Pesan Integer 4-byte yang mewakili interval kedaluwarsa pesan dalam hitungan detik. Jika tidak ada, pesan tidak kedaluwarsa. Bilangan bulat 4-byte TERBITKAN, SAMBUNGKAN
Interval Kedaluwarsa Sesi

Integer 4-byte yang mewakili interval kedaluwarsa sesi dalam hitungan detik. AWS IoT Core mendukung maksimal 7 hari, dengan default maksimal satu jam. Jika nilai yang Anda tetapkan melebihi maksimum akun Anda, AWS IoT Core akan mengembalikan nilai yang disesuaikan di CONNACK.

 Bilangan bulat 4-byte SAMBUNGKAN, SAMBUNGKAN, PUTUSKAN SAMBUNGAN
Pengenal Klien yang Ditugaskan ID klien acak yang dihasilkan AWS IoT Core ketika ID klien tidak ditentukan oleh perangkat. ID klien acak harus merupakan pengidentifikasi klien baru yang tidak digunakan oleh sesi lain yang saat ini dikelola oleh broker. Tali UTF-8 CONNACK
Server Tetap Hidup Sebuah integer 2-byte yang mewakili keep alive time yang ditetapkan oleh server. Server akan memutuskan koneksi klien jika klien tidak aktif selama lebih dari waktu tetap hidup. Bilangan bulat 2 byte CONNACK
Minta Informasi Masalah Nilai boolean yang menunjukkan apakah Reason String atau User Properties dikirim dalam kasus kegagalan. Byte MENGHUBUNG
Menerima Maksimum Bilangan bulat 2-byte yang mewakili jumlah maksimum paket PUBLISH QOS> 0 yang dapat dikirim tanpa menerima PUBACK. Bilangan bulat 2 byte SAMBUNGKAN, CONNACK
Topik Alias Maksimum Nilai ini menunjukkan nilai tertinggi yang akan diterima sebagai Alias Topik. Default-nya adalah 0. Bilangan bulat 2 byte SAMBUNGKAN, CONNACK
QoS Maksimum Nilai maksimum QoS yang AWS IoT Core mendukung. Defaultnya adalah 1. AWS IoT Core tidak mendukung QoS2. Byte CONNACK
Pertahankan Tersedia

Nilai boolean yang menunjukkan apakah broker AWS IoT Core pesan mendukung pesan yang disimpan. Default-nya adalah 1.

 Byte CONNACK
Ukuran Paket Maksimum Ukuran paket maksimum yang AWS IoT Core menerima dan mengirim. Tidak dapat melebihi 128KB. Bilangan bulat 4-byte SAMBUNGKAN, CONNACK
Berlangganan Wildcard Tersedia

Nilai boolean yang menunjukkan apakah broker AWS IoT Core pesan mendukung Langganan Wildcard Tersedia. Default-nya adalah 1.

 Byte CONNACK
Pengenal Berlangganan Tersedia

Nilai boolean yang menunjukkan apakah broker AWS IoT Core pesan mendukung Pengenal Langganan Tersedia. Default-nya adalah 0.

 Byte CONNACK

Kode alasan MQTT

MQTT 5 memperkenalkan pelaporan kesalahan yang ditingkatkan dengan respons kode alasan. AWS IoT Core dapat mengembalikan kode alasan termasuk tetapi tidak terbatas pada berikut dikelompokkan berdasarkan paket. Untuk daftar lengkap kode alasan yang didukung oleh MQTT 5, lihat spesifikasi MQTT 5.

Kode Alasan CONNACK
Nilai Hex Nama Kode Alasan Deskripsi
0 0x00 Berhasil Koneksi diterima.
128 0x80 Kesalahan yang tidak ditentukan Server tidak ingin mengungkapkan alasan kegagalan, atau tidak ada kode alasan lain yang berlaku.
133 0x85 Client Identifier tidak valid Pengidentifikasi klien adalah string yang valid tetapi tidak diizinkan oleh server.
134 0x86 Nama Pengguna atau Kata Sandi Buruk Server tidak menerima nama pengguna atau kata sandi yang ditentukan oleh klien.
135 0x87 Tidak diotorisasi Klien tidak berwenang untuk terhubung.
144 0x90 Nama Topik tidak valid Nama Topik Will dibentuk dengan benar tetapi tidak diterima oleh server.
151 0x97 Kuota terlampaui Batas implementasi atau administrasi yang diberlakukan telah terlampaui.
155 0x9B QoS tidak didukung Server tidak mendukung QoS yang ditetapkan di Will QoS.
Kode Alasan PUBACK
Nilai Hex Nama Kode Alasan Deskripsi
0 0x00 Berhasil Pesan diterima. Publikasi pesan QoS 1 berlangsung.
128 0x80 Kesalahan yang tidak ditentukan Penerima tidak menerima publikasi, tetapi tidak ingin mengungkapkan alasannya, atau tidak cocok dengan salah satu nilai lainnya.
135 0x87 Tidak diotorisasi PUBLISH tidak diotorisasi.
144 0x90 Nama Topik tidak valid Nama topik tidak cacat, tetapi tidak diterima oleh klien atau server.
145 0x91 Pengenal paket yang digunakan Packet identifier sudah digunakan. Ini mungkin menunjukkan ketidakcocokan dalam keadaan sesi antara klien dan server.
151 0x97 Kuota terlampaui Batas implementasi atau administrasi yang diberlakukan telah terlampaui.
PUTUSKAN Kode Alasan
Nilai Hex Nama Kode Alasan Deskripsi
129 0x81 Paket cacat Paket yang diterima tidak sesuai dengan spesifikasi ini.
130 0x82 Kesalahan Protokol Paket yang tidak terduga atau rusak diterima.
135 0x87 Tidak diotorisasi Permintaan tidak diizinkan.
139 0x8B Server dimatikan Server dimatikan.
141 0x8D Keep Alive timeout Koneksi ditutup karena tidak ada paket yang diterima selama 1,5 kali waktu Keep Alive.
142 0x8E Sesi diambil alih Koneksi lain menggunakan clientID yang sama telah terhubung, menyebabkan koneksi ini ditutup.
143 0x8F Filter Topik tidak valid Filter topik dibentuk dengan benar tetapi tidak diterima oleh server.
144 0x90 Nama Topik tidak valid Nama topik dibentuk dengan benar tetapi tidak diterima oleh klien atau server ini.
147 0x93 Menerima maksimum terlampaui Klien atau server telah menerima lebih dari publikasi Terima Maksimum yang belum dikirim PUBACK atau PUBCOMP.
148 0x94 Topik Alias tidak valid Klien atau server telah menerima paket PUBLISH yang berisi alias topik yang lebih besar dari Alias Topik Maksimum yang dikirim dalam paket CONNECT atau CONNACK.
151 0x97 Kuota terlampaui Batas implementasi atau administrasi yang diberlakukan telah terlampaui.
152 0x98 Tindakan administratif Koneksi ditutup karena tindakan administratif.
155 0x9B QoS tidak didukung Klien menentukan QoS lebih besar dari QoS yang ditentukan dalam QoS Maksimum di CONNACK.
161 0xA1 Pengidentifikasi Langganan tidak didukung Server tidak mendukung pengidentifikasi langganan; langganan tidak diterima.
Kode Alasan SUBACK
Nilai Hex Nama Kode Alasan Deskripsi
0 0x00 Diberikan QoS 0 Langganan diterima dan QoS maksimum yang dikirim adalah QoS 0. Ini mungkin QoS yang lebih rendah dari yang diminta.
1 0x01 Diberikan QoS 1 Langganan diterima dan QoS maksimum yang dikirim adalah QoS 1. Ini mungkin QoS yang lebih rendah dari yang diminta.
128 0x80 Kesalahan yang tidak ditentukan Langganan tidak diterima dan Server tidak ingin mengungkapkan alasan atau tidak ada Kode Alasan lainnya yang berlaku.
135 0x87 Tidak diotorisasi Klien tidak berwenang untuk membuat langganan ini.
143 0x8F Filter Topik tidak valid Filter Topik dibentuk dengan benar tetapi tidak diizinkan untuk Klien ini.
145 0x91 Packet Identifier sedang digunakan Packet Identifier yang ditentukan sudah digunakan.
151 0x97 Kuota terlampaui Batas implementasi atau administrasi yang diberlakukan telah terlampaui.
Kode Alasan UNSUBACK
Nilai Hex Nama Kode Alasan Deskripsi
0 0x00 Berhasil Langganan dihapus.
128 0x80 Kesalahan yang tidak ditentukan Berhenti berlangganan tidak dapat diselesaikan dan Server tidak ingin mengungkapkan alasan atau tidak ada Kode Alasan lainnya yang berlaku.
143 0x8F Filter Topik tidak valid Filter Topik dibentuk dengan benar tetapi tidak diizinkan untuk Klien ini.
145 0x91 Packet Identifier sedang digunakan Packet Identifier yang ditentukan sudah digunakan.

AWS IoT perbedaan dari spesifikasi MQTT

Implementasi broker pesan didasarkan pada spesifikasi MQTT v3.1.1 dan spesifikasi MQTT v5.0, tetapi berbeda dari spesifikasi dengan cara ini:

  • AWS IoT tidak mendukung paket berikut untuk MQTT 3: PUBREC, PUBREL, dan PUBCOMP.

  • AWS IoT tidak mendukung paket berikut untuk MQTT 5: PUBREC, PUBREL, PUBCOMP, dan AUTH.

  • AWS IoT tidak mendukung pengalihan server MQTT 5.

  • AWS IoT mendukung kualitas layanan MQTT (QoS) level 0 dan 1 saja. AWS IoT tidak mendukung penerbitan atau berlangganan dengan QoS level 2. Ketika QoS level 2 diminta, broker pesan tidak mengirim PUBACK atau SUBACK.

  • Di AWS IoT, berlangganan topik dengan QoS level 0 berarti pesan dikirim nol kali atau lebih. Sebuah pesan dapat disampaikan lebih dari satu kali. Pesan yang dikirim lebih dari satu kali dapat dikirim dengan ID paket yang berbeda. Dalam kasus ini, bendera DUP tidak disetel.

  • Saat menanggapi permintaan koneksi, broker pesan mengirim pesan CONNACK. Pesan ini berisi bendera untuk menunjukkan apakah koneksi melanjutkan sesi sebelumnya.

  • Sebelum mengirim paket kontrol tambahan atau permintaan pemutusan sambungan, klien harus menunggu pesan CONNACK diterima di perangkat mereka dari broker pesan. AWS IoT

  • Ketika klien berlangganan topik, mungkin ada penundaan antara waktu broker pesan mengirim SUBACK dan waktu klien mulai menerima pesan baru yang cocok.

  • Saat klien menggunakan karakter wildcard # dalam filter topik untuk berlangganan topik, semua string di dan di bawah levelnya dalam hierarki topik akan dicocokkan. Namun, topik induk tidak cocok. Misalnya, langganan topik sensor/# menerima pesan yang dipublikasikan ke topiksensor/, sensor/temperaturesensor/temperature/room1, tetapi bukan pesan yang dipublikasikan kesensor. Untuk informasi selengkapnya tentang wildcard, lihatFilter topik.

  • Broker pesan menggunakan ID klien untuk mengidentifikasi setiap klien. ID klien diteruskan dari klien ke broker pesan sebagai bagian dari muatan MQTT. Dua klien dengan ID klien yang sama tidak dapat dihubungkan secara bersamaan ke broker pesan. Ketika klien terhubung ke broker pesan menggunakan ID klien yang digunakan klien lain, koneksi klien baru diterima dan klien yang terhubung sebelumnya terputus.

  • Pada kesempatan yang jarang terjadi, broker pesan mungkin mengirim ulang pesan PUBLISH logis yang sama dengan ID paket yang berbeda.

  • Berlangganan filter topik yang berisi karakter wildcard tidak dapat menerima pesan yang disimpan. Untuk menerima pesan yang disimpan, permintaan berlangganan harus berisi filter topik yang sama persis dengan topik pesan yang disimpan.

  • Broker pesan tidak menjamin urutan pesan dan ACK diterima.

  • AWS IoT mungkin memiliki batasan yang berbeda dari spesifikasi. Untuk informasi lebih lanjut, lihat broker AWS IoT Core pesan dan batas protokol dan kuota dari Panduan AWS IoT Referensi.

  • Bendera DUP MQTT tidak didukung.