Ottimizzazione dell'utilizzo dei dati di rete nel tracker dei veicoli

Question

Ottimizzazione dell'utilizzo dei dati di rete nel tracker dei veicoli

#1 da (2 voti)

0

Attualmente sto lavorando a un'applicazione Android che trasmette la posizione del dispositivo ogni 5 secondi.

Pseudo che mostra la procedura corrente dell'app:

deviceLocation = getLocation()

if (hasChanged(deviceLocation)) {
    putRequestWithLocation();
} else {
    // Send heartbeat so we at least know device is still connected
    putRequestEmpty();
}

Questo è l'effettivo codice Java utilizzato per inviare la richiesta put:

// The data variable is a comma separated string, e.g:
// 50.343423,-1.349545,1 (lat, lon, vehicleid)

try {
    URL url = new URL(apiEndpoint);
    HttpURLConnection httpCon = (HttpURLConnection) url.openConnection();
    httpCon.setDoOutput(true);
    httpCon.setRequestMethod("PUT");
    OutputStreamWriter out = new OutputStreamWriter(httpCon.getOutputStream());
    out.write(data);
    out.close();
    httpCon.getInputStream();
} catch (MalformedURLException e) {
    e.printStackTrace();
} catch (IOException e) {
    e.printStackTrace();
}

La mia domanda è duplice:

1) Si possono fare ottimizzazioni alla richiesta HTTP PUT sopra descritta per ridurre le dimensioni del pacchetto e quindi ottimizzare l'utilizzo della rete?

2) Una connessione socket sarebbe un'idea migliore in base alla frequenza con cui inviamo i dati del veicolo?

Grazie in anticipo!

java http networking sockets android

posta jskidd3 23.10.2018 - 20:04

fonte

1 risposta

Leggi altre domande sui tag java http networking sockets android

Test unitari che riguardano funzioni e oggetti della libreria C ++, discussioni, classi e conflitti

score 2 · Answer 1

Prospettiva

Alcuni dei calcoli sulla busta per mettere le cose in prospettiva:

Supponiamo che la gestione di una singola richiesta di questo tipo consuma 2 kB di dati. Sono 24 kB di dati al minuto, 1,44 MB all'ora. 34,56 MB al giorno, 1,04 GB mensili. Non è né un numero né un numero piccolo (almeno per un tipico piano commerciale / di consumo qui nell'Europa orientale). Potresti prendere in considerazione solo l'avviso dell'utente.

Inefficienze e loro rimozione

Ci sono tre fonti di spese generali per te:

Handshaking TLS (si usa TLS, sì?)
Intestazioni HTTP
Codifica dati inefficiente

esaminandoli:

TLS handshaking

Qui vuoi mantenere vivi i tuoi collegamenti - quindi le heartbeets dei 5 non sono in realtà una cattiva idea (dato che i keepalive sarebbero comunque inviati).

Intestazioni HTTP

Qui l'idea di inviare dati grezzi invece della richiesta HTTP è abbastanza buona: ti fa risparmiare qualche centinaio di byte su ogni richiesta ma hai bisogno del tuo framing (di solito solo la lunghezza dei dati che precede i dati reali, diciamo due byte).

Codifica dei dati

Qualunque cosa tu faccia - una buona codifica binaria sarà sempre più stretta di una rappresentazione testuale leggibile dall'uomo. È possibile rappresentare la longitudine e la latitudine come numeri interi senza segno a 32 bit - guardando i propri esempi sono sufficienti 9 cifre decimali con precisione fissa. Anche conoscere la codifica scelta aiuta - lo mostrerò più tardi. Personalmente raccomando i buffer del protocollo di Google per questo.

Dopo

Back-of-the-envelope ottimizzato. Supponiamo di avere il seguente messaggio Protocol Buffer:

message Status {
  fixed32 session_id = 1;
  fixed32 lat = 2;
  fixed32 lon = 3;
  bool vechicled = 4;
}

Quanto è grande questo messaggio? Non andrò nei dettagli ma, a seconda dello stato del file, dovrebbe essere 15 o 17 bytess: i valori predefiniti come false per bool non sono nemmeno codificati. Aggiungi la lunghezza del messaggio e otteniamo 19 byte di dati. L'invio della stessa roba su HTTP renderebbe solo le richieste circa 200 byte circa con tutte le intestazioni richieste. Getta la riapertura delle connessioni, strette di mano TLS e bene ... L'utente potrebbe essere grato.