Progettazione di un protocollo di rete per dispositivi di dati in tempo reale/mobili

Question

sono di fronte a un dilemma:

progettazione di un nuovo protocollo di rete che sarebbe utilizzato tra un server (software Java) e client desktop e mobili. I client mobili includono J2ME, Android e forse in futuro anche iPhone.

Il flusso di dati è un flusso in tempo reale e costante con parti anche più rari. I client mostrano forme d'onda di questi dati e anche dati che non devono essere aggiornati all'istante. Anche i client dovrebbero essere autenticati.

Mi piacerebbe evitare di creare un'implementazione del protocollo TCP totalmente personalizzata da zero, se possibile.

In questi giorni di solito le persone consigliano di fare tutto in stile REST che mi piace anche molto. In questo caso sono un po 'titubante: come implementeresti un flusso costante di dati su REST? Una risposta HTTP Chunked?

Sto anche considerando i protocolli non in chiaro (quelli correnti che sto sostituendo sono i protocolli binari). Questi protocolli attuali hanno i loro problemi piuttosto seri, quindi dovrebbero essere davvero sostituiti.

I buffer del protocollo Google si presentano come candidati piuttosto validi per la gestione dei dettagli di basso livello, ma non sono sicuro che possa essere utilizzato da Android. E sono abbastanza sicuro che anche l'implementazione dell'iPhone avrebbe dei problemi.

C'è anche BEEP, ma penso che sia praticamente morto e mi chiedo se sia mai stato ampiamente utilizzato.

Qualche idea?

Answer 1

Si potrebbe voler guardare RTP (Real-time Transport Protocol), che potrebbe non essere direttamente utile (e/o potrebbe essere eccessivo), ma il suo design vi darà alcune buone idee su cui lavorare. E potresti essere in grado di usarlo.

Answer 2

penso che prima di entrare in protocollo di progettazione si dovrebbe prendere cura dei seguenti problemi davvero con attenzione:

• Quasi tutti i protocolli ad eccezione di HTTP sono filtrati da firewall in questi giorni. Anche molti tipi di contenuto e porte (tranne 80) possono essere filtrati dai fornitori di servizi, specialmente nei servizi dati mobili. Pertanto, assicurarsi di non avere problemi con il firewall nella rete di destinazione prima di scegliere di utilizzare o progettare un protocollo.
• Dimensioni e velocità contano. Provare a utilizzare protocolli efficienti sia in termini di dimensioni dei messaggi di trasporto che di velocità di codifica/decodifica (serializza/deserializza). Google Protocol Buffers fornisce una soluzione affidabile a questo problema.
• Le connessioni si disconnettono sempre. Non si può mai fare affidamento su una connessione per rimanere aperta a lungo a causa dei timeout NAT (15 minuti per impostazione predefinita), timeout del protocollo (30 minuti per TCP) e molti problemi di rete esistenti. Quindi, non preferire un protocollo rispetto all'altro perché mantiene aperta la connessione (potrebbe tentare di farlo ma non ci riesce mai). L'invio di heartbeat è un buon tentativo per il problema di timeout ma i disconnect della rete rimangono comunque inevitabili.
• Il throughput è importante. Per throughput, intendo il numero di messaggi elaborati in un periodo di tempo (ad esempio 1 secondo). L'utilizzo di protocolli asincroni che disconnettono un client dopo aver ricevuto il suo messaggio, aiuta davvero ad aumentare il throughput.Sebbene non si basino sulla connessione al client dal server per spingere il risultato perché molti client sono dietro NAT e firewall che evitano la connessione diretta dall'esterno. Cerca di mantenere la connessione aperta o di eseguire il polling del server per il risultato. Evitare lo stato in una conversazione è anche l'altro metodo che aiuta a ridimensionare il throughput dell'applicazione man mano che il numero di clienti cresce.
• Non c'è tempo reale nelle WAN esistenti. Non fidatevi di quelli che dicono di aver implementato un protocollo in tempo reale basato su protocolli esistenti della Wide Area Network. Non puoi mai implementare un protocollo in tempo reale su quelli non in tempo reale. Puoi semplicemente fare del tuo meglio e pregare affinché la rete vada veloce. Ciò significa: non fermarti, fai del tuo meglio.
• IO non bloccante. NIO (Non-blocking IO) è la tendenza ora, efficacemente utilizzata nella programmazione di rete. Consente un numero elevato di connessioni con un utilizzo di memoria inferiore e un numero limitato di thread. Java 5 ha il supporto nativo per NIO che è molto primitivo. Molti framework, come Apache MINA e Netty, sono stati implementati sulla base di NIO Java per rendere la programmazione non bloccante più facile e più robusta. Li raccomando vivamente.

Answer 3

Si potrebbe guardare Kryo e/o KryoNet, che sono basati su NIO e Java e funzionano sul desktop e Android. Dovresti scrivere sul lato iPhone, il che sarebbe piuttosto complicato. Kryo batte i buffer di protocollo di Google in dimensioni serializzate() e facilità d'uso (non è necessario scrivere lo schema del tipo prototipo, con Kryo le definizioni della classe Java sono lo schema).

Per quanto riguarda NIO, si potrebbe verificare NPTL. Il vecchio diventa di nuovo nuovo.

Answer 4

Non è una soluzione elegante, ma è possibile farlo su HTTP dritto, non impostando il campo Content-Length sulla risposta http, e mai la chiusura del flusso di output. Continua a inviare dati.

È inoltre possibile impostare una lunghezza del contenuto molto grande e inviare i dati indietro dal server in tempo reale finché il server non ha inviato tale importo, quindi il client può scegliere di effettuare una nuova richiesta o meno.

Purtroppo non ho trovato nessun link utili per queste idee, ma ho fiducia che si ottiene le idee.

Il vero lato positivo di queste idee è che sono su HTTP, che ottiene dal problema di firewall, e si può implementare la vostra applicazione come una webapp con un servlet.

Solo i miei 2 cents;)