Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Durum deposu, Azure IoT İşlemleri kümesi içindeki dağıtılmış bir depolama sistemidir. Durum deposu, MQTT aracısında MQTT iletileriyle aynı yüksek kullanılabilirlik garantilerini sunar. MQTT5/RPC protokolü yönergelerine göre, istemcilerin durum deposuyla etkileşime geçmek için MQTT v5 kullanması gerekir. Bu makalede, kendi durum deposu istemcilerini uygulaması gereken geliştiriciler için protokol kılavuzu sağlanır.
Genel Bakış
Durum deposu aşağıdaki komutları destekler:
-
SET<keyName><keyValue><setOptions> -
GET<keyName> -
DEL<keyName> -
VDEL<keyName><keyValue> ## Verilen <bir keyName> değerini yalnızca değeri <keyValue ise siler>
Protokol aşağıdaki istek-yanıt modelini kullanır:
- İstek. İstemciler iyi tanımlanmış bir durum deposu sistemi konusuna istek yayımlar. İstemciler, isteği yayımlamak için aşağıdaki bölümlerde açıklanan gerekli özellikleri ve yükü kullanır.
- Yanıt. Durum deposu, isteği zaman uyumsuz olarak işler ve istemcinin başlangıçta sağladığı yanıt konusuna yanıt verir.
Aşağıdaki diyagramda istek ve yanıtın temel görünümü gösterilmektedir:
Durum depolama sistemi konusu, QoS ve gerekli MQTT v5 özellikleri
Durum deposuyla iletişim kurmak için istemcilerin aşağıdaki gereksinimleri karşılaması gerekir:
- MQTT v5 kullanın. Daha fazla bilgi için bkz. MQTT v5 belirtimi.
- QoS 1 kullanın (Hizmet Kalitesi düzeyi 1). QoS 1, MQTT v5 belirtiminde açıklanmıştır.
- MQTT aracısının saatinden bir dakika içinde bir saat vardır.
Durum deposuyla iletişim kurmak için istemcilerin sistem konusuna PUBLISHistekte bulunması gerekirstatestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke. Durum deposu Azure IoT İşlemleri'nin bir parçası olduğundan, başlangıçta bu konuya örtük SUBSCRIBE bir işlem yapar.
İstek oluşturmak için aşağıdaki MQTT5 özellikleri gereklidir. Bu özellikler yoksa veya istek QoS 1 türünde değilse istek başarısız olur.
-
Yanıt Konusu. Durum deposu bu değeri kullanarak ilk isteğe yanıt verir. En iyi uygulama olarak yanıt konusunu olarak
clients/{clientId}/services/statestore/_any_/command/invoke/responsebiçimlendirin. Durum deposu isteğinde yanıt konusunun veya ilestatestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invokebaşlayan bir konu olarakclients/statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8ayarlanmasına izin verilmez. Durum deposu, geçersiz bir yanıt konusu kullanan MQTT istemcilerinin bağlantısını keser. - Bağıntı Verileri. Durum deposu bir yanıt gönderdiğinde, ilk isteğin bağıntı verilerini içerir.
Aşağıdaki diyagramda istek ve yanıtın genişletilmiş bir görünümü gösterilmektedir:
Desteklenen komutlar
, SETve GET komutları DELbeklendiği gibi davranır.
Komut kümelerinin SET ve komutun aldığından GET alınan değerler rastgele ikili verilerdir. Değerlerin boyutu yalnızca MQTT yük boyutu üst sınırı ve MQTT aracısı ile istemcinin kaynak sınırlamaları ile sınırlıdır.
SET Seçenekler
komutu, SET temel keyValue ve keyName'nin ötesinde daha fazla isteğe bağlı bayrak sağlar:
-
NX. Anahtarın yalnızca henüz mevcut değilse ayarlanmasına izin verir. -
NEX <value>. Anahtarın yalnızca anahtarın mevcut olmaması veya anahtarın değeri zaten değer< olarak ayarlanmışsa ayarlanmasına >izin verir.NEXBayrağı genellikle bir anahtardaki süre sonunu (PX) yenileyen bir istemci için kullanılır. -
PX. Anahtarın süresi dolmadan önce ne kadar süreyle (milisaniye cinsinden) kalıcı olması gerekir.
VDEL Seçenekler
komutu VDEL , komutun DEL özel bir örneğidir.
DEL belirtilen keyNameöğesini koşulsuz olarak siler.
VDEL adlı keyValuebaşka bir bağımsız değişken gerektirir.
VDELyalnızca aynı keyNameolduğunda verilen keyValue öğesini siler.
Yük biçimi
Durum deposu PUBLISH yük biçimi, Redis'in kullandığı temel protokol olan RESP3'e ilham kaynağıdır. RESP3 hem veya SETgibi GET fiili hem de ve keyNamegibi keyValue parametreleri kodlar.
Büyük/küçük harf duyarlılığı
İstemcinin hem fiilleri hem de seçenekleri büyük harfle göndermesi gerekir.
İstek biçimi
İstekler aşağıdaki örnekte olduğu gibi biçimlendirilmiştir. RESP3'ün ardından, * dizideki öğe sayısını temsil eder. Karakter $ , sondaki CRLF hariç, aşağıdaki satırdaki karakter sayısıdır.
RESP3 biçiminde desteklenen komutlar , GET, SETve DELşeklindedirVDEL.
*{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>
Aşağıdaki örnek çıktıda resp3 durum deposu yükleri gösterilmektedir:
*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>
Uyarı
SETSürüm oluşturma ve karma mantıksal saatler bölümünde açıklandığı gibi ek MQTT5 özellikleri gerektirir.
Yanıt biçimi
Durum deposu geçersiz bir RESP3 yükü algıladığında, yine de istek sahibinin Response Topicöğesine bir yanıt döndürür. Geçersiz yüklere örnek olarak geçersiz bir komut, geçersiz bir RESP3 veya tamsayı taşması verilebilir. Geçersiz bir yük dizeyle -ERR başlar ve daha fazla ayrıntı içerir.
Uyarı
GETVar olmayan bir anahtardaki bir , DELveya VDEL isteği hata olarak kabul edilmez.
İstemci geçersiz bir yük gönderirse, durum deposu aşağıdaki örneğe benzer bir yük gönderir:
-ERR syntax error
SET yanıt
bir SET istek başarılı olduğunda, durum deposu aşağıdaki yükü döndürür:
+OK<CR><LF>
Anahtarın ayarlanamadığı anlamına gelen NX veya NEX kümesi seçeneklerinde belirtilen bir koşul denetimi nedeniyle BIR SET isteği başarısız olursa, durum deposu aşağıdaki yükü döndürür:
-1<CR><LF>
GET yanıt
Var olmayan bir GET anahtara istek yapıldığında, durum deposu aşağıdaki yükü döndürür:
$-1<CR><LF>
Anahtar bulunduğunda, durum deposu değeri aşağıdaki biçimde döndürür:
${NumberOfBytes}<CR><LF>
{KEY-VALUE}
Değeri 1234 döndüren durum deposunun çıkışı aşağıdaki örneğe benzer:
$4<CR><LF>1234<CR><LF>
DEL ve VDEL yanıt
Durum deposu, silme isteğinde sildiğiniz değerlerin sayısını döndürür. Şu anda durum deposu bir kerede yalnızca bir değeri silebilir.
:{NumberOfDeletes}<CR><LF> // Will be 1 on successful delete or 0 if the keyName is not present
Aşağıdaki çıkış, başarılı DEL bir komutun örneğidir:
:1<CR><LF>
Belirtilen değer anahtarla ilişkili değerle eşleşmediğinden bir VDEL isteği başarısız olursa, durum deposu aşağıdaki yükü döndürür:
-1<CR><LF>
-ERR Yanıt
Hata dizelerinin geçerli listesi aşağıdadır. İstemci uygulamanız, durum deposu güncelleştirmelerini desteklemek için bilinmeyen hata dizelerini işlemelidir.
| Durum deposundan döndürülen hata dizesi | Açıklama |
|---|---|
| istek zaman damgası gelecekte çok uzak; istemci ve aracı sistem saatlerinin eşitlenmiş olduğundan emin olun | Durum deposu ve istemci saatlerinin neden olduğu beklenmeyen istek zaman damgası eşitlenmiyor. |
| Bu istek için bir eskrim belirteci gerekiyor | Bir anahtar bir eskrim belirteci ile işaretlenmişse, ancak istemci eskrim belirtecini belirtmediyse hata oluşur. |
| İstek eskrim belirteci zaman damgası gelecekte çok uzak; istemci ve aracı sistem saatlerinin eşitlenmiş olduğundan emin olun | Durum deposu ve istemci saatlerinin neden olduğu beklenmeyen eskrim belirteci zaman damgası eşitlenmiyor. |
| İstek eskrim belirteci, eskrim belirtecinin kaynağı koruduğu daha düşük bir sürümdür | Yanlış istek eskrim belirteci sürümü. Daha fazla bilgi için bkz. [Sürüm oluşturma ve karma mantıksal saatler]. (#versioning ve-karma-mantıksal-saatler) |
| kota aşıldı | Durum deposu, belirtilen MQTT aracısının bellek profilini temel alan kaç anahtar depolayabileceğinize ilişkin bir kotaya sahiptir. |
| söz dizimi hatası | Gönderilen yük, durum deposunun tanımına uymuyor. |
| yetkilendirilmedi | Yetkilendirme hatası |
| bilinmeyen komut | Komut tanınmıyor. |
| yanlış sayıda bağımsız değişken | Beklenen bağımsız değişkenlerin yanlış sayısı. |
| eksik zaman damgası | İstemciler bir SET gerçekleştirdiğinde, MQTT5 kullanıcı özelliğini __ts zaman damgasını temsil eden bir HLC olarak ayarlamaları gerekir. |
| yanlış biçimlendirilmiş zaman damgası | __ts veya eskrim belirtecindeki zaman damgası yasal değildir. |
| anahtar uzunluğu sıfırdır | Durum deposunda anahtarlar sıfır uzunlukta olamaz. |
Sürüm oluşturma ve karma mantıksal saatler
Bu bölümde durum deposunun sürüm oluşturma işlemini nasıl işlediği açıklanmaktadır.
Karma Mantıksal Saat Olarak Sürümler
Durum deposu, depodüğü her değer için bir sürüm tutar. Durum deposu, sürümleri korumak için monoton olarak artan bir sayaç kullanabilir. Bunun yerine, durum deposu sürümleri temsil etmek için Karma Mantıksal Saat (HLC) kullanır. Daha fazla bilgi için, HLC'lerin özgün tasarımı ve HLC'lerinamacı hakkındaki makalelere bakın.
Durum deposu, HLC'leri tanımlamak için aşağıdaki biçimi kullanır:
{wallClock}:{counter}:{node-Id}
wallClock, Unix döneminin bu yana geçen milisaniye sayısıdır.
counter ve node-Id genel olarak HLC olarak çalışır.
İstemciler bir SETişlemi gerçekleştirdiğinde, istemcinin geçerli saatini temel alarak MQTT5 kullanıcı özelliğini __ts zaman damgasını temsil eden bir HLC olarak ayarlamaları gerekir. Durum deposu, yanıt iletisindeki değerin sürümünü döndürür. Yanıt ayrıca bir HLC olarak belirtilir ve MQTT5 kullanıcı özelliğini de kullanır __ts . Döndürülen HLC her zaman ilk isteğin HLC'sinden büyüktür.
Değerin sürümünü ayarlama ve alma örneği
Bu bölümde bir değer için ayar ve sürümü alma örneği gösterilmektedir.
İstemci kümeleri keyName=value. İstemci saati 3 Ekim 11:07:05 GMT'dir. Unix döneminin ardından saat değeri milisaniyedir 1696374425000 . Durum deposunun sistem saatinin istemci sistem saatiyle aynı olduğunu varsayalım. İstemci, komutu daha önce açıklandığı gibi yapar SET .
Aşağıdaki diyagramda komutu gösterilmektedir SET :
İlk __ts kümedeki (zaman damgası) özelliği istemci duvar saati, sayacı olarak 1696374425000ve düğüm kimliği olarak 0içerirCLIENT. Yanıtta, durum deposunun __ts döndürdüğü özellik değerini, bir artırılan sayacını ve düğüm kimliğini olarak wallClockiçerirStateStore. Durum deposu, HLC güncelleştirmelerinin çalışma şekline bağlı olarak saati öncedenyse daha yüksek wallClock bir değer döndürebilir.
Bu sürüm başarılı GET, DELve VDEL isteklerinde de döndürülür. Bu isteklerde, istemci bir __tsbelirtmez.
Aşağıdaki diyagramda komutu gösterilmektedir GET :
Uyarı
Durum deposunun döndürdüğü zaman damgası, ilk __ts istekte döndürdüğü zaman damgasıyla SET aynıdır.
Belirli bir anahtar daha sonra yeni SETbir ile güncelleştirilirse, işlem benzerdir. İstemci, isteğini __ts geçerli saatine göre ayarlamalıdır. Durum deposu değerin sürümünü güncelleştirir ve HLC güncelleştirme kurallarını izleyerek değerini döndürür __ts.
Saat kayması
Durum deposu, durum deposunun yerel saatinden bir dakikadan daha uzun olan bir (ve aynı zamanda __tsbir ) öğesini reddeder __ft .
Durum deposu, durum deposu yerel saatinin arkasındaki bir __ts değeri kabul eder. HLC algoritmasında belirtildiği gibi, durum deposu anahtarın sürümünü yerel saatine ayarlar çünkü daha büyüktür.
Belirteçleri kilitleme ve eskrim
Bu bölümde belirteçleri kilitleme ve eskrim etme amacı ve kullanımı açıklanmaktadır.
Arka plan
Durum depounu kullanan iki veya daha fazla MQTT istemcisi olduğunu varsayalım. her iki istemci de belirli bir anahtara yazmak ister. Durum deposu istemcileri, anahtarı tek seferde yalnızca bir istemcinin belirli bir anahtarı değiştirebileceği şekilde kilitlemek için bir mekanizmaya ihtiyaç duyar.
Bu senaryonun bir örneği etkin ve bekleme sistemlerinde oluşur. Her ikisi de aynı işlemi gerçekleştiren iki istemci olabilir ve işlem aynı durum deposu anahtarları kümesini içerebilir. Belirli bir zamanda, istemcilerden biri etkin, diğeri ise etkin sistemin kilitlenmesi veya kilitlenmesi durumunda hemen devralmak için beklemededir. İdeal olarak, belirli bir zamanda durum deposuna yalnızca bir istemci yazmalıdır. Ancak, dağıtılmış sistemlerde her iki istemci de etkinmiş gibi davranabilir ve aynı anda aynı anahtarlara yazmaya çalışabilir. Bu senaryo bir yarış durumu oluşturur.
Durum deposu, eskrim belirteçlerini kullanarak bu yarış durumunu önlemek için mekanizmalar sağlar. Belirteçleri eskrim ve korunmak üzere tasarlanan yarış koşulları sınıfı hakkında daha fazla bilgi için bu makaleye bakın.
Eskrim belirteci alma
Bu örnekte aşağıdaki öğelere sahip olduğumuz varsayılır:
-
Client1veClient2. Bu istemciler, etkin ve bekleme çifti olarak davranan durum deposu istemcileridir. -
LockName. Durum deposunda kilit görevi gören bir anahtarın adı. -
ProtectedKey. Birden çok yazardan korunması gereken anahtar.
İstemciler ilk adım olarak bir kilit almaya çalışır. Bir kilit SET LockName {CLIENT-NAME} NEX PX {TIMEOUT-IN-MILLISECONDS}ile kilitlerler. Ayar Seçenekleri'nden, bayrağın NEX yalnızca aşağıdaki koşullardan SET biri karşılandığında başarılı olduğu anlamına geldiğini hatırlayın:
- Anahtar boştu
- Anahtarın değeri zaten değer< olarak >ayarlanmıştır ve
PXzaman aşımını milisaniye cinsinden belirtir.
bunun ilk olarak isteğiyle Client1olduğunu SET LockName Client1 NEX PX 10000 varsayalım. Bu istek, 10.000 milisaniye için sahipliğini LockName verir. Kilidin sahibi bir Client2 süre SET LockName Client2 NEX ... denerseClient1, NEX bayrağı isteğin Client2 başarısız olduğu anlamına gelir.
Client1sahipliğine devam etmek istiyorsaSET, kilidi almak için kullanılan komutu göndererek Client1 bu kilidi yenilemesi gerekir.
Uyarı
A SET NX kavramsal olarak ile AcquireLock()eşdeğerdir.
SET isteklerinde eskrim belirteçlerini kullanma
üzerinde bir ("AcquireLock") başarıyla yapıldığında Client1SET , durum deposu MQTT5 kullanıcı özelliğinde LockNamesürümünü Karma Mantıksal Saat (HLC) olarak döndürürLockName.__ts
İstemci bir SET istek gerçekleştirdiğinde, isteğe bağlı olarak bir "eskrim belirtecini" temsil eden MQTT5 kullanıcı özelliğini __ft içerebilir.
__ft bir HLC olarak temsil edilir. Belirli bir anahtar-değer çiftiyle ilişkili eskrim belirteci kilit sahipliği denetimi sağlar. Eskrim belirteci her yerden gelebilir. Bu senaryo için sürümünden LockNamegelmelidir.
Aşağıdaki diyagramda üzerinde Client1istek SET yapma işlemi LockName gösterilmektedir:
Ardından, Client1 değiştirme __tsisteğindeki Property=1696374425000:1:StateStore özelliğin __ft temeli olarak değiştirilmemiş özelliğini (ProtectedKey) kullanır. Tüm SET istekler gibi istemcinin de özelliğini ayarlaması __tsProtectedKeygerekir.
Aşağıdaki diyagramda üzerinde Client1istek SET yapma işlemi ProtectedKey gösterilmektedir:
İstek başarılı olursa, bu noktadan sonra istekte ProtectedKeySET belirtilene eşit veya ondan büyük bir eskrim belirteci gerektirir.
Eskrim Belirteci Algoritması
Durum deposu, değer maksimum saat dengesizliği içindeyse anahtar-değer çifti için __ts herhangi bir HLC'yi kabul eder. Ancak, belirteçleri eskrim için de aynı durum geçerli değildir.
Belirteçleri eskrim için durum deposu algoritması aşağıdaki gibidir:
- Bir anahtar-değer çiftinin kendisiyle ilişkilendirilmiş bir eskrim belirteci yoksa ve istek
SETkümeleri varsa__ft, durum, anahtar-değer çiftiyle ilişkili__ftdepolar. - Anahtar-değer çiftinin kendisiyle ilişkilendirilmiş bir eskrim belirteci varsa:
- bir
SETistek belirtmezse__ftisteği reddedin. - Bir
SETistek, anahtar-değer çiftiyle ilişkilendirilmiş eskrim belirtecinden daha eski bir HLC değerine sahip bir__ftbelirtmişse, isteği reddedin. -
SETAnahtar-değer çiftiyle ilişkili eskrim belirtecinden eşit veya daha yeni bir HLC değerine sahip bir istek belirttiyse__ft, isteği kabul edin. Durum deposu, daha yeniyse anahtar-değer çiftinin eskrim belirtecini istekte ayarlanan belirteç olacak şekilde güncelleştirir.
- bir
Bir anahtar bir eskrim belirteci ile işaretlendikten sonra, bir isteğin başarılı DEL olması için ve VDEL istekler de özelliğin __ft eklenmesini gerektirir. Algoritma öncekiyle aynıdır, ancak anahtar silindiği için eskrim belirteci depolanmaz.
İstemci davranışı
Bu kilitleme mekanizmaları, istemcilerin iyi davranılmasını kullanır. Önceki örnekte, bir hatalı davranış Client2 belirtecin sahibi LockName olamadı ve yine de belirteçten SET ProtectedKey daha yeni bir eskrim belirteci seçerek bunu başarıyla gerçekleştiremediProtectedKey. Durum deposu bunun LockName farkında değildir ve ProtectedKey herhangi bir ilişkisi vardır. Sonuç olarak, durum deposu değerin sahibi olan Client2 doğrulama gerçekleştirmez.
İstemcilerin aslında kilidin sahibi olmadığı anahtarları yazabilmesi istenmeyen bir davranıştır. İstemcileri doğru şekilde uygulayarak ve anahtarlara erişimi yalnızca güvenilen istemcilerle sınırlandırmak için kimlik doğrulamasını kullanarak bu tür istemci yanlışlarına karşı koruyabilirsiniz.
Bildirimler
İstemciler, değiştirilen anahtarların bildirimlerini almak için durum deposuna kaydolabilir. Termostatın durum deposu anahtarını {thermostatName}\setPointkullandığı senaryoyu düşünün. Diğer durum deposu istemcileri termostat setPoint değerini değiştirmek için bu anahtarın değerini değiştirebilir. Termostat, değişiklikleri yoklama yerine durum deposuna kaydolarak değiştirildiğinde {thermostatName}\setPoint iletileri alabilir.
KEYNOTIFY istek iletileri
Durum deposu istemcileri, bir ileti göndererek durum deposunun belirli keyName bir değişiklikleri izlemesini KEYNOTIFY iste. Tüm durum deposu isteklerinde olduğu gibi, istemciler de MQTT v5 aracılığıyla bu iletiyle birlikte bir QoS1 iletisini durum deposu sistemi konusuna statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invokeYAYIMLAR.
İstek yükü aşağıdaki biçimdedir:
KEYNOTIFY<CR><LF>
{keyName}<CR><LF>
{optionalFields}<CR><LF>
Nerede:
- KEYNOTIFY, komutu belirten bir dize değişmez değeridir.
-
{keyName}, bildirimlerin dinlenmek için anahtar adıdır. Joker karakterler şu anda desteklenmemektedir. -
{optionalFields}Şu anda desteklenen isteğe bağlı alan değerleri şunlardır:-
{STOP}Bu istekle aynıkeyNameveclientIdmevcut bir bildirim varsa durum deposu bunu kaldırır.
-
Aşağıdaki örnek çıktıda anahtarı KEYNOTIFYizleme isteği gösterilmektedirSOMEKEY:
*2<CR><LF>
$9<CR><LF>
KEYNOTIFY<CR><LF>
$7<CR><LF>
SOMEKEY<CR><LF>
KEYNOTIFY yanıt iletisi
Tüm durum deposu RPC isteklerinde olduğu gibi durum deposu da yanıtını Response Topic döndürür ve ilk istekten belirtilen özellikleri kullanır Correlation Data . için KEYNOTIFYbaşarılı bir yanıt, durum deposunun isteği işlediğini gösterir. Durum deposu isteği başarıyla işledikten sonra, geçerli istemcinin anahtarını izler veya izlemeyi durdurur.
Başarılı olduğunda, durum deposunun yanıtı başarılı SETile aynıdır.
+OK<CR><LF>
İstemci bir KEYNOTIFY SOMEKEY STOP istek gönderirse ancak durum deposu bu anahtarı izlemiyorsa, durum deposunun yanıtı var olmayan bir anahtarı silme girişimiyle aynıdır.
:0<CR><LF>
Diğer tüm hatalar durum deposunun genel hata raporlama desenini izler:
-ERR: <DESCRIPTION OF ERROR><CR><LF>
KEYNOTIFY bildirim konuları ve yaşam döngüsü
aracılığıyla keyName izlenen bir KEYNOTIFY değiştirildiğinde veya silindiğinde, durum deposu istemciye bir bildirim gönderir. Konu kurala göre belirlenir; istemci işlem sırasında KEYNOTIFY konuyu belirtmez.
Konu aşağıdaki örnekte tanımlanmıştır. , clientId isteği başlatan KEYNOTIFY istemcinin MQTT ClientId değerinin büyük harf onaltılık kodlanmış bir gösterimidir ve keyName değişen anahtarın onaltılık kodlanmış bir gösterimidir. Durum deposu, bu kodlama için RFC 4648 - Base16, Base32 ve Base64 Veri Kodlamalarının Temel 16 kodlama kurallarını izler.
clients/statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/{clientId}/command/notify/{keyName}
Örnek olarak, MQTT aracısı değiştirilmiş anahtar adıyla NOTIFY gönderilen client-id1 bir SOMEKEY iletiyi konu başlığına yayımlar:
clients/statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/636C69656E742D696431/command/notify/534F4D454B4559`
Bildirimleri kullanan bir istemci bu konuya gitmeli ve hiçbir iletinin kaybolmaması için SUBSCRIBE istek SUBACK göndermeden önce alınabilmesini beklemelidirKEYNOTIFY.
İstemcinin bağlantısı kesilirse bildirim konusuna yeniden abone olması ve izlemeye devam etmesi KEYNOTIFY için gereken tüm anahtarlar için komutu yeniden KEYNOTIFY göndermesi gerekir. Çekirdek olmayan bir oturumda kalıcı olabilecek MQTT aboneliklerinden farklı olarak, durum deposu belirli bir istemcinin bağlantısı kesildiğinde tüm KEYNOTIFY iletileri dahili olarak kaldırır.
KEYNOTIFY bildirim iletisi biçimi
aracılığıyla KEYNOTIFY izlenen bir anahtar değiştirildiğinde, durum deposu, değişiklik için kaydedilen durum deposu istemcilerinin biçimini izleyen bildirim konusuna bir ileti gönderir PUBLISH .
NOTIFY<CR><LF>
{operation}<CR><LF>
{optionalFields}<CR><LF>
İletiye aşağıdaki ayrıntılar eklenmiştir:
-
NOTIFY, yükteki ilk bağımsız değişken olarak dahil edilen ve bir bildirimin geldiğini gösteren bir dize değişmez değeridir. -
{operation}gerçekleşen olaydır. Şu anda bu işlemler şunlardır:-
SETdeğeri değiştirildi. Bu işlem yalnızca durum deposu istemcisinden gelen birSETkomutun sonucu olarak gerçekleşebilir. -
DELdeğeri silindi. Bu işlem, durum deposu istemcisinden gelenDELveyaVDELkomutu nedeniyle gerçekleşebilir.
-
optionalFields-
VALUEve{MODIFIED-VALUE}.VALUE, bir sonraki alan olan değerinin anahtarın{MODIFIED-VALUE}değiştirildiği değeri içerdiğini belirten bir dize değişmez değeridir. Bu değer yalnızca nedeniyleSETdeğiştirilen anahtarlara yanıt olarak gönderilir.
-
Aşağıdaki örnek çıktıda, anahtar SOMEKEY değeri abcolarak VALUE değiştirildiğinde gönderilen bir bildirim iletisi gösterilir ve ilk istek seçeneği belirtilmiştir GET :
*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>
Bildirim iletisi, KEYNOTIFY bir istemciye SET isteği hakkında bildirimde bulunurken (değer güncelleştirildi) veya del veya VDEL isteği (değer silindi) hakkında bir istemciye bildirimde bulunurken değerin zaman damgasını içerir. Zaman damgası, iletinin MQTT v5 Kullanıcı Özelliği __ts bir parçası olarak eklenir. Daha fazla bilgi için, Karma Mantıksal Saatler Olarak Sürümler bölümüne bakın.