Bagikan melalui

Protokol penyimpanan status broker MQTT

  • Artikel

Penting

Pratinjau Operasi Azure IoT – diaktifkan oleh Azure Arc saat ini dalam pratinjau. Anda tidak boleh menggunakan perangkat lunak pratinjau ini di lingkungan produksi.

Anda harus menyebarkan penginstalan Azure IoT Operations baru saat rilis yang tersedia secara umum tersedia. Anda tidak akan dapat memutakhirkan penginstalan pratinjau.

Untuk persyaratan hukum yang berlaku untuk fitur Azure yang beta, dalam pratinjau, atau belum dirilis ke ketersediaan umum, lihat Ketentuan Penggunaan Tambahan untuk Pratinjau Microsoft Azure.

Penyimpanan status MQ adalah sistem penyimpanan terdistribusi dalam kluster Operasi Azure IoT. Penyimpanan negara menawarkan jaminan ketersediaan tinggi yang sama dengan pesan MQTT di broker MQTT. Menurut pedoman protokol MQTT5/RPC, klien harus menggunakan MQTT5 untuk berinteraksi dengan penyimpanan status MQ. Artikel ini menyediakan panduan protokol untuk pengembang yang perlu menerapkan klien penyimpanan status broker MQTT mereka sendiri.

Gambaran umum protokol penyimpanan status

Penyimpanan status MQ mendukung perintah berikut:

  • SET<keyName><keyValue><setOptions>
  • GET<keyName>
  • DEL<keyName>
  • VDEL<keyName><keyValue> ## Menghapus keyName> tertentu <jika dan hanya jika nilainya adalah <keyValue>

Protokol menggunakan model respons permintaan berikut:

  • Permintaan. Klien menerbitkan permintaan ke topik sistem penyimpanan status yang ditentukan dengan baik. Untuk menerbitkan permintaan, klien menggunakan properti dan payload yang diperlukan yang dijelaskan di bagian berikut.
  • Tanggapan. Penyimpanan status secara asinkron memproses permintaan dan merespons topik respons yang awalnya disediakan klien.

Diagram berikut menunjukkan tampilan dasar permintaan dan respons:

Diagram permintaan dasar penyimpanan status dan proses respons.

Topik sistem penyimpanan status, QoS, dan properti MQTT5 yang diperlukan

Untuk berkomunikasi dengan penyimpanan status, klien harus memenuhi persyaratan berikut:

  • Gunakan MQTT5. Untuk informasi selengkapnya, lihat spesifikasi MQTT 5.
  • Gunakan QoS 1 (Kualitas Layanan tingkat 1). QoS 1 dijelaskan dalam spesifikasi MQTT 5.
  • Memiliki jam yang dalam satu menit dari jam broker MQTT.

Untuk berkomunikasi dengan penyimpanan status, klien harus PUBLISH meminta ke topik statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invokesistem . Karena penyimpanan status adalah bagian dari Operasi Azure IoT, penyimpanan status merupakan implisit SUBSCRIBE pada topik ini saat startup.

Untuk membuat permintaan, properti MQTT5 berikut diperlukan. Jika properti ini tidak ada atau permintaan bukan jenis QoS 1, permintaan gagal.

  • Topik Respons. Penyimpanan status merespons permintaan awal menggunakan nilai ini. Sebagai praktik terbaik, format topik respons sebagai clients/{clientId}/services/statestore/_any_/command/invoke/response. Mengatur topik respons sebagai statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke atau sebagai topik yang dimulai dengan clients/statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8 tidak diizinkan pada permintaan penyimpanan status. Penyimpanan status memutuskan sambungan klien MQTT yang menggunakan topik respons yang tidak valid.
  • Data Korelasi. Saat penyimpanan status mengirim respons, penyimpanan tersebut menyertakan data korelasi permintaan awal.

Diagram berikut menunjukkan tampilan permintaan dan respons yang diperluas:

Diagram permintaan dan proses respons yang diperluas penyimpanan status.

Perintah yang didukung

Perintah SET, GET, dan DEL berulah seperti yang diharapkan.

Nilai yang SET ditetapkan perintah, dan GET perintah diambil, adalah data biner arbitrer. Ukuran nilai hanya dibatasi oleh ukuran payload MQTT maksimum, dan batasan sumber daya MQ dan klien.

Opsi SET

Perintah ini SET menyediakan bendera yang lebih opsional di luar dasar keyValue dan keyName:

  • NX. Memungkinkan kunci diatur hanya jika belum ada.
  • NEX <value>. Memungkinkan kunci diatur hanya jika kunci tidak ada atau jika nilai kunci sudah diatur ke <nilai>. NEX Bendera biasanya digunakan untuk klien yang memperbarui kedaluwarsa (PX) pada kunci.
  • PX. Berapa lama kunci harus bertahan sebelum kedaluwarsa, dalam milidetik.

Opsi VDEL

Perintah VDEL adalah kasus khusus dari DEL perintah. DEL secara tidak bersyarat menghapus yang diberikan keyName. VDEL memerlukan argumen lain yang disebut keyValue. VDEL hanya menghapus yang diberikan keyName jika memiliki keyValue.

Format payload

Format payload penyimpanan PUBLISH status terinspirasi oleh RESP3, yang merupakan protokol mendasar yang digunakan Redis. RESP3 mengodekan kata kerja, seperti SET atau GET, dan parameter seperti keyName dan keyValue.

Sensitivitas huruf besar/besar

Klien harus mengirim kata kerja dan opsi dalam huruf besar.

Format permintaan

Permintaan diformat seperti dalam contoh berikut. Setelah RESP3, * mewakili jumlah item dalam array. Karakter $ adalah jumlah karakter dalam baris berikut, tidak termasuk CRLF berikutnya.

Perintah yang didukung dalam format RESP3 adalah GET, , SET, DELdan VDEL.

*{NUMBER-OF-ARGUMENTS}<CR><LF>
${LENGTH-OF-NEXT-LINE}<CR><LF>
{COMMAND-NAME}<CR><LF>
${LENGTH-OF-NEXT-LINE}<CR><LF> // This is always the keyName with the current supported verbs.
{KEY-NAME}<CR><LF>
// Next lines included only if command has additional arguments
${LENGTH-OF-NEXT-LINE}<CR><LF> // This is always the keyValue for set
{KEY-VALUE}<CR><LF>

Contoh output berikut menunjukkan payload RESP3 penyimpanan status:

*3<CR><LF>$3<CR><LF>set<CR><LF>$7<CR><LF>SETKEY2<CR><LF>$6<CR><LF>VALUE5<CR><LF>
*2<CR><LF>$3<CR><LF>get<CR><LF>$7<CR><LF>SETKEY2<CR><LF>
*2<CR><LF>$3<CR><LF>del<CR><LF>$7<CR><LF>SETKEY2<CR><LF>
*3<CR><LF>$4<CR><LF>vdel<CR><LF>$7<CR><LF>SETKEY2<CR><LF>$3<CR><LF>ABC<CR><LF>

Catatan

Perhatikan bahwa memerlukan properti MQTT5 tambahan, seperti yang SET dijelaskan di bagian Penerapan versi dan jam logis hibrid.

Format respons

Ketika penyimpanan status mendeteksi payload RESP3 yang tidak valid, penyimpanan status masih mengembalikan respons terhadap pemohon Response Topic. Contoh payload yang tidak valid termasuk perintah yang tidak valid, RESP3 ilegal, atau luapan bilangan bulat. Payload yang tidak valid dimulai dengan string -ERR dan berisi detail selengkapnya.

Catatan

Permintaan GET, , DELatau VDEL pada kunci yang tidak ada tidak dianggap sebagai kesalahan.

Jika klien mengirim payload yang tidak valid, penyimpanan status mengirimkan payload seperti contoh berikut:

-ERR syntax error

SET jawaban

SET Ketika permintaan berhasil, penyimpanan status mengembalikan payload berikut:

+OK<CR><LF>

Jika permintaan SET gagal karena pemeriksaan kondisi seperti yang ditentukan dalam opsi set NX atau NEX yang berarti kunci tidak dapat diatur, penyimpanan status mengembalikan payload berikut:

-1<CR><LF>

GET jawaban

GET Saat permintaan dibuat pada kunci yang tidak ada, penyimpanan status mengembalikan payload berikut:

$-1<CR><LF>

Saat kunci ditemukan, penyimpanan status mengembalikan nilai dalam format berikut:

${NumberOfBytes}<CR><LF>
{KEY-VALUE}

Output penyimpanan status yang mengembalikan nilai 1234 terlihat seperti contoh berikut:

$4<CR><LF>1234<CR><LF>

DEL dan VDEL respons

Penyimpanan status mengembalikan jumlah nilai yang dihapusnya pada permintaan penghapusan. Saat ini, penyimpanan status hanya dapat menghapus satu nilai pada satu waktu.

:{NumberOfDeletes}<CR><LF> // Will be 1 on successful delete or 0 if the keyName is not present

Output berikut adalah contoh perintah yang berhasil DEL :

:1<CR><LF>

Jika permintaan VDEL gagal karena nilai yang ditentukan tidak cocok dengan nilai yang terkait dengan kunci, penyimpanan status mengembalikan payload berikut:

-1<CR><LF>

-ERR Responses to

Berikut ini adalah daftar string kesalahan saat ini. Aplikasi klien Anda harus menangani string kesalahan yang tidak diketahui untuk mendukung pembaruan pada penyimpanan status.

String kesalahan yang dikembalikan dari penyimpanan status Penjelasan
tanda waktu permintaan terlalu jauh di masa mendatang; memastikan bahwa jam sistem klien dan broker disinkronkan Tanda waktu permintaan tak terduga yang disebabkan oleh penyimpanan status dan jam klien tidak sinkron.
token anggar diperlukan untuk permintaan ini Kesalahan terjadi jika kunci ditandai dengan token pagar, tetapi klien tidak menentukan token pagar.
permintaan anggar tanda waktu token terlalu jauh di masa depan; memastikan bahwa jam sistem klien dan broker disinkronkan Tanda waktu token pagar yang tidak terduga yang disebabkan oleh penyimpanan status dan jam klien tidak sinkron.
token anggar permintaan adalah versi yang lebih rendah bahwa token pagar yang melindungi sumber daya Permintaan versi token anggar salah. Untuk informasi selengkapnya, lihat [Penerapan versi dan jam logis hibrid]. (#versioning-and-hybrid-logical-clocks)
kuota telah terlampaui Penyimpanan status memiliki kuota berapa banyak kunci yang dapat disimpannya, yang didasarkan pada profil memori broker MQTT yang ditentukan.
kesalahan sintaks Payload yang dikirim tidak sesuai dengan definisi penyimpanan status.
tidak diotorisasi Otorisasi gagal
perintah tidak diketahui Perintah tidak dikenali.
jumlah argumen yang salah Jumlah argumen yang diharapkan salah.
tanda waktu hilang Ketika klien melakukan SET, mereka harus mengatur properti pengguna MQTT5 __ts sebagai HLC yang mewakili tanda waktunya.
tanda waktu salah bentuk Tanda waktu dalam __ts atau token anggar tidak legal.
panjang kunci adalah nol Kunci tidak boleh panjang nol di penyimpanan status.

Penerapan versi dan jam logis hibrid

Bagian ini menjelaskan bagaimana penyimpanan status menangani penerapan versi.

Versi sebagai Jam Logis Hibrid

Penyimpanan status mempertahankan versi untuk setiap nilai yang disimpannya. Penyimpanan status dapat menggunakan penghitung yang meningkat secara monoton untuk mempertahankan versi. Sebagai gantinya, penyimpanan status menggunakan Hybrid Logical Clock (HLC) untuk mewakili versi. Untuk informasi selengkapnya, lihat artikel tentang desain asli HLC dan niat di balik HLC.

Penyimpanan status menggunakan format berikut untuk menentukan HLC:

{wallClock}:{counter}:{node-Id}

adalah wallClock jumlah milidetik sejak zaman Unix. counter dan node-Id bekerja sebagai HLC secara umum.

Ketika klien melakukan SET, mereka harus mengatur properti __ts pengguna MQTT5 sebagai HLC yang mewakili tanda waktunya, berdasarkan jam klien saat ini. Penyimpanan status mengembalikan versi nilai dalam pesan responsnya. Respons juga ditentukan sebagai HLC dan juga menggunakan __ts properti pengguna MQTT5. HLC yang dikembalikan selalu lebih besar dari HLC permintaan awal.

Contoh pengaturan dan pengambilan versi nilai

Bagian ini memperlihatkan contoh pengaturan dan mendapatkan versi untuk nilai.

Klien menetapkan keyName=value. Jam klien adalah 3 Oktober 11:07:05 GMT. Nilai jam adalah 1696374425000 milidetik sejak zaman Unix. Asumsikan bahwa jam sistem penyimpanan status identik dengan jam sistem klien. Klien melakukan perintah seperti yang SET dijelaskan sebelumnya.

Diagram berikut mengilustrasikan SET perintah:

Diagram perintah penyimpanan status untuk mengatur versi untuk nilai.

Properti __ts (tanda waktu) pada set awal berisi 1696374425000 sebagai jam dinding klien, penghitung sebagai 0, dan node-Id-nya sebagai CLIENT. Pada respons, __ts properti yang dikembalikan penyimpanan status berisi wallClock, penghitung bertambah satu, dan node-Id sebagai StateStore. Penyimpanan status dapat mengembalikan nilai yang lebih tinggi wallClock jika jamnya berada di depan, berdasarkan cara kerja pembaruan HLC.

Versi ini juga dikembalikan pada permintaan , , DELdan VDEL yang berhasilGET. Pada permintaan ini, klien tidak menentukan __ts.

Diagram berikut mengilustrasikan GET perintah:

Diagram penyimpanan status mendapatkan versi nilai.

Catatan

Tanda waktu __ts yang dikembalikan penyimpanan status sama dengan apa yang dikembalikannya pada permintaan awal SET .

Jika kunci tertentu kemudian diperbarui dengan yang baru SET, prosesnya serupa. Klien harus mengatur permintaannya __ts berdasarkan jam saat ini. Penyimpanan status memperbarui versi nilai dan mengembalikan __ts, mengikuti aturan pembaruan HLC.

Penyimpangan jam

Penyimpanan status menolak __ts (dan juga ) __ftyang lebih dari satu menit sebelum jam lokal penyimpanan status.

Penyimpanan status menerima __ts yang berada di belakang jam lokal penyimpanan status. Seperti yang ditentukan dalam algoritma HLC, penyimpanan status mengatur versi kunci ke jam lokalnya karena lebih besar.

Mengunci dan memenggar token

Bagian ini menjelaskan tujuan dan penggunaan token penguncian dan pemagaran.

Latar belakang

Misalkan ada dua atau beberapa klien MQTT menggunakan penyimpanan status. Kedua klien ingin menulis ke kunci tertentu. Klien penyimpanan status memerlukan mekanisme untuk mengunci kunci sehingga hanya satu klien pada satu waktu yang dapat memodifikasi kunci tertentu.

Contoh skenario ini terjadi dalam sistem aktif dan siaga. Mungkin ada dua klien yang keduanya melakukan operasi yang sama, dan operasi dapat mencakup set kunci penyimpanan status yang sama. Pada waktu tertentu, salah satu klien aktif dan yang lain berdiri untuk segera mengambil alih jika sistem aktif macet atau crash. Idealnya, hanya satu klien yang harus menulis ke penyimpanan status pada waktu tertentu. Namun, dalam sistem terdistribusi ada kemungkinan bahwa kedua klien mungkin berperilaku seolah-olah mereka aktif, dan mereka mungkin secara bersamaan mencoba menulis ke kunci yang sama. Skenario ini menciptakan kondisi balapan.

Penyimpanan status menyediakan mekanisme untuk mencegah kondisi balapan ini dengan menggunakan token pagar. Untuk informasi selengkapnya tentang token anggar, dan kelas kondisi ras yang dirancang untuk dijaga, lihat artikel ini.

Mendapatkan token pagar

Contoh ini mengasumsikan bahwa kita memiliki elemen berikut:

  • Client1 dan Client2. Klien ini adalah klien penyimpanan status yang bertindak sebagai pasangan aktif dan siaga.
  • LockName. Nama kunci di penyimpanan status yang bertindak sebagai kunci.
  • ProtectedKey. Kunci yang perlu dilindungi dari beberapa penulis.

Klien mencoba untuk mendapatkan kunci sebagai langkah pertama. Mereka mendapatkan kunci dengan melakukan SET LockName {CLIENT-NAME} NEX PX {TIMEOUT-IN-MILLISECONDS}. Ingat dari Atur Opsi bahwa NEX bendera berarti bahwa SET berhasil hanya jika salah satu kondisi berikut terpenuhi:

  • Kunci kosong
  • Nilai kunci sudah diatur ke <nilai> dan PX menentukan batas waktu dalam milidetik.

Asumsikan bahwa Client1 pergi terlebih dahulu dengan permintaan SET LockName Client1 NEX PX 10000. Permintaan ini memberinya kepemilikan LockName selama 10.000 milidetik. Jika Client2 mencoba beberapa SET LockName Client2 NEX ... saat Client1 memiliki kunci, NEX bendera berarti Client2 permintaan gagal. Client1 perlu memperbarui kunci ini dengan mengirim perintah yang sama yang SET digunakan untuk memperoleh kunci, jika Client1 ingin melanjutkan kepemilikan.

Catatan

Secara SET NX konseptual setara dengan AcquireLock().

Menggunakan token pagar pada permintaan SET

Ketika Client1 berhasil melakukan SET ("AquireLock") pada LockName, penyimpanan status mengembalikan versi LockName sebagai Hybrid Logical Clock (HLC) di properti __tspengguna MQTT5 .

Ketika klien melakukan SET permintaan, klien dapat secara opsional menyertakan properti __ft pengguna MQTT5 untuk mewakili "token pagar". direpresentasikan __ft sebagai HLC. Token anggar yang terkait dengan pasangan kunci-nilai tertentu memberikan pemeriksaan kepemilikan kunci. Token anggar bisa datang dari mana saja. Untuk skenario ini, seharusnya berasal dari versi LockName.

Diagram berikut menunjukkan proses Client1 melakukan SET permintaan pada LockName:

Diagram klien yang melakukan permintaan yang ditetapkan pada properti nama kunci.

Selanjutnya, Client1 menggunakan properti (Property=1696374425000:1:StateStore) yang tidak dimodifikasi sebagai dasar __ft properti dalam permintaan untuk memodifikasi ProtectedKey__ts . Seperti semua SET permintaan, klien harus mengatur __ts properti .ProtectedKey

Diagram berikut menunjukkan proses Client1 melakukan SET permintaan pada ProtectedKey:

Diagram klien melakukan permintaan yang ditetapkan pada properti kunci yang dilindungi.

Jika permintaan berhasil, dari titik ProtectedKey ini memerlukan token pagar yang sama dengan atau lebih besar dari yang ditentukan dalam SET permintaan.

Algoritma Token Anggar

Penyimpanan status menerima HLC apa pun untuk __ts pasangan kunci-nilai, jika nilai berada dalam ke condong jam maks. Namun, hal yang sama tidak berlaku untuk token anggar.

Algoritma penyimpanan status untuk token anggar adalah sebagai berikut:

  • Jika pasangan kunci-nilai tidak memiliki token pagar yang terkait dengannya dan SET set __ftpermintaan , penyimpanan status menyimpan yang terkait __ft dengan pasangan kunci-nilai.
  • Jika pasangan kunci-nilai memiliki token anggar yang terkait dengannya:
    • SET Jika permintaan tidak menentukan __ft, tolak permintaan.
    • SET Jika permintaan menentukan __ft yang memiliki nilai HLC yang lebih lama daripada token pagar yang terkait dengan pasangan kunci-nilai, tolak permintaan.
    • SET Jika permintaan menentukan __ft yang memiliki nilai HLC yang sama atau lebih baru daripada token pagar yang terkait dengan pasangan kunci-nilai, terima permintaan. Penyimpanan status memperbarui token pagar pasangan kunci-nilai menjadi yang ditetapkan dalam permintaan, jika lebih baru.

Setelah kunci ditandai dengan token pagar, agar permintaan berhasil, DEL dan VDEL permintaan juga mengharuskan __ft properti disertakan. Algoritma identik dengan yang sebelumnya, kecuali bahwa token pagar tidak disimpan karena kunci sedang dihapus.

Perilaku klien

Mekanisme penguncian ini mengandalkan klien yang bersikap baik. Dalam contoh sebelumnya, perilaku yang salah Client2 tidak dapat memiliki LockName dan masih berhasil melakukan dengan SET ProtectedKey memilih token pagar yang lebih baru dari ProtectedKey token. Penyimpanan status tidak menyadari bahwa LockName dan ProtectedKey memiliki hubungan apa pun. Akibatnya, penyimpanan status tidak melakukan validasi yang Client2 benar-benar memiliki nilai .

Klien dapat menulis kunci yang sebenarnya tidak mereka miliki kuncinya, adalah perilaku yang tidak diinginkan. Anda dapat melindungi dari perilaku klien tersebut dengan menerapkan klien dengan benar dan menggunakan autentikasi untuk membatasi akses ke kunci hanya untuk klien tepercaya.

Notifications

Klien dapat mendaftar dengan penyimpanan status untuk menerima pemberitahuan kunci yang dimodifikasi. Pertimbangkan skenario di mana termostat menggunakan kunci {thermostatName}\setPointpenyimpanan status . Klien penyimpanan status lainnya dapat mengubah nilai kunci ini untuk mengubah setPoint termostat. Daripada polling untuk perubahan, termostat dapat mendaftar dengan penyimpanan status untuk menerima pesan ketika {thermostatName}\setPoint dimodifikasi.

PESAN permintaan KEYNOTIFY

Klien penyimpanan status meminta monitor penyimpanan status yang diberikan keyName untuk perubahan dengan mengirim KEYNOTIFY pesan. Sama seperti semua permintaan penyimpanan status, klien MENERBITKAN pesan QoS1 dengan pesan ini melalui MQTT5 ke topik statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invokesistem penyimpanan status .

Payload permintaan memiliki formulir berikut:

KEYNOTIFY<CR><LF>
{keyName}<CR><LF>
{optionalFields}<CR><LF>

Mana:

  • KEYNOTIFY adalah string literal yang menentukan perintah .
  • {keyName} adalah nama kunci untuk mendengarkan pemberitahuan. Kartubebas saat ini tidak didukung.
  • {optionalFields} Nilai bidang opsional yang saat ini didukung adalah:
    • {STOP} Jika ada pemberitahuan yang ada dengan permintaan yang sama keyName dan clientId seperti permintaan ini, penyimpanan status akan menghapusnya.

Contoh output berikut menunjukkan KEYNOTIFY permintaan untuk memantau kunci SOMEKEY:

*2<CR><LF>
$9<CR><LF>
KEYNOTIFY<CR><LF>
$7<CR><LF>
SOMEKEY<CR><LF>

Pesan respons KEYNOTIFY

Seperti semua permintaan RPC penyimpanan status, penyimpanan status mengembalikan responsnya ke Response Topic dan menggunakan Correlation Data properti yang ditentukan dari permintaan awal. Untuk KEYNOTIFY, respons yang berhasil menunjukkan bahwa penyimpanan status memproses permintaan. Setelah penyimpanan status berhasil memproses permintaan, penyimpanan status memantau kunci untuk klien saat ini, atau berhenti memantau.

Pada keberhasilan, respons penyimpanan status sama dengan yang berhasil SET.

+OK<CR><LF>

Jika klien mengirim KEYNOTIFY SOMEKEY STOP permintaan tetapi penyimpanan status tidak memantau kunci tersebut, respons penyimpanan status sama dengan mencoba menghapus kunci yang tidak ada.

:0<CR><LF>

Kegagalan lain mengikuti pola pelaporan kesalahan umum penyimpanan status:

-ERR: <DESCRIPTION OF ERROR><CR><LF>

Topik dan siklus hidup pemberitahuan KEYNOTIFY

keyName Saat dipantau melalui KEYNOTIFY dimodifikasi atau dihapus, penyimpanan status mengirimkan pemberitahuan ke klien. Topik ditentukan oleh konvensi - klien tidak menentukan topik selama KEYNOTIFY proses.

Topik didefinisikan dalam contoh berikut. clientId adalah representasi hex huruf besar yang dikodekan dari MQTT ClientId klien yang memulai KEYNOTIFY permintaan dan keyName merupakan representasi hex yang dikodekan dari kunci yang berubah. Penyimpanan status mengikuti aturan pengodean Base 16 RFC 4648 - Pengodean Data Base16, Base32, dan Base64 untuk pengodean ini.

clients/statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/{clientId}/command/notify/{keyName}

Sebagai contoh, MQ menerbitkan pesan yang NOTIFY dikirim ke client-id1 dengan nama SOMEKEY kunci yang dimodifikasi ke topik:

clients/statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/636C69656E742D696431/command/notify/534F4D454B4559`

Klien yang menggunakan pemberitahuan harus SUBSCRIBE ke topik ini dan menunggu SUBACK diterima sebelum mengirim permintaan apa pun KEYNOTIFY sehingga tidak ada pesan yang hilang.

Jika klien terputus, klien harus berlangganan KEYNOTIFY kembali ke topik pemberitahuan dan mengirim KEYNOTIFY ulang perintah untuk kunci apa pun yang perlu dipantau. Tidak seperti langganan MQTT, yang dapat dipertahankan di seluruh sesi nonklen, penyimpanan status secara internal menghapus pesan apa pun KEYNOTIFY ketika klien tertentu terputus.

Format pesan pemberitahuan KEYNOTIFY

Ketika kunci yang dipantau melalui KEYNOTIFY dimodifikasi, penyimpanan status akan PUBLISH mengirim pesan ke topik pemberitahuan dengan mengikuti format ke klien penyimpanan status yang terdaftar untuk perubahan tersebut.

NOTIFY<CR><LF>
{operation}<CR><LF>
{optionalFields}<CR><LF>

Detail berikut disertakan dalam pesan:

  • NOTIFY adalah string harfiah yang disertakan sebagai argumen pertama dalam payload, yang menunjukkan pemberitahuan tiba.
  • {operation} adalah peristiwa yang terjadi. Saat ini operasi ini adalah:
    • SET nilai dimodifikasi. Operasi ini hanya dapat terjadi sebagai hasil dari SET perintah dari klien penyimpanan status.
    • DEL nilai dihapus. Operasi ini dapat terjadi karena perintah DEL atau VDEL dari klien penyimpanan status.
  • optionalFields
    • VALUE dan {MODIFIED-VALUE}. VALUE adalah string harfiah yang menunjukkan bahwa bidang berikutnya, {MODIFIED-VALUE}, berisi nilai tempat kunci diubah. Nilai ini hanya dikirim sebagai respons terhadap kunci yang dimodifikasi karena SET.

Contoh output berikut menunjukkan pesan pemberitahuan yang dikirim saat kunci SOMEKEY dimodifikasi GET ke nilai abc, dengan VALUE disertakan karena permintaan awal menentukan opsi:

*4<CR><LF>
$6<CR><LF>
NOTIFY<CR><LF>
$3<CR><LF>
SET<CR><LF>
$5<CR><LF>
VALUE<CR><LF>
$3<CR><LF>
abc<CR><LF>

Konten terkait