Come funzionano le prese tramite connessioni wireless?


15

Ho lavorato solo su applicazioni lato client (in particolare mobili) tramite Android, in cui tutta la rete è gestita a livello HTTP utilizzando componenti forniti da framework come HttpUrlConnection.

Ma i sistemi di messaggistica push come Websocket / XMPP ecc. Mantengono tutti una connessione persistente al server. Anche GCM di Google, integrato nei dispositivi supportati da Google Play, mantiene una connessione persistente ai server.

La mia domanda è: come funziona senza scaricare la batteria? Se effettuiamo richieste HTTP continue in sequenza, il consumo della batteria è significativo. Come vengono mantenute queste connessioni persistenti senza riscontrare lo stesso problema?


La tua domanda su socket o websocket? Sono due cose molto diverse.
svick,

@svick La mia domanda riguardava i socket.
Vinay S Shenoy,

Risposte:


23

Una connessione TCP aperta è uno stato logico. Ciò non implica che i dati vengano sempre inviati avanti e indietro. Dopo la stretta di mano a tre vie iniziale sei entrato nello stato "connesso". Sei in quello stato fino a quando si verifica una disconnessione a 3 vie o un keep-alive non riesce.

Durante la durata della connessione, è possibile stabilire risorse dal supporto "fisico" sottostante per eseguire trasferimenti di dati per quella connessione. Nel caso di una connessione cablata, si tratta di trasferire in giro frame ethernet. Nel caso di una connessione wireless 3G / 4G, ciò avviene stabilendo connessioni con i protocolli di livello inferiore, se necessario.

Pertanto, per tutta la durata della connessione, non esiste alcuna connessione dati fisica sottostante. Si trova invece in sospeso in attesa che uno dei peer nella connessione TCP debba inviare i dati.

Un altro problema è che TCP è basato su ack . I peer TCP possono tenersi reciprocamente abbastanza efficienti su ciò che è stato sicuramente ricevuto. In caso di errore, TCP ritrasmetterà. Funziona benissimo per collegamenti fisici abbastanza affidabili, ma tende a cadere a pezzi in collegamenti molto rumorosi / interrotti, come le connessioni wireless. Come puoi immaginare, ack / ritrasmissioni si verificherebbero molto frequentemente in questi ambienti.

Quindi, in genere, il protocollo wireless sottostante fa tutto il possibile per ridurre la necessità di ritrasmissioni TCP. Ad esempio, ci sono molti errori nel controllo integrato nel livello wireless. Anche i peer nel regno wireless (la stazione base / telefono) usano un protocollo basato su nak per dire all'altro lato quando non hanno ricevuto qualcosa. Essere basati su nak riduce il sovraccarico nel controllo degli errori (supponiamo che tutto vada bene a meno che l'altra parte non dica di no). Aiuta anche a correggere gli errori primapassano al livello TCP, evitando così un sacco di thrashing TCP nel tentativo di ritrasmettere. Inoltre, riduce la portata di eventuali ritrasmissioni ai peer wireless - il telefono non ha bisogno di chiedere nuovamente al pacchetto da qualche parte su Internet il pacchetto, solo la stazione base tramite il collegamento wireless.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.