Quale metodo di comunicazione su wireless instabile?

[sottovento]

Cari colleghi
nonostante sia S.Stefano, qualcuno lavora lo stesso :(

Mi servirebbe un vostro parere: ho un applicativo che deve essere montato su una serie di "muletti" che si muovono in un cortile molto ampio.
L'applicativo dice all'operatore dove andare e cosa fare. Il segnale purtroppo non copre in maniera decente tutto il cortile, in alcuni punti e' mediocre o meno (inferiore a -70dB).
Nonostante questo, la connessione wireless e' mantenuta ma la velocita' di trasferimento dei dati e' davvero bassa.

Chi ha fatto l'applicativo non ha pensato ad una simile situazione ed ha scritto l'applicazione accedendo direttamente al database per prelevare le istruzioni da dare agli operatori. Poi ha provato tutto in ufficio e ha detto "da me funziona benissimo ed e' veloce".

Vorrei migliorarne le prestazioni, magari cambiando modo di comunicare.
Ovviamente non e' come sputare in terra... e' un lavoro che richiede un certo impegno, quindi prima di cominciare chiedo a chiunque passi di qui:

Quale metodo di comunicazione implementereste?
1 - Una socket via tcp/ip?
2 - Una comunicazione udp/ip?
3 - Remote calls? (tipo Corba/RMI/etc.);
4 - Manterreste la connessione al database?
5 - ....

Attualmente la connessione al database e' estremamente lenta, ma il programmatore che l'ha scelta ha pensato al fatto che le riconnessioni vengono gestite automaticamente dal client del database. Era quindi una soluzione molto semplice da attuare.

Io sarei per una riscrittura mediante udp/ip (datagram): dovrebbe essere la piu' veloce in quando non richiede ritrasmissioni.
Ovviamente non e' garantito il fatto che i dati arrivino a destinazione, ma potrei anche sopravvivere a questo richiedendo i dati che davvero servono (gestendomi in pratica le ritrasmissioni da solo e solo quando ne ho bisogno).

Altre idee?

Dimenticavo - un altro dato importante e' che il numero di clienti (muletti) che vanno a zonzo per il cortile e' molto limitato (per ora sono 4, in futuro saranno di piu' ma si puo' pensare che non supereranno mai la decina). Questo potrebbe aiutare a mantenere gli stati di ordini, ... sul server.

Buon Natale a tutti!

[tomminno]

Se hai problemi di stabilità della rete, usare l'UDP mi pare un suicidio. Non richiede ritrasmissioni, ma non è garantita la consegna.
Bisognerebbe capire la quantità dei dati scambiati e la frequenza con cui vi viene fatto accesso.
Al momento visto l'utilizzo della connessione diretta al db, mi pare di capire che non ci sia una logica centralizzata, ma che ogni muletto faccia per conto suo, io proverei un approccio client-server visto anche il numero tendenzialmente crescente dei muletti. Potrebbero essere possibili ottimizzazioni future es. il server che invia i dati al muletto in base alla vicinanza rispetto alla prossima destinazione.
Socket con un "webservice" di qualche tipo in modo da ridurre al minimo l'overhead potrebbe essere una strada.

[ericmarone]

io andrei di ... http.
metterei paginette php sul server che prendono il minimo possibile di comandi, e rispondono con i dati del server.
perché? perché è completamente stateless, questa è la chiave per situazioni di inaffidabilità di circuito.
chiaramente si può pensare a mille altre soluzioni più o meno evolute, ma dubito si possa migliorare più di questa (che è grosso modo un pomeriggio di lavoro).
tra l'altro si può fare il debug con... gli smartphone, fingendo che siano muletti e portandoli in giro nell'area in cui verificare la copertura.
quindi

1 - Una socket via tcp/ip?
2 - Una comunicazione udp/ip?
3 - Remote calls? (tipo Corba/RMI/etc.);
4 - Manterreste la connessione al database?
5 - ....
1. no
2. assolutamente no, perché poi c'è tutto il pippone dei pacchetti persi da gestire da applicazione
3. è grosso modo quello che farei, ma con... http. il vero limite è il timeout elevato per la mancata risposta. dipende da quanti millisecondi il muletto può attendere i dati (qualora non arrivassero)
4. no
:mbe:

[sottovento]

Grazie per i suggerimenti.
Ovviamente ci devo pensare su ancora molto, perche' la modifica da fare all'applicativo e' piuttosto importante.

Alcune informazioni in piu':
- ho fatto una piccola applicazione che registra periodicamente
- data/ora
- posizione data dal gps a bordo del "muletto" (sono muletti speciali,
spostano piu' di 20 tonnellate alla volta)
- livello del segnale in quel momento ed in tal punto.

La situazione varia parecchio a seconda del punto di rilevazione ma il livello del segnale non e' mai accettabile.
La quantita' di dati e' purtroppo piuttosto grande: liste di materiali e di posizioni, oltre che una quantita' enorme degli stessi dati elaborati dal server (e scritti nel database) per disegnare i suddetti dati in 3D.
Si tratta quindi di dati ridondanti.
Credo che si possa sfoltire molto e ridurre parecchio la quantita' dei dati necessari. Inoltre gli operatori sul muletto DETESTANO la rappresentazione 3D perche' non fornisce loro alcuna ulteriore informazione ed e' difficilmente maneggiabile. Propenderei per eliminarla.

Grazie per i suggerimenti, li ho apprezzati veramente. Soprattutto relativamente al web service, che non avevo nemmeno preso in considerazione.

Sono tuttavia sorpreso di come mi abbiate "ucciso" UDP! Stavo infatti propendendo per questo: e' vero, non garantisce la consegna dei pacchetti ma tutto sommato potrebbe anche essere un vantaggio rispetto a TCP, il quale rimane "inchiodato" fino a quando scade un timeout e la connessione e' persa.
Se facessi una gestione "furba" (e magari non troppo pesante) dei datagram udp magari potrei essere davvero veloce, visto che probabilmente e' il sistema con l'overhead piu' piccolo.

Comunque credo che la soluzione "web service" sia la piu' logica, credo che valutero' prima questa. Rimane una certezza: l'attuale sistema di "comunicazione" basato solo sulla connessione al database (+ trigger per verificare se qualcosa e' cambiato nel DB) e' assolutamente inaccettabile ed occorre metterci le mani, purtroppo :(

[tomminno]

Grazie per i suggerimenti.
Ovviamente ci devo pensare su ancora molto, perche' la modifica da fare all'applicativo e' piuttosto importante.

Alcune informazioni in piu':
- ho fatto una piccola applicazione che registra periodicamente
- data/ora
- posizione data dal gps a bordo del "muletto" (sono muletti speciali,
spostano piu' di 20 tonnellate alla volta)
- livello del segnale in quel momento ed in tal punto.

La situazione varia parecchio a seconda del punto di rilevazione ma il livello del segnale non e' mai accettabile.
La quantita' di dati e' purtroppo piuttosto grande: liste di materiali e di posizioni, oltre che una quantita' enorme degli stessi dati elaborati dal server (e scritti nel database) per disegnare i suddetti dati in 3D.
Si tratta quindi di dati ridondanti.
Credo che si possa sfoltire molto e ridurre parecchio la quantita' dei dati necessari. Inoltre gli operatori sul muletto DETESTANO la rappresentazione 3D perche' non fornisce loro alcuna ulteriore informazione ed e' difficilmente maneggiabile. Propenderei per eliminarla.


Ipotesi: vista la mole di dati, sarebbe possibile che i muletti scarichino il grosso dei dati in un punto con ampia copertura es. inizio turno e successivamente solo dei piccoli aggiornamenti?


Sono tuttavia sorpreso di come mi abbiate "ucciso" UDP! Stavo infatti propendendo per questo: e' vero, non garantisce la consegna dei pacchetti ma tutto sommato potrebbe anche essere un vantaggio rispetto a TCP, il quale rimane "inchiodato" fino a quando scade un timeout e la connessione e' persa.
Se facessi una gestione "furba" (e magari non troppo pesante) dei datagram udp magari potrei essere davvero veloce, visto che probabilmente e' il sistema con l'overhead piu' piccolo.


In pratica vorresti implementare a mano il TCP sopra UDP ;)


Comunque credo che la soluzione "web service" sia la piu' logica, credo che valutero' prima questa. Rimane una certezza: l'attuale sistema di "comunicazione" basato solo sulla connessione al database (+ trigger per verificare se qualcosa e' cambiato nel DB) e' assolutamente inaccettabile ed occorre metterci le mani, purtroppo :(

La soluzione webservice è quella più modulare, se hai possibilità di adottare una comunicazione bidirezionale es con websocket ancora meglio, implementi una sorta di push notification così puoi risparmiare banda e accessi.

[sottovento]

Ipotesi: vista la mole di dati, sarebbe possibile che i muletti scarichino il grosso dei dati in un punto con ampia copertura es. inizio turno e successivamente solo dei piccoli aggiornamenti?

Tomminno, prima di tutto scusa il mio colpevole ritardo con cui rispondo, nonostante il tuo sforzo nell'aiutarmi!!! Chiedo scusa anche a chi e' intervenuto.

Si, stavo pensando esattamente la stessa cosa. Fra l'altro, ho visto che leggere il segnale GPS e leggere il segnale della rete wireless e' piuttosto semplice (ho gia' fatto le prove).
Potrei quindi pensare di scaricare il grosso dei dati quando
- sono in una posizione favorevole (lo so grazie al GPS) AND
- il segnale e' superiore ad una soglia predefinita, per esempio da -70[dB]. Non si tratta di un segnale ottimale (si va a manetta quando il segnale e' almeno -40[dB]) ma segnali cosi' forti non li ho mai rilevati nell'area in cui operano i muletti.



In pratica vorresti implementare a mano il TCP sopra UDP ;)

No, dai. A parte che TCP non e' complessissimo, ma il bello di UDP e' quello di essere veloce ed avere poco overhead.
Purtroppo tcp non sa a cosa mi servono i dati, lui e' tenuto a consegnarli, quando possibile. Se la connessione e' di bassa qualita', vedro' il mio client fermo ad aspettare l'arrivo di qualcosa. Magari qualcosa arriva ma non nell'ordine giusto, quindi i dati non vengono consegnati alla mia applicazione perche' mancano dei pacchetti inviati precedentemente e mai piu' ricevuti.
Quindi l'applicazione non vede arrivare un solo byte fino al timeout.

UDP permetterebbe invece di poter usare quello che arriva. Inoltre conosco l'importanza dei miei dati e posso distinguere fra quelli che assolutamente devono arrivare (e dei quali posso richiedere insistentemente la trasmissione) da quelli che se arrivano li mostro, altrimenti mostro un messaggio del tipo "non pervenuti".
Non ho connessioni, quindi non ho timeout alla scadenza dei quali perdo la connessione ;)



La soluzione webservice è quella più modulare, se hai possibilità di adottare una comunicazione bidirezionale es con websocket ancora meglio, implementi una sorta di push notification così puoi risparmiare banda e accessi.
D'accordissimo. Anzi, di piu': la websocket e' sicuramente LA soluzione.
Sta a vedere quanto mi costa impiegarla, soprattutto in considerazione del fatto che il cliente mi obbliga all'uso del C#.

Ancora una volta: grazie per il tempo che hai dedicato a questo problema. Per prima cosa, cerchero' di individuare l'area in cui il segnale e' piu' forte (GPS + Valutazione del segnale) perche' mi permette di cambiare l'applicazione il meno possibile.
Se poi anche in quel caso il client e' inaccettabilmente lento, mi rassegnero' a cambiare il metodo di comunicazione (ci vorranno settimane)