DOMANDA Creare interazione tra device e server

[fedi98]

Ciao a tutti, da un po vorrei capire come funziona un server che interagisca con device ed elabori i dati, provando a scriverne uno. Vorrei partire dalle basi, quindi provare a mandare pochi dati(ad esempio un numero) che il server elabori(ad esempio moltiplichi il numero per 2) e che poi me li restituisca al device.
Ho una discreta conoscenza del java ma non ho mai realizzato applicazioni che interagiscono con internet in questo modo... quindi da dove potrei incominciare? Conoscete qualche guida?

Come tecnologia penso di usare REST e quindi inviare e ricevere pacchetti dati in Json, e come inizio mi andrebbe bene anche un server in locale (magari proverò a creare un server online più tardi)...

Grazie in anticipo

 

[alex87alex]

Quindi vuoi farlo in java? Perchè su python ci sarebbe il framework flask (unito a jsonify) che farebbe tutto ciò che richiedi senza molto sforzo...

 

[fedi98]

non ho necessita di farlo in java (potrei incominciare un nuovo linguaggio), pero comunque ho trovato un framework che lo fa con 20 righe e anche piuttosto bene.
Il mio problema ora è mandare una risposta a device diversi e quindi mandare json anche ad un device che non richiede un web service e non fa una richiesta (in stile app di messaggistica), ma non so se si possa fare

 

[lukezona]

Fossi in te lo farei in NodeJS o Python

Ad ogni modo ogni device deve essere in ascolto secondo me, magari senza fare richiesta ma in ascolto deve essere

 

[fedi98]

Fossi in te lo farei in NodeJS o Python

Ad ogni modo ogni device deve essere in ascolto secondo me, magari senza fare richiesta ma in ascolto deve essere

Teoricamente si, anche secondo me. pero ci deve essere un modo per skippare questo problema. app come watsapp non possono rimanere sempre in ascolto di un messaggio (cioe cercare se il server ha dati per lui) perche sarebbe troppo dispendioso e l' app deve ricevere messaggi anche quando l' app non è in esecuzione

 

[1nd33d]

Secondo me invece il device non deve rimanere in ascolto per il semplice motivo che spesso non è praticabile. Perchè il tuo device possa essere in ascolto, deve innanzi tutto tenere aperta una porta in ingresso con relativi rischi di ddos all'app. Inoltre non solo la porta, ma anche l'indirizzo IP devono essere noti al server, ma l'indirizzo IP su un dispositivo mobile può cambiare diverse volte nell'arco di poco tempo, per esempio switchando da un wifi all'altro o tra wifi e 3G/4G.
Inoltre, se sei dietro a un router wifi, il router stesso deve impostare il NAT in modo che tu possa ricevere le connessioni in ingresso, magari puoi farlo sfruttando il protocollo upnp ma non è sempre una buona idea (e spesso è disabilitato).
La soluzione più semplice e probabilmente più praticata, è una richiesta a intervalli regolari da parte del device verso il server. Il server può quindi usare la connessione iniziata dal device (che è nota al NAT del router) per fornire al client i nuovi messaggi come risposta.
Se sai che ci sono pochi device e il server può gestirli tutti contemporaneamente, puoi far si che il device inizi la connessione e la tenga aperta, ma questo non penso sia contemplato nella "filosofia" REST.

 

[fedi98]

Secondo me invece il device non deve rimanere in ascolto per il semplice motivo che spesso non è praticabile. Perchè il tuo device possa essere in ascolto, deve innanzi tutto tenere aperta una porta in ingresso con relativi rischi di ddos all'app. Inoltre non solo la porta, ma anche l'indirizzo IP devono essere noti al server, ma l'indirizzo IP su un dispositivo mobile può cambiare diverse volte nell'arco di poco tempo, per esempio switchando da un wifi all'altro o tra wifi e 3G/4G.
Inoltre, se sei dietro a un router wifi, il router stesso deve impostare il NAT in modo che tu possa ricevere le connessioni in ingresso, magari puoi farlo sfruttando il protocollo upnp ma non è sempre una buona idea (e spesso è disabilitato).
La soluzione più semplice e probabilmente più praticata, è una richiesta a intervalli regolari da parte del device verso il server. Il server può quindi usare la connessione iniziata dal device (che è nota al NAT del router) per fornire al client i nuovi messaggi come risposta.
Se sai che ci sono pochi device e il server può gestirli tutti contemporaneamente, puoi far si che il device inizi la connessione e la tenga aperta, ma questo non penso sia contemplato nella "filosofia" REST.

le soluzioni sono:
- il device fa richieste continue al server (fino a che quindi il server non ha dati per l' utente o scatta il timeout), quindi alla fine di una richiesta ne esegue un altra (mi sembra pero poco performante come cosa, sia perche penso che si sprechino un po di risorse sia perche non potrei ricevere messaggi quando la mia app non è in esecuzione -esempio app di messaggistica, anche se non è il mio target)

-il device resta in ascolto.... se volessi provare a cavalcare questa soluzione conoscete guide o tutorial che trattino cio? (ci sarebbe l' alternativa GCM da come ho capito, ma è solo per app android)

 

[1nd33d]

- il device fa richieste continue al server (fino a che quindi il server non ha dati per l' utente o scatta il timeout), quindi alla fine di una richiesta ne esegue un altra (mi sembra pero poco performante come cosa, sia perche penso che si sprechino un po di risorse sia perche non potrei ricevere messaggi quando la mia app non è in esecuzione -esempio app di messaggistica, anche se non è il mio target)

Hai sicuramente un leggero overhead rispetto al mantenere una connessione aperta ma nemmeno troppo, ed è molto semplice da gestire con un approccio REST; questa modalità viene anche chiamata pull request.
Per quanto riguarda il potere o no ricevere messaggi quando l'app non è in foreground dipende esclusivamente dallo scheduler del sistema operativo su cui gira l'app. L'app può benissimo fare richieste anche quando è in background, fintanto che lo scheduler non decide di killare l'app per liberare risorse.

-il device resta in ascolto.... se volessi provare a cavalcare questa soluzione conoscete guide o tutorial che trattino cio? (ci sarebbe l' alternativa GCM da come ho capito, ma è solo per app android)

Bisogna mettere in chiaro un paio di concetti: un device è "in ascolto" quando una porta locale viene aperta in attesa di nuove connessioni. Come ti ho detto nel post precedente, questo approccio è quasi sempre non praticabile per vari motivi di networking.
Puoi tuttavia seguire una alternativa che è simile nell'atto pratico, ma concettualmente molto diversa... parliamo delle push request, che sono quelle spesso usate dalle app su dispositivi android e iOS. In questo caso si può usare un server cloud fornito da terzi (Android per esempio ha il suo "Google Cloud Messaging"): il tuo server si interfaccia verso questo servizio e poi è il servizio stesso a girare la notifica al device. Attenzione però... il server di notifica invia solo una notifica, e non tutti i dati; una volta ricevuta la notifica, dovrà essere il device a connettersi al tuo server e quindi di fatto farà una pull request. La differenza rispetto al primo approccio è che farà pull request solo quando sarà sicuro che c'è un nuovo messaggio. Dettagli ed esempi del servizio Android li trovi qui: https://developers.google.com/cloud-messaging/gcm
Nulla ti vieta di fare una cosa simile per conto tuo, però ricordati che non è il device a rimanere in ascolto, è sempre il server che attende la connessione del device, e poi la tiene aperta. La connessione richiede quindi di essere gestita lato client e in caso di problemi (cambio IP per esempio), ripristinata.

 

[fedi98]

Si in effetti fare continue richieste e tenere le stesse attive fino al timeout non è affatto un problema, e mi basta anche per cio che voglio fare, volevo solo capire (da un lato soprattutto didattico piu che pratico) il sistema che viene adottato dalle grandi app e quindi ad esempio da gcm

Hai qualche informazione da darmi sul protocollo XMPP (che da come ho capito è quello per gestire questo genere di cose) e su come avviene quindi il settaggio di una porta per l' ascolto e lato server come si sfrutta questa porta in ascolto?

Comunque grazie per i consigli

 

[1nd33d]

Si in effetti fare continue richieste e tenere le stesse attive fino al timeout non è affatto un problema, e mi basta anche per cio che voglio fare, volevo solo capire (da un lato soprattutto didattico piu che pratico) il sistema che viene adottato dalle grandi app e quindi ad esempio da gcm

Hai qualche informazione da darmi sul protocollo XMPP (che da come ho capito è quello per gestire questo genere di cose) e su come avviene quindi il settaggio di una porta per l' ascolto e lato server come si sfrutta questa porta in ascolto?

Comunque grazie per i consigli

Riguardo XMPP purtroppo non saprei come aiutarti, non ho mai programmato molto in questo settore (mi occupo di altro xD). So che esistono diverse implementazioni di XMPP, anche GCM ne integra una: https://cloud.google.com/appengine/docs/java/xmpp/ a questo link mi pare che sia fornita anche una spiegazione

 

[fedi98]

Riguardo XMPP purtroppo non saprei come aiutarti, non ho mai programmato molto in questo settore (mi occupo di altro xD). So che esistono diverse implementazioni di XMPP, anche GCM ne integra una: https://cloud.google.com/appengine/docs/java/xmpp/ a questo link mi pare che sia fornita anche una spiegazione

Ok grazie.. comnque da come ho capito gcm si basa proprio su xmpp.

Ora pero mi e sorto un dubbio:
- perche l ip del mio client cambia quando cambio il tipo di connessione o cambio wifi al quale sono collegato? Cioe, da quanto ne so c' e l ip del router, ovviamente, ma piu che altro l identificativo di un pc e il proprio ip, il quale non cambia quando cambia la connessione

 

[1nd33d]

Ora pero mi e sorto un dubbio:
- perche l ip del mio client cambia quando cambio il tipo di connessione o cambio wifi al quale sono collegato? Cioe, da quanto ne so c' e l ip del router, ovviamente, ma piu che altro l identificativo di un pc e il proprio ip, il quale non cambia quando cambia la connessione

Deduco che non hai molta esperienza con le reti di calcolatori...
Il router per definizione è un dispositivo che commuta i pacchetti su due reti (o sottoreti) distinte. L'indirizzo IP del tuo PC, per esempio 192.168.0.2/24 è un indirizzo di classe C che è raggiungibile solo dall'interno della sottorete 192.168.0.0/24, cioè quella che tipicamente si definisce LAN. Il tuo router dispone di due interfacce: quella interna (192.168.0.1/24) e quella esterna che corrisponde all'IP pubblico del tuo collegamento ADSL (o fibra che sia) assegnato dal tuo provider (Tim, Wind, Tiscali...). Per visitare la rete internet i pc e i dispositivi collegati al router mandano pacchetti attraverso il router stesso, i pacchetti giungono al server internet e l'eventuale risposta ti viene rispedita indietro (il router, grazie al NAT, sa a chi è destinato il pacchetto di risposta di una connessione TCP già stabilita)
Ma perchè un host esterno sia in grado di iniziare una connessione con te che sei nella sottorete interna, deve conoscere l'IP pubblico, che è diverso per ogni connessione a internet (diversi modem/router hanno diversi IP pubblici). Inoltre le connessioni in ingresso vanno gestite dal NAT in modo opportuno, ma spesso non è possibile, soprattutto se ci si trova in reti wifi pubbliche. Per ricevere connessioni esterne sul proprio pc o smartphone locale è necessario cofigurare il router (manualmente o con upnp) ma questa è una cosa che tipicamente riesci a fare solo sul tuo router privato in quanto puoi accedere alla sua interfaccia di configurazione.
ps: non è nemmeno detto che il tuo IP locale rimanga uguale cambiando wifi... un router potrebbe darti uno qualsiasi degli indirizzi della sottorete, tipicamente ti assegna il primo libero in ordine numerico, a patto che non sia staticamente assegnato a qualcun'altro mediante DHCP.

 

[fedi98]

Grazie, effettivamente non so proprio nulla di queste cose, magari adesso provo a trovare qualcosa che spieghi nel dettaglio questo tipo di approccio (se c' è)