fano
02-11-2013, 14:04
Salve a tutti abbiamo un problemino per un Progetto, la nostra "Applicazione" è in realtà un'applicazione distribuita cioè formata da più applicazioni (che girano su Linux X86 e ARM[1]) per esempio:
Supervisor controlla tutte le altre
Logger
Driver(s)
Manager(s)
Logica di Controllo
Interfaccia "Operatore"
Interfaccia "Utente"
Storage (per ora sqlite)
Logger
Configuratore (se le cose vanno bene un giorno sarà lo Storage stesso o parte di esso...)
tutti i membri de "l'Applicazione" comunicano tra loro via rete e/o via code realtime, l'Applicazione può essere distribuita da 1 a N macchine, l'IPC è proprietario (nostra proprietà, quindi nessun problema c'ho i sorgenti!).
Non vi posso dire che cosa sarà, ma diciamo che se un giorno andrete in Polonia lo scoprirete :D
Il problema è lo Storage che sta divenendo un collo di bottiglia: infatti noi lo usiamo per la diagnostica, per far conoscere ai Manager(s) quanti Driver(s) controllano (no, non è schiantato... è quasi Plug & Play :Prrr: ) e, ovviamente, per salvare i dati propri de "l'Applicazione" (denaro, denaro, denaro... per la maggior parte :mbe:) quindi circa 1 volta al secondo accade:
Evento da Periferica X
Manager Y, "X" è una mia periferica? So una sega io, lo chiedo allo Storage!
Storage apre un ridicolo file binario che sqlite chiama database, fa una SELECT complessa a piacere, crea un json (in C robe turche!) e risponde al Manager e/o va in core :muro:
Manager Y scopre che era la sua periferica, apre il json cerca ciò che gli serve, elabora, smanazza e poi decide: è successo qualcosa d'interessante? Sì lo mando al Controllore, no è solo un evento diagnostico lo dico allo Storage.
Controllore Z, "Y" è un mio Manager? So una sega io, chiedo allo Storage...
...
Tutto questo avveniva in origine su rete e sulla "carta" funzionava pure, ma appena ci siamo messi a parlare con una Periferica Real Time, essa ci ha dichiarato scollegati (sì avete capito bene LEI ha detto che il Controllore era scollegato, "l'Applicazione" per la gioia ha reagito andando in core!) :cry:
Abbiamo quindi provato ad usare ANCHE le code Real Time di Linux, la velocità è cambiata di un fattore 1000 :doh:; la periferica RealTime ora funziona regolarmente, ma il "traffico" rimane alto e, comunque, da un punto di vista dell'efficienza non può essere corretto.
Posto che sqlite si leva dalle p@lle e si passa a mysql, ci troviamo, ora, ad un bivio o, più probabilmente, ad un trivio:
Lo Storage non esiste più come reale applicazione, ma diventa una libreria. Questo significa che ogni membro dell'Applicazione "conosce" lo Storage ed esegue direttamente le operazioni su di esso. In questo caso non saprei a chi far creare il DB e inizializzare le Tabelle di "anagrafica" :confused:
Da un punto di vista "estetico", NON mi piace... ma il tempo per eseguire le operazioni diventerà intorno allo 0...
Lo Storage esiste ancora, ma diventa un'applicazione Multithread (magari scritta in un linguaggio più moderno, il C mi ha stufato, io vorrei usare Java, ma se proprio me lo impediscono almeno Qt/C++), l'IPC rimane in piedi, ma ogni membro dell'Applicazione ha un suo "thread" e canale dedicato. Mi pare una soluzione più pulita, io sono convinto sia sqlite il collo di bottiglia!
Una sorta di ibrido? Una libreria che è anche un'applicazione? Lasciate andare la vostra fantasia come dico sempre io: non fossilizziamoci su JAVA o C/C++, se lo fa Python o Perl, si valuta quelli...
I Polacchi, ovviamente, se lo tengono così, ma per i prossimi progetti le cose DEVONO cambiare, notate che per la natura stessa de "l'Applicazione" se riusciamo a mantenere l'interfaccia identica con l'applicazione (e la 2 è la via IMHO) io posso sostituirla e il resto de "l'Applicazione" non si deve accorgere della differenza... o andrà in core e allora anch'io sono morto, ma questa è un'altra Storia :ciapet:
[1]Porting fatto da un collega bestemmiando in Sanscrito perché ho usato troppe estensioni di GCC 4.4 e la Moxa fornisce un toolchain basato su GCC 3.9 se ricordo bene :Prrr:
Supervisor controlla tutte le altre
Logger
Driver(s)
Manager(s)
Logica di Controllo
Interfaccia "Operatore"
Interfaccia "Utente"
Storage (per ora sqlite)
Logger
Configuratore (se le cose vanno bene un giorno sarà lo Storage stesso o parte di esso...)
tutti i membri de "l'Applicazione" comunicano tra loro via rete e/o via code realtime, l'Applicazione può essere distribuita da 1 a N macchine, l'IPC è proprietario (nostra proprietà, quindi nessun problema c'ho i sorgenti!).
Non vi posso dire che cosa sarà, ma diciamo che se un giorno andrete in Polonia lo scoprirete :D
Il problema è lo Storage che sta divenendo un collo di bottiglia: infatti noi lo usiamo per la diagnostica, per far conoscere ai Manager(s) quanti Driver(s) controllano (no, non è schiantato... è quasi Plug & Play :Prrr: ) e, ovviamente, per salvare i dati propri de "l'Applicazione" (denaro, denaro, denaro... per la maggior parte :mbe:) quindi circa 1 volta al secondo accade:
Evento da Periferica X
Manager Y, "X" è una mia periferica? So una sega io, lo chiedo allo Storage!
Storage apre un ridicolo file binario che sqlite chiama database, fa una SELECT complessa a piacere, crea un json (in C robe turche!) e risponde al Manager e/o va in core :muro:
Manager Y scopre che era la sua periferica, apre il json cerca ciò che gli serve, elabora, smanazza e poi decide: è successo qualcosa d'interessante? Sì lo mando al Controllore, no è solo un evento diagnostico lo dico allo Storage.
Controllore Z, "Y" è un mio Manager? So una sega io, chiedo allo Storage...
...
Tutto questo avveniva in origine su rete e sulla "carta" funzionava pure, ma appena ci siamo messi a parlare con una Periferica Real Time, essa ci ha dichiarato scollegati (sì avete capito bene LEI ha detto che il Controllore era scollegato, "l'Applicazione" per la gioia ha reagito andando in core!) :cry:
Abbiamo quindi provato ad usare ANCHE le code Real Time di Linux, la velocità è cambiata di un fattore 1000 :doh:; la periferica RealTime ora funziona regolarmente, ma il "traffico" rimane alto e, comunque, da un punto di vista dell'efficienza non può essere corretto.
Posto che sqlite si leva dalle p@lle e si passa a mysql, ci troviamo, ora, ad un bivio o, più probabilmente, ad un trivio:
Lo Storage non esiste più come reale applicazione, ma diventa una libreria. Questo significa che ogni membro dell'Applicazione "conosce" lo Storage ed esegue direttamente le operazioni su di esso. In questo caso non saprei a chi far creare il DB e inizializzare le Tabelle di "anagrafica" :confused:
Da un punto di vista "estetico", NON mi piace... ma il tempo per eseguire le operazioni diventerà intorno allo 0...
Lo Storage esiste ancora, ma diventa un'applicazione Multithread (magari scritta in un linguaggio più moderno, il C mi ha stufato, io vorrei usare Java, ma se proprio me lo impediscono almeno Qt/C++), l'IPC rimane in piedi, ma ogni membro dell'Applicazione ha un suo "thread" e canale dedicato. Mi pare una soluzione più pulita, io sono convinto sia sqlite il collo di bottiglia!
Una sorta di ibrido? Una libreria che è anche un'applicazione? Lasciate andare la vostra fantasia come dico sempre io: non fossilizziamoci su JAVA o C/C++, se lo fa Python o Perl, si valuta quelli...
I Polacchi, ovviamente, se lo tengono così, ma per i prossimi progetti le cose DEVONO cambiare, notate che per la natura stessa de "l'Applicazione" se riusciamo a mantenere l'interfaccia identica con l'applicazione (e la 2 è la via IMHO) io posso sostituirla e il resto de "l'Applicazione" non si deve accorgere della differenza... o andrà in core e allora anch'io sono morto, ma questa è un'altra Storia :ciapet:
[1]Porting fatto da un collega bestemmiando in Sanscrito perché ho usato troppe estensioni di GCC 4.4 e la Moxa fornisce un toolchain basato su GCC 3.9 se ricordo bene :Prrr: