Italian [B4X] Mqtt vs Firebase Realtime vs notifiche push (Firebase Cloud Messaging)

[amorosik]

Per comunicare rapidamente da pc centrale a uno o piu' smartphone Android ho usato finora Firebase Realtime oppure le notifiche push Firebase Cloud Messaging
Vedo che usando il sistema di messaggistica su server Mqtt sono realizzabili grossomodo le stesse funzionalita'
Ci sarebbe pero' il vantaggio del 'tutto in casa' perche' tirar su un server/broker mqtt su macchine Windows e' operazione non estremamente complessa
La domanda e': dal punto di vista delle prestazioni, per scambiare messaggi diciamo max un migliaio di caratteri, un sistema basato su Mqtt e' paragonabile al sistema Firebase?
Quello che vorrei capire e' se un sistema di messaggi basato su mqtt e' altrettanto reattivo di analogo sistema basato su Firebase Realtime o notifiche Push

 

[udg]

Limitatamente alla mia esperienza (mosquitto su CentOS7), FCM funziona "meglio".
La differenza fondamentale è che i messaggi FCM vengono inoltrati all'app dal sistema operativo in modo automatico. Nei miei test, messaggi inviati a telefono spento, venivano recapitati subito dopo l'accensione (anche quando tra invio e riaccensione passava un bel lasso di tempo).
Con MQTT (forse anche per mie carenze in fase di configurazione) questo non avveniva. Dovevo necessariamente avviare l'app (o averla con #StartAtBoot) per ricevere messaggi "in sospeso" e, se non ricordo male, neanche tutti.

In ogni caso (FCM o MQTT), sembra che buona norma sia richiedere al server eventuali messaggi in attesa al lancio dell'app. In pratica bisognerebbe salvare in locale l'ID dell'ultimo messaggio ricevuto e chiedere al server (non al broker) di inviare tutte le info successive. Nel caso arrivino anche dal broker, scartare i "doppioni".

 

[amorosik]

Ringrazio per la condivisione preziosa esperienza
Per quanto riguarda i messaggi 'a telefono spento' per la mia applicazione sono irrilevanti perche' tutto aviene in diretta, se un messaggio inviato da pc verso telefoni viene perso e' perso e basta, il telefono non reagira' e quindi pur essendo una funzionalita' importante per un sistema di messaggistica classica, per me in questo momento non lo e'
Quello che mi interessava e' proprio la reattivita', la velocita' consegna messaggi
Voglio dire, usando Firebase Realtime o le notifiche push, da invio pc a ricezione su Android passavano decimi di secondo, qualche volta un secondo, ma comunque sempre nel 'quasi istantaneo'
Se usassi Mqtt saremmo allo stesso livello, quindi siamo sui decimi di secondo oppure ben oltre?

 

[udg]

Anche con MQTT i messaggi arrivavano quasi immediatamente. Però, in generale, i tempi possono essere influenzati da molteplici fattori. I primi che vengono in mente sono:
- efficienza del server
- banda a disposizione del server
- infrastruttura dei provider coinvolti
- distanza geografica (es. server in USA e client in Italia)
- efficienza del device

Non ho mai utilizzato FR, quindi non saprei confrontarlo in termini di complessità ed efficienza.

 

[amorosik]

Dopo un po di test con tutti e tre i sistemi, per favorire le scelte di chi verra', posso dire che Mqtt puo' tranquillamente sostituire Firebase Realtime, almeno per carichi di lavoro che non siano estremamente gravosi, dove l'infrastruttura di Google non ha rivali come performance
Per 'estremamente' gravosi intendo scambiare messaggi a migliaia al secondo
Ma se restiamo nell'ordine delle decine di messaggi/sec max, un server Mqtt gratuito come Mosquitto, installato su un pc lan, e quindi il tutto a costo zero, assicura prestazioni e reattivita' sufficienti per essere considerato un sistema quasi real-time
Col grosso vantaggio, oltre risparmio puramente economico, di avere tutto sotto controllo compreso il codice sorgente di un server mqtt, vedi esempi B4J Broker, che consentono di realizzare integrazioni dirette coi database aziendali se necessario
Per quanto riguarda il sistema Fcm, le notifiche di Google, essendo un sistema che 'entra' nativamente nei meandri Android, e' insostituibile per 'risvegliare' l'app dormiente e renderla attiva

 

[LucaMs]

... e tanto per complicarti la vita ? , aggiungo che la stessa cosa che fai con MQTT (broker locale) puoi farla con un websocket server, sempre B4J e sempre in locale ed hai anche maggior controllo sul tuo server.

 

[amorosik]

Dici?
Con un websocket server locale, come fai ad 'avvertire' 10 smartphone che devono fare una certa cosa?
Mettere loro ad interrogare il server non vale perche' e' di una ineleganza difficilmente raggiungibile
Anche per quanto riguarda il 'controllo del tuo server' direi che, usando come server mqtt un programma realizzato con B4J, non sia possibile avere un controllo piu' efficace
Da quanto ho sperimentato finora, credo che per inviare/ricevere comandi da un dispositivo all'altro, l'mqtt sia l'ideale
- leggero di trasmissione
- aggratisse come server, e supercontrollabile se usi broker B4J
- usabile anche per comunicare verso dispositivi che non sai che ip hanno (come i telefoni)
- ma soprattutto molto reattivo, molto rapido nel trasferire le informazioni da mittente a destinatario
In realta' gli manca una cosa, per me importante, ma si tratta di aggirare la limitazione

 

[LucaMs]

Con un websocket server locale, come fai ad 'avvertire' 10 smartphone che devono fare una certa cosa?

Sul server avrai una Map contenente i websocket connessi ed invierai un msg a quelli che vuoi.

 

[LucaMs]

In realta' gli manca una cosa, per me importante, ma si tratta di aggirare la limitazione

Ovvero?

 

[amorosik]

Sul server avrai una Map contenente i websocket connessi ed invierai un msg a quelli che vuoi.

Nessun socket rimane connesso, solitamente
Quando i telefoni desiderano comunicare, aprono un socket sul server, mandano dati, poi chiudono
Se devono mandare un comando ogni minuto non e' che li si fa stare attaccati per tutto il tempo

 

[LucaMs]

Nessun socket rimane connesso, solitamente
Quando i telefoni desiderano comunicare, aprono un socket sul server, mandano dati, poi chiudono
Se devono mandare un comando ogni minuto non e' che li si fa stare attaccati per tutto il tempo

Dipende da cosa devi fare. Per un bellissimo gioco a turni, come sarà il mio ?, il WEBsocket sarà connesso e l'utente in gioco finché lo desidera.

 

[amorosik]

Ovvero?

Che non trovo codice per interfacciarlo nativamente con Microsoft Access
Vorrei realizzare una funzione in vba che possa 'abbonarsi' ad alcuni topic e reagisca ai messaggi ricevuti
Quello che attualmente fanno le sub mqtt_MessageArrived per capirci
Ho cercato un po' ma finora trovato niente, mi tocca mettere in ricezione programma B4J che poi 'parla' col vba del gestionale
Funzionare fuziona, ma non mi piace per niente

 

[LucaMs]

Ecco, hai trovato un buon motivo per passare da MQTT a server websocket B4J

 

[LucaMs]

Fate una colletta e vi sviluppo un server websocket + client (minimi) facilmente riutilizzabile.

Quando arriverete a 200€ fatemi un fischio

(scherzo; è sufficiente prendere uno degli esempi di Erel).

 

[amorosik]

Fate una colletta e vi sviluppo un server websocket + client (minimi) facilmente riutilizzabile.
Quando arriverete a 200€ fatemi un fischio
(scherzo; è sufficiente prende uno degli esempi di Erel).

Queste sono cose che fanno tutti
Lavora su funzioni vba per inviare/ricevere messaggi via mqtt
Questa non ce l'ha ancora nessuno

 

[LucaMs]

Queste sono cose che fanno tutti

Se tu avessi trovato sul sito una generica coppia client-server websocket, magari avresti usato questa, anziché MQTT

 

[LucaMs]

Ah, che poi ho letto VBA ma non ho fatto caso che parlavi di Access, ho pensato ad Excel.

Con Access o qualunque altro DB, ci vuole "un attimo" (non parlo di MQTT, ovviamente).