Ringkasan dukungan IoT Hub MQTT 5 (pratinjau)

Versi: 2.0 api-version: 2020-10-01-pratinjau

Dokumen ini menentukan API bidang data IoT Hub melalui protokol MQTT versi 5.0. Lihat Referensi API untuk definisi lengkap dalam API ini.

Prasyarat

Tingkat dukungan dan batasan

Dukungan IoT Hub untuk MQTT 5 dalam pratinjau dan terbatas dengan cara berikut (dikomunikasikan ke klien melalui properti CONNACK kecuali dicatat sebaliknya secara eksplisit):

  • Belum ada dukungan SDK perangkat Azure IoT Hub resmi.
  • Pengidentifikasi langganan tidak didukung.
  • Langganan bersama tidak didukung.
  • RETAIN tidak didukung.
  • Maximum QoS adalah 1.
  • Maximum Packet Sizeadalah 256 KiB (tunduk pada batasan lebih lanjut per operasi).
  • ID Klien yang ditetapkan tidak didukung.
  • Keep Alive dibatasi hingga 19 min (penundaan maksimum untuk pemeriksaan keaktifan – 28.5 min).
  • Topic Alias Maximum adalah 10.
  • Response Information tidak didukung; CONNACK tidak mengembalikan properti Response Information bahkan jika CONNECT berisi properti Request Response Information.
  • Receive Maximum (jumlah maksimum paket PUBLISH yang belum diakui yang diizinkan (dalam arah client-server) dengan QoS: 1) adalah 16.
  • Klien tunggal tidak boleh memiliki lebih dari 50 langganan. Saat batas tercapai, SUBACK akan mengembalikan 0x97 (Kuota terlampaui) kode alasan untuk langganan.

Siklus hidup koneksi

Koneksi

Untuk menyambungkan klien ke IoT Hub menggunakan API ini, buat koneksi sesuai spesifikasi MQTT 5. Klien harus mengirim paket CONNECT dalam waktu 30 detik setelah jabat tangan TLS berhasil, atau server menutup koneksi. Berikut contoh dari paket CONNECT:

-> CONNECT
    Protocol_Version: 5
    Clean_Start: 0
    Client_Id: D1
    Authentication_Method: SAS
    Authentication_Data: {SAS bytes}
    api-version: 2020-10-10
    host: abc.azure-devices.net
    sas-at: 1600987795320
    sas-expiry: 1600987195320
    client-agent: artisan;Linux
  • Properti Authentication Method diperlukan dan mengidentifikasi metode autentikasi mana yang digunakan. Untuk informasi selengkapnya tentang metode autentikasi, lihat Autentikasi.
  • Penanganan properti Authentication Data tergantung pada Authentication Method. Jika Authentication Method diatur ke SAS, Authentication Data diperlukan dan harus berisi tanda tangan yang valid. Untuk informasi selengkapnya tentang data autentikasi, lihat Autentikasi.
  • Properti api-version diperlukan dan harus diatur ke nilai versi API yang disediakan di header spesifikasi ini agar spesifikasi ini berlaku.
  • Properti host menentukan nama host penyewa. Ini diperlukan kecuali ekstensi SNI disajikan dalam rekaman Halo Klien selama jabat tangan TLS
  • sas-at menentukan waktu koneksi.
  • sas-expiry menentukan waktu kedaluwarsa untuk SAS yang disediakan.
  • client-agent secara opsional mengkomunikasikan informasi tentang klien yang membuat koneksi.

Catatan

Authentication Method dan properti lainnya di seluruh spesifikasi dengan nama yang dikapitalisasi adalah properti kelas satu di MQTT 5 - properti tersebut dijelaskan secara rinci dalam spesifikasi MQTT 5. api-version dan properti lain dalam tanda hubung adalah properti pengguna khusus untuk IoT Hub API.

IoT Hub merespons dengan paket CONNACK setelah selesai dengan autentikasi dan mengambil data untuk mendukung koneksi. Jika koneksi berhasil dibuat, CONNACK terlihat seperti:

<- CONNACK
    Session_Present: 1
    Reason_Code: 0x00
    Session_Expiry_Interval: 0xFFFFFFFF # included only if CONNECT specified value less than 0xFFFFFFFF and more than 0x00
    Receive_Maximum: 16
    Maximum_QoS: 1
    Retain_Available: 0
    Maximum_Packet_Size: 262144
    Topic_Alias_Maximum: 10
    Subscription_Identifiers_Available: 0
    Shared_Subscriptions_Available: 0
    Server_Keep_Alive: 1140 # included only if client did not specify Keep Alive or if it specified a bigger value

Properti paket CONNACK ini mengikuti spesifikasi MQTT 5. Properti tersebut mencerminkan kemampuan IoT Hub.

Autentikasi

Properti Authentication Method pada klien CONNECT menentukan jenis autentikasi yang digunakan untuk koneksi ini:

  • SAS - Tanda Tangan Akses Bersama disediakan di CONNECT properti Authentication Data,
  • X509 - Klien mengandalkan autentikasi sertifikat klien.

Autentikasi gagal jika metode autentikasi tidak cocok dengan metode klien yang dikonfigurasi di IoT Hub.

Catatan

API ini membutuhkan properti Authentication Method untuk diatur dalam paket CONNECT. Jika properti Authentication Method tidak disediakan, koneksi gagal dengan respons Bad Request.

Autentikasi nama pengguna/kata sandi yang digunakan dalam versi API sebelumnya tidak didukung.

SAS

Dengan autentikasi berbasis SAS, klien harus memberikan tanda tangan konteks koneksi. Ini membuktikan keaslian koneksi MQTT. Tanda tangan harus didasarkan pada salah satu dari dua kunci autentikasi dalam konfigurasi klien di IoT Hub atau salah satu dari dua kunci akses bersama dari Kebijakan akses bersama.

String untuk ditandatangani harus dibentuk sebagai berikut:

{host name}\n
{Client Id}\n
{sas-policy}\n
{sas-at}\n
{sas-expiry}\n
  • host name berasal baik dari ekstensi SNI (disajikan oleh klien dalam rekaman Halo Klien selama jabat tangan TLS) atau properti pengguna host dalam paket CONNECT.
  • Client Id adalah Pengidentifikasi Klien dalam paket CONNECT.
  • sas-policy - jika ada, menentukan kebijakan akses IoT Hub yang digunakan untuk autentikasi. Ini dikodekan sebagai properti pengguna pada paket CONNECT. Opsional: menghilangkannya berarti pengaturan autentikasi di registri perangkat akan digunakan sebagai gantinya.
  • sas-at - Jika ada, menentukan waktu koneksi - waktu saat ini. Ini dikodekan sebagai properti pengguna jenis time pada paket CONNECT.
  • sas-expiry menentukan waktu kedaluwarsa untuk autentikasi. Ini adalah properti pengguna yang diketik time pada paket CONNECT. Properti ini diperlukan.

Untuk parameter opsional, jika dihilangkan, string kosong HARUS digunakan sebagai pengganti string untuk ditandatangani.

HMAC-SHA256 digunakan untuk hash string berdasarkan salah satu kunci konten perangkat. Nilai hash kemudian diatur sebagai nilai properti Authentication Data.

X509

Jika properti Authentication Method diatur ke X509, IoT Hub mengautentikasi koneksi berdasarkan sertifikat klien yang disediakan.

Autentikasi ulang

Jika autentikasi berbasis SAS digunakan, sebaiknya gunakan token autentikasi yang berumur pendek. Untuk menjaga koneksi terautentikasi dan mencegah pemutusan sambungan karena kedaluwarsa, klien harus mengautentikasi ulang dengan mengirimkan paket AUTH dengan Reason Code: 0x19 (autentikasi ulang):

-> AUTH
    Reason_Code: 0x19
    Authentication_Method: SAS
    Authentication_Data: {SAS bytes}
    sas-at: {current time}
    sas-expiry: {SAS expiry time}

Aturan:

  • Authentication Method harus sama dengan yang digunakan untuk autentikasi awal
  • jika koneksi awalnya diautentikasi menggunakan SAS berdasarkan Shared Access Azure Policy, tanda tangan yang digunakan dalam autentikasi ulang harus didasarkan pada kebijakan yang sama.

Jika autentikasi ulang berhasil, IoT Hub mengirimkan paket AUTH dengan Reason Code: 0x00 (berhasil). Jika tidak, IoT Hub mengirim paket DISCONNECT dengan Reason Code: 0x87 (Tidak diotorisasi) dan menutup koneksi.

Pemutusan sambungan

Server dapat memutuskan sambungan klien karena beberapa alasan:

  • klien berperilaku tidak baik dengan cara yang tidak mungkin ditanggapi dengan pengakuan (atau respons) negatif secara langsung,
  • server gagal memperbarui status koneksi,
  • klien dengan identitas yang sama telah tersambung.

Server dapat memutuskan sambungan dengan kode alasan apa pun yang ditentukan dalam spesifikasi MQTT 5.0. Sebutan penting:

  • 135 (Tidak diotorisasi) saat autentikasi ulang gagal, token SAS saat ini kedaluwarsa atau info masuk perangkat berubah
  • 142 (Sesi diambil alih) saat koneksi baru dengan identitas klien yang sama telah dibuka.
  • 159 (Laju koneksi terlampaui) saat laju koneksi untuk hub IoT melebihi
  • 131 (Kesalahan khusus implementasi) digunakan untuk kesalahan khusus apa pun yang ditentukan dalam API ini. Properti status dan reason akan digunakan untuk mengomunikasikan detail lebih lanjut tentang penyebab pemutusan sambungan (lihat Respons untuk detailnya).

Operasional

Semua fungsi dalam API ini dinyatakan sebagai operasi. Berikut ini contoh operasi Kirim Telemetri:

-> PUBLISH
    QoS: 1
    Packet_Id: 3
    Topic: $iothub/telemetry
    Payload: Hello

<- PUBACK
    Packet_Id: 3
    Reason_Code: 0

Untuk spesifikasi lengkap operasi dalam API ini, lihat Referensi API.

Catatan

Semua sampel dalam spesifikasi ini ditunjukkan dari perspektif klien. Tanda -> berarti klien mengirim paket, <- - menerima.

Topik pesan dan langganan

Topik yang digunakan dalam pesan operasi dalam API ini dimulai dengan $iothub/. Semantik broker MQTT tidak berlaku untuk operasi ini (lihat "Topik dimulai dengan $" untuk detailnya). Topik yang dimulai dengan $iothub/ yang tidak ditentukan dalam API ini tidak didukung:

  • Mengirim pesan ke topik yang tidak ditentukan menghasilkan respons Not Found (lihat Respons untuk detail di bawah),
  • Berlangganan ke topik yang tidak ditentukan menghasilkan SUBACK dengan Reason Code: 0x8F (Filter Topik Tidak Valid).

Nama topik dan nama properti peka huruf besar/kecil dan harus sama persis. Misalnya, $iothub/telemetry/ tidak didukung saat $iothub/telemetry didukung.

Catatan

Kartubebas dalam langganan di $iothub/.. tidak didukung. Artinya, klien tidak dapat berlangganan $iothub/+ atau $iothub/#. Mencoba melakukannya menghasilkan SUBACK dengan Reason Code: 0xA2 (Langganan Kartubebas tidak didukung). Hanya kartubebas segmen tunggal (+) yang didukung sebagai ganti dari parameter jalur dalam nama topik untuk operasi yang memilikinya.

Jenis interaksi

Semua operasi di API ini didasarkan pada salah satu dari dua jenis interaksi:

  • Pesan dengan pengakuan opsional (MessageAck)
  • Permintaan-Respons (ReqRep)

Operasi juga bervariasi menurut arah (ditentukan oleh arah pesan awal dalam pertukaran):

  • Klien-ke-Server (c2s)
  • Server-ke-Klien (s2c)

Misalnya, Kirim Telemetri adalah operasi Klien-ke-Server dari jenis "Pesan dengan pengakuan", sedangkan Handle Direct Method adalah operasi Server-ke-Klien dari jenis Permintaan-Respons.

Interaksi pesan-pengakuan

Pesan dengan interaksi Pengakuan (MessageAck) opsional dinyatakan sebagai pertukaran paket PUBLISH dan PUBACK di MQTT. Pengakuan bersifat opsional dan pengirim dapat memilih untuk tidak memintanya dengan mengirimkan paket PUBLISH dengan QoS: 0.

Catatan

Jika properti dalam paketi PUBACK harus dipotong karena Maximum Packet Size dideklarasikan oleh klien, IoT Hub akan mempertahankan properti Pengguna sebanyak yang dapat ditampung dalam batas yang diberikan. Properti pengguna yang terdaftar pertama memiliki peluang lebih tinggi untuk dikirim daripada yang terdaftar kemudian; properti Reason String memiliki prioritas paling sedikit.

Contoh interaksi MessageAck sederhana

Pesan:

PUBLISH
    QoS: 1
    Packet_Id: 34
    Topic: $iothub/{request.path}
    Payload: <any>

Pengakuan (berhasil):

PUBACK
    Packet_Id: 34
    Reason_Code: 0

Interaksi Permintaan-Respons

Dalam interaksi Permintaan-Respons (ReqRep), baik Permintaan maupun Respons diterjemahkan ke dalam paket PUBLISH dengan QoS: 0.

Properti Correlation Data harus diatur di keduanya dan digunakan untuk mencocokkan paket Respons dengan paket Permintaan.

API ini menggunakan topik respons tunggal $iothub/responses untuk semua operasi ReqRep. Berlangganan/berhenti berlangganan dari topik ini untuk operasi klien-ke-server tidak diperlukan - server mengasumsikan semua klien untuk berlangganan.

Contoh interaksi ReqRep sederhana

Permintaan:

PUBLISH
    QoS: 0
    Topic: $iothub/{request.path}
    Correlation_Data: 0x01 0xFA
    Payload: ...

Respons (berhasil):

PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    Payload: ...

Interaksi ReqRep tidak mendukung paket PUBLISH dengan QoS: 1 sebagai pesan permintaan atau respons. Mengirim Permintaan PUBLISH menghasilkan respons Bad Request.

Panjang maksimum yang didukung dalam properti Correlation Data adalah 16 byte. Jika properti Correlation Data pada paket PUBLISH diatur ke nilai yang lebih panjang dari 16 byte, IoT Hub mengirimkan DISCONNECT dengan hasil Bad Request, dan menutup koneksi. Perilaku ini hanya berlaku untuk paket yang ditukar dalam API ini.

Catatan

Data Korelasi adalah urutan byte arbitrer, misalnya tidak dijamin menjadi string UTF-8.

ReqRep menggunakan topik yang telah ditentukan sebelumnya untuk respons; Properti Topik Respons dalam paket Permintaan PUBLISH (jika diatur oleh pengirim) diabaikan.

IoT Hub secara otomatis membuat klien berlangganan topik respons untuk semua operasi ReqRep klien-ke-server. Bahkan jika klien secara eksplisit berhenti berlangganan dari topik respons, IoT Hub mengaktifkan kembali langganan secara otomatis. Untuk interaksi ReqRep server-ke-klien, perangkat masih perlu berlangganan.

Properti Pesan

Properti operasi - sistem atau yang ditentukan pengguna - dinyatakan sebagai properti paket di MQTT 5.

Nama properti pengguna peka huruf besar/kecil dan harus dieja persis seperti yang ditentukan. Misalnya, Trace-ID tidak didukung saat trace-id didukung.

Permintaan dengan properti Pengguna di luar spesifikasi dan tanpa awalan @ menghasilkan kesalahan.

Properti sistem dikodekan sebagai properti kelas satu (misalnya, Content Type) atau sebagai properti Pengguna. Spesifikasi menyediakan daftar lengkap properti sistem yang didukung. Semua properti kelas satu diabaikan kecuali dukungan untuk properti tersebut secara eksplisit dinyatakan dalam spesifikasi.

Jika properti yang ditentukan pengguna diizinkan, namanya harus mengikuti format @{property name}. Properti yang ditentukan pengguna hanya mendukung nilai string UTF-8 yang valid. misalnya, properti MyProperty1 dengan nilai 15 harus dikodekan sebagai properti Pengguna dengan nama @MyProperty dan nilai 15.

Jika IoT Hub tidak mengenali properti Pengguna, itu dianggap sebagai kesalahan dan IoT Hub merespons dengan PUBACK dengan Reason Code: 0x83 (Kesalahan khusus implementasi) dan status: 0100 (Permintaan Buruk). Jika pengakuan tidak diminta (QoS: 0), paket DISCONNECT dengan kesalahan yang sama akan dikirim kembali dan koneksi dihentikan.

API ini menentukan jenis data berikut selain string:

  • time: jumlah milidetik sejak 1970-01-01T00:00:00.000Z. Misalnya, 1600987195320 untuk 2020-09-24T22:39:55.320Z,
  • u32: bilangan bulat 32-bit yang tidak ditandatangani,
  • u64: bilangan bulat 64-bit yang tidak ditandatangani,
  • i32: bilangan bulat 32-bit yang ditandatangani.

Respons

Interaksi dapat menghasilkan hasil yang berbeda: Success, Bad Request, Not Found, dan lainnya. Hasil dibedakan satu sama lain oleh properti pengguna status. Reason Code dalam paket PUBACK (untuk interaksi MessageAck) mencocokkan status dalam arti jika memungkinkan.

Catatan

Jika klien menentukan Request Problem Information: 0 dalam paket CONNECT, tidak ada properti pengguna yang akan dikirim pada paket PUBACK untuk memenuhi spesifikasi MQTT 5, termasuk properti status. Dalam hal ini, klien masih dapat mengandalkan Reason Code untuk menentukan apakah pengakuan itu positif atau negatif.

Setiap interaksi memiliki default (atau berhasil). Ini memiliki Reason Code0 dan properti status "tidak diatur". Sebaliknya:

  • Untuk interaksi MessageAck, PUBACK mendapatkan Reason Code selain 0x0 (Berhasil). Properti status mungkin ada untuk lebih memperjelas hasilnya.
  • Untuk interaksi ReqRep, Respons PUBLISH mendapatkan kumpulan properti status.
  • Karena tidak ada cara untuk merespons interaksi MessageAck dengan QoS: 0 secara langsung, paket DISCONNECTdikirim sebagai gantinya dengan informasi respons, diikuti dengan pemutusan sambungan.

Contoh:

Permintaan Buruk (MessageAck):

PUBACK
    Reason_Code: 131
    status: 0100
    reason: Unknown property `test`

Tidak Diotorisasi (MessageAck):

PUBACK
    Reason_Code: 135
    status: 0101

Tidak Diotorisasi (ReqRep):

PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: ...
    status: 0101

Jika diperlukan, IoT Hub mengatur properti pengguna berikut:

  • status - Kode diperpanjang IoT Hub untuk status operasi. Kode ini dapat digunakan untuk membedakan hasil.
  • trace-id – jejak ID untuk operasi; IoT Hub dapat menyimpan diagnostik tambahan terkait operasi yang dapat digunakan untuk penyelidikan internal.
  • reason - pesan yang dapat dibaca manusia yang memberikan informasi lebih lanjut tentang mengapa operasi berakhir dalam keadaan yang ditunjukkan oleh properti status.

Catatan

Jika klien mengatur properti Maximum Packet Size dalam paket CONNECT ke nilai yang sangat kecil, tidak semua properti pengguna mungkin pas dan tidak akan muncul dalam paket.

reason dimaksudkan hanya untuk orang dan tidak boleh digunakan dalam logika klien. API ini memungkinkan pesan diubah kapan saja tanpa peringatan atau perubahan versi.

Jika klien mengirim RequestProblemInformation: 0 dalam paket CONNECT, properti pengguna tidak akan disertakan dalam pengakuan sesuai spesifikasi MQTT 5.

Kode status

Properti status membawa kode status untuk operasi. Ini dioptimalkan untuk efisiensi membaca komputer. Ini terdiri dari bilangan bulat dua byte yang tidak bertanda yang dikodekan sebagai hex dalam string seperti 0501. Struktur kode (peta bit):

7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
0 0 0 0 0 R T T | C C C C C C C C

Byte pertama digunakan untuk bendera:

  • bit 0 dan 1 menunjukkan jenis hasil:
    • 00 - berhasil
    • 01 - kesalahan klien
    • 10 - kesalahan server
  • bit 2: 1 menunjukkan kesalahan dapat dicoba lagi
  • bit 3 sampai 7 dicadangkan dan harus diatur ke 0

Byte kedua berisi kode respons nyata yang berbeda. Kode galat dengan bendera yang berbeda dapat memiliki nilai byte kedua yang sama. Misalnya, mungkin ada kode galat 0001, 0101, 0201, 0301 yang memiliki arti berbeda.

Misalnya, Too Many Requests adalah klien, kesalahan yang dapat coba lagi dengan kode sendiri 1. Nilainya adalah 0000 0101 0000 0001 atau 0x0501.

Klien dapat menggunakan bit jenis untuk mengidentifikasi apakah operasi berhasil diselesaikan. Klien juga dapat menggunakan bit yang dapat dicoba lagi untuk memutuskan apakah masuk akal untuk mencoba kembali operasi.

Rekomendasi

Manajemen Sesi

Paket CONNACK membawa properti Session Present untuk menunjukkan apakah server memulihkan sesi yang dibuat sebelumnya. Gunakan properti ini untuk mengetahui apakah akan berlangganan topik atau melewatkan berlangganan karena langganan dilakukan lebih awal.

Untuk mengandalkan Session Present,klien harus melacak langganan yang dibuatnya (yaitu, mengirim paket SUBSCRIBE dan menerima SUBACKdengan kode alasan yang berhasil), atau pastikan untuk berlangganan semua topik dalam satu pertukaran SUBSCRIBE/SUBACK. Jika tidak, jika klien mengirim dua paket SUBSCRIBE, dan hanya satu dari paket tersebut yang berhasil diproses oleh server, server akan mengomunikasikan Session Present: 1 di CONNACK sementara hanya sebagian dari langganan klien yang diterima.

Untuk mencegah kasus di mana versi klien yang lebih lama tidak berlangganan semua topik, lebih baik untuk berlangganan tanpa syarat ketika perilaku klien berubah (misalnya, sebagai bagian dari pembaruan firmware). Juga, untuk memastikan tidak ada langganan usang yang tertinggal (mengambil dari jumlah maksimum langganan yang diizinkan), secara eksplisit berhenti berlangganan dari langganan yang tidak lagi digunakan.

Pembuatan batch

Tidak ada format khusus untuk mengirim batch pesan. Untuk mengurangi overhead operasi intensif sumber daya di TLS dan jaringan, paket bundel (PUBLISH, PUBACK, SUBSCRIBE, dan sebagainya tidak) bersama-sama sebelum menyerahkannya ke tumpukan TLS/TCP yang mendasarinya. Selain itu, klien dapat membuat topik alias lebih mudah dalam "batch":

  • Masukkan nama topik lengkap di paket PUBLISH pertama untuk koneksi dan kaitkan topik alias dengannya,
  • Letakkan paket berikut untuk topik yang sama dengan nama topik kosong dan properti alias topik.

Migration

Bagian ini mencantumkan perubahan api dibandingkan dengan MQTT API sebelumnya.

  • Protokol transportasi adalah MQTT 5. Sebelumnya - MQTT 3.1.1.
  • Informasi konteks untuk Autentikasi SAS terkandung dalam paket CONNECT secara langsung sebagai ganti dari dikodekan bersama dengan tanda tangan.
  • Metode Autentikasi digunakan untuk menunjukkan metode otentikasi yang digunakan.
  • Tanda Tangan Akses Bersama dimasukkan ke dalam properti Data Autentikasi. Sebelumnya bidang Kata Sandi digunakan.
  • Topik untuk operasi berbeda:
    • Telemetri: $iothub/telemetry bukannya devices/{Client Id}/messages/events,
    • Perintah: $iothub/commands bukannya devices/{Client Id}/messages/devicebound,
    • Patch Ganda Dilaporkan: $iothub/twin/patch/reported bukannya $iothub/twin/PATCH/properties/reported,
    • Beri tahu Status Ganda yang Diinginkan Berubah: $iothub/twin/patch/desired bukannya$iothub/twin/PATCH/properties/desired.
  • Berlangganan untuk topik respons operasi permintaan-respons klien-server tidak diperlukan.
  • Properti pengguna digunakan sebagai ganti properti pengodean di segmen nama topik.
  • nama properti dieja dalam konvensi penamaan "tanda hubung" alih-alih singkatan dengan awalan khusus. Properti yang ditentukan pengguna sekarang memerlukan awalan sebagai gantinya. Misalnya, $.mid sekarang message-id, sementara myProperty1 menjadi @myProperty1.
  • Properti Data Korelasi digunakan untuk mengkorelasikan pesan permintaan dan respons untuk operasi permintaan-respons sebagai ganti dari properti $rid yang dikodekan dalam topik.
  • Properti iothub-connection-auth-method tidak lagi ditandai pada peristiwa telemetri.
  • Perintah C2D tidak akan dihapus menyeluruh tanpa berlangganan dari perangkat. Mereka akan tetap mengantre sampai perangkat berlangganan atau kedaluwarsa.

Contoh

Mengirim telemetri

Pesan:

-> PUBLISH
    QoS: 1
    Packet_Id: 31
    Topic: $iothub/telemetry
    @myProperty1: My String Value # optional
    creation-time: 1600987195320 # optional
    @ No_Rules-ForUser-PROPERTIES: Any UTF-8 string value # optional
    Payload: <data>

Pengakuan:

<- PUBACK
    Packet_Id: 31
    Reason_Code: 0

Pengakuan alternatif (dibatasi):

<- PUBACK
    Packet_Id: 31
    Reason_Code: 151
    status: 0501

Mengiirim dapatkan status ganda

Permintaan:

-> PUBLISH
    QoS: 0
    Topic: $iothub/twin/get
    Correlation_Data: 0x01 0xFA
    Payload: <empty>

Respons (berhasil):

<- PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    Payload: <twin/desired state>

Respons (tidak diperbolehkan):

<- PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    status: 0102
    reason: Operation not allowed for `B2` SKU
    Payload: <empty>

Menangani panggilan metode langsung

Permintaan:

<- PUBLISH
    QoS: 0
    Topic: $iothub/methods/abc
    Correlation_Data: 0x0A 0x10
    Payload: <data>

Respons (berhasil):

-> PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x0A 0x10
    response-code: 200 # user defined response code
    Payload: <data>

Catatan

status tidak diatur - ini adalah respons berhasil.

Respons Perangkat Tidak Tersedia:

-> PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x0A 0x10
    status: 0603

Kesalahan saat menggunakan QoS 0, bagian 1

Permintaan:

-> PUBLISH
    QoS: 0
    Topic: $iothub/twin/gett # misspelled topic name - server won't recognize it as Request-Response interaction
    Correlation_Data: 0x0A 0x10
    Payload: <data>

Respons:

<- DISCONNECT
    Reason_Code: 144
    reason: "Unsupported topic: `$iothub/twin/gett`"

Kesalahan saat menggunakan QoS 0, bagian 2

Permintaan:

-> PUBLISH # missing Correlation Data
    QoS: 0
    Topic: $iothub/twin/get
    Payload: <data>

Respons:

<- DISCONNECT
    Reason_Code: 131
    status: 0100
    reason: "`Correlation Data` property is missing"

Langkah berikutnya