Vlákno názorů k článku Protokol MQTT: komunikační standard pro IoT od Ladislav Jech - V non IOT architekturach se vetsinou neresi pocet...

V non IOT architekturach se vetsinou neresi pocet TCP spojeni, takze pokud nejake zarizeni neni pripojeno, je to spise error stav, ktery se musi co nejdrive napravit... -> connection musi stale existovat

Naopak v IOT architekturach (ted resim svuj prvni IOT POC projekt) jsem se dostal trochu jinam:
1. Pokud uvazuji imaginarnich napr. 500,000 zarizeni, tak to jako sorry, ale to uz muze byt problem mozna na firewallu, ale hlavne na message brokerech. Nemam zkusenost s moquito, ale Weblogic JMS, ActiveMQ, Rabbit.. a kazdy pripojeni potrebuje pamet
2. Posilam data napr. jednou za den/hodinu, takze proste poslu behem par vterin data a zarizeni prepnu do sleep modu, aby papalo malo elektriny

A ted tu mam mozny problem, nevim, proto se tu ptam na nasledujici scenar:
1. Zarizeni posle data na data pro server
2. Server ma subscribci, dostane data
3. Zarizeni vytvori subskripci na nejaky rekneme reply topic
4. Zarizeni se hodi do sleep modu, tj. vypne komplet wifi -> pripojeni k brokeru je dole
5. Server posle response do topicu
6. Zarizeni se nahodi a pripoji se zpet do brokeru

Otazka:
1. Musi zarizeni vytvaret novou subskripci, nebo je predesla subscripce persistentni na brokeru i po docasnem odpojeni a po znovupripojeni dostane zarizeni vsechny zpravy z topicu, ktere server behem trvani vypnuti publikoval?

Nemohl jsem tu odpoved najit, protoze jsem pasl po "persistent subscription mqtt", ale nasel jsem, ze toto je implementovano v MQTT jako Persistent Session, takze ano, je to tam, a prave bych se divil, kdyby to neumelo... :-)

MQTT uspávání nepodporuje. Je založeno na předpokladu trvale udržovaného obousměrného spojení typu "stream".

Pro čidla, která se připojují jenom občas, je právě MQTT-SN, ten má speciální prostředky pro oznámení přechodu do spánku apod.

Nejdriv diky za rychlou odezvu komunity!

Ted mam takovou nesrovnalost. MQTT-SN je totez co Persistent Session, zase jsem to bohuzel nevygooglil :-)

Predesly prispevek je otazka, nedal jsem tam ?

Persistent session znamená jenom tohle:

Dejme tomu, že se klient potřebuje subscribovat na topiky A,B,C,D. Jestliže se úspěšně subscribuje, potom ztratí spojení a při následném připojení (pod stejným client id) NEpoužije flag "clean session", bude dál dostávat zprávy z topiků A,B,C,D (tj. nemusí se na ně subscribovat znovu)

...pořád ale platí, že klient má pode MQTT specifikace povinnost držet spojení otevřené (musí reagovat na zprávy, musí posílat PINGREQ).

Výš napsané platí pro protokol MQTT. MQTT-SN je jiný protokol než MQTT a je speciálně určen pro jednoduché sensory. Mj. nevyžaduje udržovat spojení a umožňuje klientům přecházet do spánku (kdy nepřijímají zprávy). Po sémantické stránce je ale s MQTT plně kompatibilní (v praxi to znamená, že naprogramovat MQTT <-> MQTT-SN bridge je relativně jednoduché).

Specifikace protokolu MQTT je tady: http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/MQTT_V3.1_Protocol_Specific.pdf

Specifikace protokolu MQTT-SN je tady: http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf

Superior answer.

Ja myslel, ze to SN je jen nejaka konfigurace, ale to je uplne jiny protokol, diky za detailni vysvetleni...

No v mem pripade se mi zda stejne lepsi Persistent Session. Jasne, musim udelat skalovatelnou architekturu. Message broker nebude mit problem persistovat data smerem k zarizenim i po nekolik dni vypadku (uvazuju, ze se zarizeni rozbije a nekdo ho musi vymenit). I pokud by tam litaly tisice zprav, tak jsem v pohode.

Podobnym zpusobem jsem nekdy pouzival Kafku broker, ze slouzil jako obrovsky zasobnik dat.

Zaver: Ale stejne se jdu detailneji kouknout na SN, mozna ze zitra to uvidim jinak.. :-)

Pekny vecer, resp. rano.