Applicazione in tempo reale: è un buon modo di comunicare con il mio server? [trasmissione molto frequente]

Question

Applicazione in tempo reale: è un buon modo di comunicare con il mio server? [trasmissione molto frequente]

#1 da (0 voti)

0

Sto facendo un'applicazione che raccoglie dati di timestamp e GPS dal telefono di un utente a intervalli insieme ad altre informazioni.

Attualmente, ogni tupla generata viene inviata tramite TCP al mio server delle applicazioni non appena viene generata la tupla.

Si tratta di un modo non convenzionale di trasmettere dati considerando che potrebbe trasmettere dati più volte al minuto? Sono preoccupato per le risorse del dispositivo, come consumo di batteria e piano dati, ecc. La trasmissione avviene principalmente tramite reti cellulari o WIFI.

È importante che il server riceva informazioni in tempo reale o quasi in tempo reale, quindi non vedo nessun altro modo per farlo.

Qualche informazione?

real-time tcp

posta carva 24.04.2017 - 23:23

fonte

1 risposta

Leggi altre domande sui tag real-time tcp

Best practice per richiedere la scrittura simultanea negli oggetti di archiviazione È buona pratica creare più file di guerra per app Web da un repository di origine?

score 0 · Accepted Answer

Se assolutamente richiede di essere in tempo reale (o il più vicino possibile) allora forse questa è la cosa migliore che puoi fare.

Se stai bene con close in tempo reale puoi salvare alcuni messaggi e poi inviarli in un unico messaggio digest al server. Ogni sottomessaggio includerebbe ovviamente il timestamp che mostra quando è stato generato in modo che il server possa ancora inserirli nella sequenza cronologica corretta. Quindi, ogni n secondi (dovrai determinare il valore ottimale per n ), invierai un messaggio digest. In questo modo, invece di inviare messaggi 10 volte al minuto, è possibile inviare solo 2 o 3 volte al minuto, risparmiando la batteria del dispositivo di trasmissione.

Naturalmente, se questo è il tipo di situazione in cui le vite potrebbero dipendere da risposte veloci dal server, questo approccio potrebbe non essere abbastanza buono. Inoltre, non ho idea di quanta energia della batteria in più le trasmissioni extra potrebbero utilizzare contro una singola (ma necessariamente più lunga) trasmissione. Ciò richiederebbe probabilmente qualche sperimentazione reale.