Sziasztok!
Egy szenzoros-adatgyujtos temara probalnam felhasznalni az MQTT protokollt, mosquitto segitsegevel. Kis teszteles utan kiderult hogy noha a broker bridging az tok jol megy, a "server" broker a "client" brokerhez cimzett retain-nek jelzett uzeneteket mar nem tarolja el/le. Azaz, mas szavakkal: ha a "server" brokerhez nem csatlakozik subscriber a "client" brokernek kuldott retain uzenet feladasanak pillanataban, akkor kesobb sem jut el a "server" brokerhez csatlakozo subscriber-hez az uzenet.
Az MQTT-vel kapcsolatos alapgondolatunk az lenne hogy mind a szenzorok, mind a szenzorok adatait felhasznalo gepek (loggerek, plotterek, frontendek, stb) csak localhost-on futo brokerekhez kapcsolodnanak. Azaz a szenzor is local-ban publikal, a felhasznalok is csak local-ban iratkoznak fel, hogy a subscription/publication folyamatot veletlenul se blokkolja az instabil net. Aztan a brokerek egymas kozott megoldjak, ha megis instabil a net. Es emellett ertelemszeruen minden szenzor egy retain attributumu, timestamp-pal ellatott uzenetet kuldene. Igy barki megtudja legalabb azt hogy ki/mi volt az utolso ertelmes adat, blokkolas nelkul (ami a mi celjainknak tokeletes).
Csinalt mar valaki ilyesmit?
Thx, A.
Hozzászólások
MQTT nem erre való.
Pontosabban a mosquitto-nak nincs (nem volt, amikor néztem) perzisztens rétege.
Az én utam saját protokoll után;
AMQP(Rabbit,Qpid)->MQTT(mosq, Paho)->Qpid Proton P2P->0MQ->Új saját cucc perzisztencia réteggel. (Amit viszont tudok portolni Cortex M3/4-re is.)
Ráadásul beágyazott (nem Linux) rendszeren a Mosquitto/Paho adattitkosítása nem triviális az OpenSSL binding miatt. A 0MQ ECC-je csak egy fokkal könnyebb.
Mit ertesz perzisztens reteg alatt ebben a kontextusban? Az MQTT "retained messages" megoldasa az azert olyan ertelmebnen nem rossz hogy minden kliens kapasbol tudja hogy mennyire up-to-date az informacio es tud dontest hozni ennek fenyeben. Ami (nekunk legalabbis) ele'g.
Szenzoros cuccoknal meg persze van egy-ket mas kategorias problema is (pl csuoszatlagok, min-max-stddev ertekek szamolasa, idoablakozas, ...) amire persze az MQTT nem ad megoldast. De azt tisztan local-ban mar lehet(ne) kezelni.