Supponiamo che Service S voglia inviare i dati all'app mobile nel dispositivo A in tempo arbitrario senza interazione con il client.
qual è il modo migliore per tenere traccia di A IP?
l'unico modo in cui posso pensare è di eseguire un servizio per tenere traccia di A IP pubblico (localmente su A ) se modificato - > aggiorna S database con nuovo IP.
C'è un'idea migliore?
Non farlo. Non puoi presumere che ogni dispositivo abbia un particolare IP univoco, o che tu possa essere in grado di stabilire una connessione con esso.
Ci sono due problemi:
Poiché lo spazio IPv4 è ridicolmente limitato e IPv6 non è universalmente disponibile, molte reti utilizzano la conversione degli indirizzi di rete. Ciò significa: c'è una rete interna con molti indirizzi IP e più dispositivi. Tuttavia, tutte le connessioni sono tradotte da un router in modo che vengano visualizzate su Internet come condivisione di un indirizzo IP (quello del router).
I router sono spesso configurati in modo che le connessioni in uscita siano automaticamente supportate. Ad esempio, immagina una LAN 192.168.0.0/24 con un client 192.168.0.7 e un router su 192.168.0.1 (indirizzo locale). Il router ha un indirizzo pubblico 203.0.113.111 Il client vuole stabilire una connessione TCP con un server a 203.0.113.222:80.
Il client seleziona una porta locale casuale e avvia la connessione (192.168.0.7:49152, 203.0.113.222:80). I pacchetti vengono quindi inviati al router. Il router potrebbe inviare i pacchetti invariato, ma non avremmo mai ricevuto una risposta: l'indirizzo locale 192.168.0.7 non è instradabile. Invece, il router apre una porta esterna e finge che i pacchetti abbiano avuto origine lì - dall'esterno vediamo la connessione (203.0.113.111:65535, 203.0.113.222:80).
Quando il server risponde, questa risposta viene inviata al router su 203.0.113.111:65535. Il router sa che questa porta viene utilizzata per NAT e quindi inoltra il pacchetto al client su 192.168.0.7:49152. Dopo un certo periodo di tempo, il router interrompe l'inoltro dei pacchetti sulla porta esterna.
Tuttavia, i router generalmente non inoltrano le connessioni in entrata. Quando il router riceve una connessione a una porta, deve sapere a quale porta IP + locale deve essere inoltrata la connessione. Questo di solito può essere configurato manualmente per porte specifiche, ad es. "Se il router riceve una connessione sulla porta esterna 80, eseguire NAT su un server locale su 192.168.0.2:80".
Nel tuo caso, vorrai che il router trasmetta le connessioni dal tuo server a un particolare dispositivo. Tuttavia, non c'è modo di dire al router quale indirizzo IP locale + porta vuoi che venga inoltrata la tua connessione.
Il firewall dei dispositivi finali o dei router che si trovano tra te e il dispositivo finale potrebbero bloccare le connessioni in entrata a meno che quel tipo di connessione non sia stato autorizzato in modo esplicito.
Il mio esempio precedente utilizzava TCP, dal momento che le connessioni sono più facili da capire. Si potrebbero anche inviare pacchetti UDP. Mentre NAT per i pacchetti UDP è possibile, il NAT dovrebbe comunque essere configurato - esplicitamente che non aiuta qui, o implicitamente se il client dietro il NAT invia un pacchetto per primo, e continua a inviare pacchetti occasionali per mantenere il router libero quella voce nella tabella NAT. Ma a quel punto, abbiamo effettivamente una connessione e potrebbe anche usare TCP.
I messaggi push vengono generalmente implementati mantenendo aperta una connessione avviata dal client per un lungo periodo di tempo. Se la connessione scade o se il client cambia la rete, il client avvia un'altra connessione. Il grosso problema qui è che mantenere aperta la connessione è ad alta intensità energetica: abbiamo bisogno di una connessione di rete continua, abbiamo bisogno di inviare pacchetti keep-alive e abbiamo bisogno di risorse della CPU per controllare tutto ciò. Questo non è un grosso problema per i PC moderni, ma un enorme problema per i dispositivi mobili che passano la maggior parte del loro tempo in stand-by.
La soluzione consiste nell'utilizzare un servizio di notifica push centralizzato: sia Apple che Google gestiscono tali servizi per i rispettivi ecosistemi mobili. Ora, il dispositivo mobile non ha bisogno di tenere aperte 30 connessioni per ricevere notifiche da 30 servizi, ma solo una singola connessione. Per uno sviluppatore, questo semplifica anche la messaggistica push perché non devono preoccuparsi dei dettagli di basso livello di queste connessioni. Invece, le notifiche push vengono inviate a un server centrale del provider di notifiche push. Invece di un indirizzo IP, dovresti memorizzare alcuni token di autorizzazione più costanti nel tuo DB.
Leggi altre domande sui tag server-side networking mobile web-services