MQTT - AWS IoT Core
Menghubungkan dengan MQTT menggunakan AWS IoT Perangkat SDKsMQTTOpsi Kualitas Layanan (QoS)MQTTsesi persistenMQTTpesan yang disimpanMQTTPesan Wasiat dan Perjanjian Terakhir (LWT)Menggunakan connectAttributesMQTT5 fitur yang didukungMQTT5 propertiMQTTkode alasanAWS IoT perbedaan dari MQTT spesifikasi

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 MQTTv3.1.1 dan spesifikasi MQTT v5.0, dengan beberapa perbedaan, seperti yang didokumentasikan dalam. AWS IoT perbedaan dari MQTT spesifikasi Sebagai versi terbaru dari standar, MQTT 5 memperkenalkan beberapa fitur utama yang membuat sistem MQTT berbasis 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 MQTT 5 fitur yang AWS IoT Core mendukung, lihat MQTT5 fitur yang didukung. AWS IoT Core juga mendukung komunikasi lintas MQTT versi (MQTT3 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 MQTT protokol dan MQTT over WSS protocol dan yang diidentifikasi oleh ID klien. AWS IoT Perangkat SDKsDukungan kedua protokol dan merupakan cara yang disarankan untuk menghubungkan perangkat ke. AWS IoT Core AWS IoT Perangkat SDKs mendukung fungsi yang diperlukan untuk perangkat dan klien untuk terhubung dan mengakses AWS IoT layanan. Perangkat SDKs mendukung protokol otentikasi yang diperlukan AWS IoT layanan dan persyaratan ID koneksi yang diperlukan oleh MQTT protokol dan MQTT lebih dari WSS protokol. Untuk informasi tentang cara menyambung AWS IoT menggunakan AWS Perangkat SDKs dan menautkan ke contoh AWS IoT dalam bahasa yang didukung, lihatMenghubungkan dengan MQTT menggunakan AWS IoT Perangkat SDKs. Untuk informasi selengkapnya tentang metode otentikasi dan pemetaan port untuk MQTT pesan, lihat. Protokol, pemetaan port, dan otentikasi

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

Menghubungkan dengan MQTT menggunakan AWS IoT Perangkat SDKs

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

catatan

AWS IoT Perangkat SDKs telah merilis klien MQTT 5.

C++

Menggunakan Perangkat AWS IoT C ++ SDK untuk menghubungkan perangkat

Python

Menggunakan AWS IoT Perangkat SDK untuk Python untuk menghubungkan perangkat

JavaScript

Menggunakan AWS IoT Perangkat SDK JavaScript untuk menghubungkan perangkat

Java

Menggunakan AWS IoT Perangkat SDK untuk Java untuk menghubungkan perangkat

catatan

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

Embedded C

Menggunakan AWS IoT Perangkat SDK untuk Embedded C untuk menghubungkan perangkat

penting

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

MQTTOpsi Kualitas Layanan (QoS)

AWS IoT dan AWS IoT Perangkat SDKs mendukung tingkat MQTT 0 Kualitas Layanan (QoS) dan. 1 MQTTProtokol mendefinisikan tingkat ketiga QoS, 2 level, AWS IoT tetapi tidak mendukungnya. Hanya MQTT protokol yang mendukung fitur QoS. HTTPSmendukung QoS dengan melewatkan 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 berhasil.

MQTTsesi persisten

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 MQTT persisten dengan mengirim CONNECT pesan dan menyetel cleanSession bendera ke0. 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.

Dalam MQTT 5, Anda menangani sesi persisten dengan menyetel Clean Start bendera danSession 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 CONNECT pesan, defaultnya adalah 0.

MQTT5 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 Session Expiry Interval = 1 dan =0, ini setara dengan MQTT 3 sesi bersih. Jika Anda mengatur Clean Start = 0 dan Session Expiry Interval >0, ini setara dengan sesi persisten MQTT 3.

catatan

Sesi persisten MQTT versi silang (MQTT3 dan MQTT 5) 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 setiap 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 MQTT pesan. 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. Dalam MQTT 5, jika QoS1 keluar dengan Interval Kedaluwarsa Pesan kedaluwarsa 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.

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

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

Untuk Interval Kedaluwarsa Sesi pada DISCONNECT paket:

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

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

  • Jika tidak, Interval Kedaluwarsa Sesi pada DISCONNECT paket akan memperbarui Interval Kedaluwarsa Sesi dari 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 berakhir, 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.

MQTTpesan yang disimpan

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

Contoh menggunakan pesan MQTT yang disimpan
  • Sebagai pesan konfigurasi awal

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

  • Sebagai pesan status terakhir yang diketahui

    Perangkat dapat mengatur RETAIN bendera 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 MQTT disimpan di AWS IoT Core

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

MQTTPesan yang disimpan 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 RETAIN bendera saat mereka memublikasikan pesan dengan menggunakan Perangkat SDK. Aplikasi dan layanan dapat mengatur RETAIN bendera saat mereka menggunakan Publishtindakan untuk mempublikasikan MQTT pesan.

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

    NOTE: Anda tidak dapat memublikasikan ke topik yang dicadangkan dengan set RETAIN bendera.

  • Berlangganan topik pesan yang dipertahankan

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

    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.

    NOTE: 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 yang disetel. RETAIN 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 RETAIN bendera. 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

    MQTTApakah pesan yang dibuat saat perangkat terhubung dapat dipertahankan dengan mengatur Will Retain bendera di Connect Flag bits bidang.

  • Menghapus pesan yang disimpan

    Perangkat, aplikasi, dan layanan dapat menghapus pesan yang disimpan dengan menerbitkan pesan dengan RETAIN tanda set 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 disimpan

      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 MQTT uji

      Halaman klien MQTT pengujian di AWS IoT konsol dapat berlangganan dan mempublikasikan MQTT topik. Opsi terbitkan memungkinkan Anda menyetel RETAIN tanda 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 RETAIN set dan muatan lebih besar dari 0 byte hingga beberapa pesan yang disimpan dihapus dan jumlah pesan yang dipertahankan jatuh 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 RETAIN tanda 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 normal. API Biaya tambahan dijelaskan dalam AWS IoT Core harga - Pesan.

MQTTApakah pesan yang dipublikasikan saat perangkat terputus secara tak terduga akan dikenakan biaya pengiriman pesan yang dijelaskan dalam AWS IoT Core harga - Pesan.

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

MQTTMembandingkan pesan yang disimpan dan sesi MQTT persisten

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 a QOS = 1 dan berlangganan dengan QOS =1 saat perangkat terputus dikirim setelah perangkat terhubung kembali.

Kedaluwarsa data/sesi

Dalam MQTT 3, pesan yang disimpan tidak kedaluwarsa. Mereka disimpan sampai diganti atau dihapus. Dalam 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 a 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. MQTTsesi persisten

Untuk informasi tentang sesi persisten, lihatMQTTsesi persisten.

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 RETAIN set dan muatan lebih besar dari 0 byte hingga beberapa pesan yang disimpan dihapus dan jumlah pesan yang dipertahankan jatuh di bawah batas.

MQTTpesan yang disimpan dan AWS IoT Device Shadows

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. MQTTtidak 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.

MQTTPesan Wasiat dan Perjanjian Terakhir (LWT)

Kehendak Terakhir dan Perjanjian (LWT) adalah fitur diMQTT. DenganLWT, klien dapat menentukan pesan yang akan dipublikasikan broker ke topik yang ditentukan klien dan mengirim ke semua klien yang berlangganan topik ketika pemutusan yang belum tahu terjadi. Pesan yang ditentukan klien disebut LWT pesan atau Pesan Will, dan topik yang ditentukan klien disebut sebagai Topik Will. Anda dapat menentukan LWT pesan 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 koneksi yang diprakarsai klien menggunakan MQTT DISCONNECT pesan, broker tidak akan mempublikasikan pesan yang disimpan. LWT Dalam semua kasus lain, LWT pesan akan dikirim. Untuk daftar lengkap skenario pemutusan saat broker akan mengirim LWT pesan, lihat acara Hubungkan/Putuskan sambungan.

Menggunakan connectAttributes

ConnectAttributesmemungkinkan Anda untuk menentukan atribut apa yang ingin Anda gunakan dalam pesan connect Anda dalam IAM kebijakan 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 IAM kebijakan Anda jika ingin memilikinya.

Untuk ConnectAttributes contoh, lihat Connect Policy Examples.

MQTT5 fitur yang didukung

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

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 MQTT pesan saldo di sejumlah pelanggan. Misalnya, Anda memiliki 1.000 perangkat yang menerbitkan topik yang sama, dan 10 aplikasi backend 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 sama {ShareName}/{TopicFilter} termasuk dalam grup Langganan 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 inci. AWS IoT Core
Langganan bersama untuk MQTT 3 dan MQTT 5 inci. 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 dikirim 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 dikirim 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 MQTT topik sports/tennis penerbitan. 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 AWS IoT MQTT klien di AWS IoT konsol, lihatMenguji Langganan Bersama di klien MQTT. Untuk informasi selengkapnya tentang Langganan Bersama, lihat Langganan Bersama dari MQTTv5 spesifikasi.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 saat pemutusan. Untuk informasi selengkapnya, lihat MQTTsesi persisten.

Kode Alasan pada semua ACKs

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 MQTT alasan. Untuk daftar lengkap kode MQTT alasan, 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 memiliki pembaruan MEI 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 MQTT versi 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.

MQTT5 fitur lainnya

Putuskan sambungan server

Ketika pemutusan terjadi, server dapat secara proaktif mengirim klien DISCONNECT untuk memberitahukan 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.

MQTT5 properti

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

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

Properti Deskripsi Jenis masukan Paket
Indikator Format Muatan Nilai boolean yang menunjukkan apakah payload diformat sebagai -8. UTF Byte PUBLISH, CONNECT
Jenis Konten String UTF -8 yang menjelaskan isi muatan. UTF-8 string PUBLISH, CONNECT
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. UTF-8 string PUBLISH, CONNECT
Data Korelasi Data biner yang digunakan oleh pengirim pesan permintaan untuk mengidentifikasi permintaan pesan respons. Biner PUBLISH, CONNECT
Properti Pengguna Sepasang 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. UTF-8 pasangan string CONNECT,PUBLISH, Akan Properti,SUBSCRIBE,DISCONNECT, UNSUBSCRIBE
Interval Kedaluwarsa Pesan Integer 4-byte yang mewakili interval kedaluwarsa pesan dalam hitungan detik. Jika tidak ada, pesan tidak kedaluwarsa. Bilangan bulat 4-byte PUBLISH, CONNECT
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 diCONNACK.

 Bilangan bulat 4-byte CONNECT, CONNACK, DISCONNECT
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. UTF-8 string 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 CONNECT
Menerima Maksimum Bilangan bulat 2-byte yang mewakili jumlah maksimum paket PUBLISH QOS > 0 yang dapat dikirim tanpa menerima. PUBACK Bilangan bulat 2 byte CONNECT, CONNACK
Topik Alias Maksimum Nilai ini menunjukkan nilai tertinggi yang akan diterima sebagai Alias Topik. Default-nya adalah 0. Bilangan bulat 2 byte CONNECT, 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 CONNECT, 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

MQTTkode alasan

MQTT5 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 MQTT5 spesifikasi.

CONNACKKode Alasan
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.
PUBACKKode Alasan
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 PUBLISHItu 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.
DISCONNECTKode 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 atauPUBCOMP.
148 0x94 Topik Alias tidak valid Klien atau server telah menerima PUBLISH paket yang berisi alias topik yang lebih besar dari Alias Topik Maksimum yang dikirim dalam paket atau. CONNECT 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.
SUBACKKode Alasan
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.
UNSUBACKKode Alasan
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 MQTT spesifikasi

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

  • AWS IoT tidak mendukung paket-paket berikut untuk MQTT 3:PUBREC,PUBREL, danPUBCOMP.

  • AWS IoT tidak mendukung paket-paket berikut untuk MQTT 5:PUBREC,, PUBRELPUBCOMP, danAUTH.

  • AWS IoT tidak mendukung pengalihan MQTT 5 server.

  • AWS IoT mendukung MQTT kualitas layanan (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 atauPUBACK. 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, DUP bendera tidak disetel.

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

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

  • 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 MQTT muatan. 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 langka, broker pesan mungkin mengirim ulang PUBLISH pesan 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.

  • MQTTDUPBendera tidak didukung.