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 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 protokol MQTT dan MQTT melalui protokol WSS. 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 Perangkat AWS IoT SDKs. Untuk informasi selengkapnya tentang metode otentikasi dan pemetaan port untuk pesan MQTT, lihat. Protokol, pemetaan port, dan otentikasi

Meskipun kami merekomendasikan penggunaan AWS IoT Perangkat SDKs untuk terhubung AWS IoT, mereka tidak diperlukan. Namun SDKs, jika Anda tidak menggunakan AWS IoT Perangkat, Anda harus menyediakan koneksi dan keamanan 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.

Setelah klien Anda terhubung, Anda dapat memantau dan mengelola koneksi klien MQTT mereka menggunakan. APIs Untuk informasi selengkapnya, lihat Mengelola koneksi MQTT.

Menghubungkan dengan MQTT menggunakan Perangkat AWS IoT SDKs

Bagian ini berisi tautan ke AWS IoT Perangkat SDKs 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.

Opsi Kualitas Layanan (QoS) MQTT

AWS IoT dan AWS IoT Perangkat SDKs 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.

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

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.

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 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 QoS 1 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 penyambungan ulang.

Untuk pelanggan bersama, pesan akan diantrian jika setidaknya satu pelanggan grup menggunakan sesi persisten dan tidak ada pelanggan yang online untuk menerima pesan QoS 1. Dequeuing pesan dilakukan dengan kecepatan maksimum 20 pesan per detik per pelanggan aktif dalam grup. Untuk informasi selengkapnya, lihat antrian pesan langganan bersama.

Mengakhiri sesi persisten

Sesi persisten dapat diakhiri dengan cara-cara berikut:

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:

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 RETAIN bendera yang dijelaskan dalam protokol MQTT. Saat klien menyetel RETAIN bendera 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.

Tugas umum dengan pesan yang disimpan MQTT di AWS IoT Core

AWS IoT Core menyimpan pesan MQTT dengan set bendera. RETAIN 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.

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 API normal. Biaya tambahan dijelaskan dalam AWS IoT Core harga - Pesan.

MQTT Akan pesan yang dipublikasikan ketika perangkat terputus secara tak terduga akan 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.

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

Saat mengelola koneksi klien, Anda dapat mengontrol apakah pesan LWT dipublikasikan saat Anda memutuskan sambungan klien. Untuk informasi selengkapnya, lihat Mengelola koneksi MQTT.

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:

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.

Saat mengelola koneksi klien, Anda dapat melihat atribut koneksi dan konfigurasi sesi untuk klien yang terhubung. Untuk informasi selengkapnya, lihat Mengelola koneksi MQTT.

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.1.1 dan MQTT 5. Langganan bersama memungkinkan beberapa klien untuk berbagi langganan ke 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. Ketika semua pelanggan terputus, pesan diantri.

Kemampuan antrian pesan tersedia untuk langganan bersama pada koneksi MQTT 3.1.1 dan MQTT 5 untuk meningkatkan keandalan pengiriman pesan.

Untuk menggunakan langganan bersama, klien berlangganan filter topik langganan bersama sebagai berikut:

$share/{ShareName}/{TopicFilter}

Langganan yang memiliki 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:

sports/tennis
sports/#

$share/consumer/sports/tennis
$share/consumer/sports/#

Alur langganan non-bersama	Alur langganan bersama

Catatan penting untuk menggunakan langganan bersama

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 Anda juga dapat melihat topik mana klien yang terhubung berlangganan, termasuk langganan bersama, dengan menggunakan fitur manajemen koneksi klien. Untuk informasi selengkapnya, lihat Mengelola koneksi MQTT. Untuk informasi selengkapnya tentang langganan bersama, lihat Langganan Bersama dari MQTTv5 spesifikasi.0.

Antrian pesan langganan bersama

Untuk meningkatkan keandalan pengiriman pesan, langganan bersama mencakup kemampuan antrian pesan yang menyimpan pesan ketika tidak ada pelanggan online yang tersedia. Jika grup langganan bersama berisi setidaknya satu anggota dengan sesi persisten, fitur antrian diaktifkan untuk grup. Saat mendistribusikan pesan, anggota online dipilih sebagai penerima. Pesan QoS 1 diantrian ketika tidak ada anggota yang ditemukan online atau ketika pelanggan melebihi batas. Publish requests per second per connection Pesan antrian dikirimkan ketika anggota yang ada melanjutkan sesi persisten mereka, atau anggota baru bergabung dengan grup. Pesan antrian dikirimkan hingga 20 pesan antrian per detik per pelanggan grup aktif, bersama dengan pesan lain yang dikirimkan ke pelanggan sesuai langganan.

Secara default, penyimpanan pesan antrian mengikuti kuota. Persistent Session expiry period Namun, jika Interval Kedaluwarsa Pesan (MEI) diatur dalam pesan publikasi masuk, MEI akan diutamakan. Ketika MEI hadir, ia menentukan periode penyimpanan pesan, terlepas dari periode kedaluwarsa Sesi Persisten.

Tarif antrian pesan dibatasi sesuai dengan Queued messages per second per accountkuota, dan jumlah pesan dibatasi oleh Maximum number of queued messages per shared subscription groupkuota.

Ketika batas ini terlampaui, hanya pesan yang sudah antri sebelum mencapai batas yang dipertahankan. Pesan masuk baru yang akan melebihi batas dijatuhkan. Sistem tidak mengganti pesan antrian yang lebih lama dengan yang lebih baru.

Antrian pesan direkam dalam CloudWatch metrik dan Log. CloudWatch Untuk informasi tentang entri yang ditulis ke CloudWatch dan CloudWatch Log, lihat Metrik broker pesan danEntri log antrian. Pesan antrian masih ditagih pada tingkat pesan standar. Untuk informasi selengkapnya tentang harga pesan, lihat AWS IoT Core Harga.

Siklus hidup sesi dalam grup langganan bersama

Ketika sesi bersih berlangganan grup, itu menjadi anggota online grup. Ketika berhenti berlangganan atau terputus, sesi bersih meninggalkan grup.

Ketika sesi persisten berlangganan ke grup, itu menjadi anggota online grup. Ketika terputus, itu masih tetap dalam grup, tetapi menjadi anggota offline grup. Ketika terhubung kembali, itu menjadi anggota online lagi. Sesi persisten meninggalkan grup ketika secara eksplisit berhenti berlangganan atau ketika kedaluwarsa setelah terputus.

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 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 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 (MEI) 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, MEI 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:

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

Client 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 merupakan tambahan penting pada standar MQTT untuk mendukung fitur MQTT 5 baru seperti Session Expiry dan polanya. Request/Response 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

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.

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:

Mengelola koneksi MQTT

AWS IoT Core menyediakan APIs untuk membantu Anda mengelola koneksi MQTT, termasuk kemampuan untuk memutuskan klien dan mengelola sesi mereka. Kemampuan ini memberi Anda kontrol lebih besar atas armada AWS IoT klien Anda dan membantu mengatasi masalah koneksi.

DeleteConnection API

Gunakan DeleteConnection API untuk memutuskan sambungan perangkat MQTT AWS IoT Core dengan menentukan klien mereka. IDs Ketika Anda memutuskan koneksi klien, AWS IoT Core putuskan klien dari broker AWS IoT Core pesan dan secara opsional dapat membersihkan status sesi dan menekan pesan Kehendak dan Perjanjian Terakhir (LWT).

Saat Anda memanggil DeleteConnection API, AWS IoT Core lakukan beberapa tindakan untuk memastikan pemutusan yang bersih. AWS IoT Core pertama mengirimkan pesan pemutusan MQTT ke klien untuk mengakhiri sesi MQTT. Layanan kemudian menutup TCP/TLS soket yang mendasarinya.

Broker pesan mengirimkan DISCONNECT paket ke perangkat dan menerbitkan peristiwa siklus hidup dengan alasan pemutusan sambungan. API_INITIATED_DISCONNECT Ini membantu Anda mengidentifikasi kapan pemutusan dimulai melalui API daripada oleh klien atau karena masalah jaringan. Anda dapat memantau peristiwa ini untuk tujuan visibilitas, pemecahan masalah, dan audit. Misalnya, Anda dapat menggunakan AWS IoT aturan untuk memproses peristiwa ini untuk melacak kapan dan mengapa klien terputus.

Jika Anda menyetel cleanSession parameter ketrue, AWS IoT Core menghapus status sesi klien, termasuk semua langganan dan pesan antrian. Jika Anda membersihkan sesi, sesi persisten dihentikan. Jika klien adalah sesi persisten dan preventWillMessage parameter diatur kefalse, layanan mengirimkan pesan LWT jika tersedia, yang berguna selama operasi pemeliharaan yang direncanakan.

Saat Anda memanggil DeleteConnection API, proses pemutusan segera dimulai, tetapi waktu yang tepat kapan klien mengenali pemutusan dapat bervariasi berdasarkan kondisi jaringan dan implementasi klien. Sebagian besar klien akan mendeteksi pemutusan dalam beberapa detik, tetapi dalam beberapa kasus dengan konektivitas jaringan yang buruk, mungkin perlu waktu lebih lama bagi klien untuk mengenali bahwa itu telah terputus.

Untuk informasi lebih lanjut tenngenai harga, lihat harga AWS IoT Core.

Kasus penggunaan

DeleteConnectionAPI berguna untuk mengelola klien yang berperilaku buruk yang menunjukkan perilaku bermasalah atau mengkonsumsi sumber daya yang berlebihan. Dengan memaksa pemutusan sambungan, Anda dapat memastikan bahwa klien membangun kembali koneksi mereka dengan otentikasi dan otorisasi yang tepat, yang dapat membantu menyelesaikan masalah konsumsi sumber daya.

Skenario pengalihan klien juga mendapat manfaat dari API ini. Saat Anda perlu mengarahkan klien ke titik akhir yang berbeda atau Wilayah AWS, Anda dapat memutuskannya secara terprogram dan menyambungkannya kembali ke titik akhir yang berbeda AWS IoT Core dengan mengubah pengaturan DNS. API ini dapat membantu menyelesaikan koneksi yang macet atau menghapus status sesi bermasalah yang mungkin mencegah operasi normal.

Parameter API:

DeleteConnectionAPI menerima parameter berikut:

Sintaks API

DeleteConnectionAPI menggunakan format permintaan HTTP berikut:

DELETE /connections/<clientId>?cleanSession=<cleanSession>&preventWillMessage=<preventWillMessage> HTTP/1.1

Permintaan contoh:

// Basic disconnect (preserves session, allows LWT message)
DELETE /connections/myDevice123 HTTP/1.1

// Disconnect and clear session
DELETE /connections/myDevice123?cleanSession=TRUE HTTP/1.1

// Disconnect, clear session, and prevent LWT message
DELETE /connections/myDevice123?cleanSession=TRUE&preventWillMessage=TRUE HTTP/1.1

Permintaan yang berhasil mengembalikan HTTP 200 OK tanpa badan respons.

Izin yang diperlukan

Untuk menggunakan DeleteConnection API, Anda memerlukan izin IAM berikut:

iot:DeleteConnection

Anda dapat memberikan cakupan izin ini ke klien tertentu IDs menggunakan kebijakan berbasis sumber daya. Misalnya:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:DeleteConnection",
            "Resource": "arn:aws:iot:region:account:client/myDevice*"
        }
    ]
}

Pertimbangan penting

Klien yang terputus dapat segera mencoba menyambung kembali kecuali Anda telah menerapkan logika tambahan untuk mencegah penyambungan kembali. Operasi pemutusan hanya menghentikan koneksi saat ini dan tidak mencegah koneksi terhubung kembali. Jika Anda perlu mencegah koneksi ulang, pertimbangkan untuk menerapkan logika sisi klien atau menonaktifkan kredensi perangkat.

Batas tarif berlaku untuk API sebagai bagian dari pembatasan tarif AWS IoT Core API standar. Saat merencanakan operasi pemutusan massal, pastikan Anda memperhitungkan batasan ini dan menerapkan logika coba ulang dan strategi batching yang sesuai untuk menghindari pelambatan. Untuk informasi lebih lanjut, lihat AWS IoT Core kuota dan titik akhir.

Tanggapan kesalahan

DeleteConnectionAPI dapat mengembalikan respons kesalahan berikut: