2013-07-31 10 views
9

Ho una quantità X di sensori di attività connessi a un server che inserisce dati in un database ogni volta che viene attivato un sensore. Quello che sto cercando di fare è creare un'interfaccia web con una stampa blu della funzione (svg) e ogni volta che viene attivato un sensore, oltre al db insert, voglio che mostri una sorta di avviso nella mia stampa blu. Per questo ho bisogno di mantenere una connessione aperta al server, penso.Consigli su quale tecnologia utilizzare per le notifiche in tempo reale

Stavo pensando di utilizzare i socket Web, ma potrebbe essere eccessivo visto che ho solo bisogno di recuperare i dati dal server. Ma eseguire una chiamata Ajax ogni secondo non sembra molto efficiente. Ci sono altre alternative?

Grazie

+1

Si dispone di un polling AJAX lungo, che si rivelerà quasi efficiente quanto le web-socket nel tuo caso; supponendo che i sensori non siano attivati ​​spesso. I WebSocket non sono "eccessivi", direi, e le richieste AJAX non sarebbero troppo inefficienti se si considera un piccolo numero di utenti. – Matt

+1

forse http://signalr.net/ – Raidri

+1

suggerisco anche signalr.net .. giusto ora in beta ma è troppo bello ... –

risposta

4

Alcune scelte possibili sono:

  • WebSocket
  • Adobe® Flash® Socket
  • AJAX polling lungo
  • AJAX multipart in streaming
  • sempre Iframe
  • Polling JSONP

Il trasporto effettivo che si utilizza dipenderà dai requisiti del supporto del browser e dalla tecnologia utilizzata sul server per gestire tali richieste. La scelta del trasporto può dipendere anche dalla topologia della rete - quali tipi di bilanciamento del carico è necessario integrare con, proxy, ecc.

Ci sono molte librerie disponibili su entrambi i lati client e server, molte delle quali supportano più di una di questi trasporti.

Per esempio (non un elenco esaustivo):

  • socket.io per nodejs
    • websocket
    • Adobe® Flash® Socket
    • AJAX polling lungo
    • AJAX multipart in streaming
    • Per sempre Iframe
    • Polling JSONP
  • SignalR per un asp /.backend net
    • WebSockets
    • Eventi Server-Sent
    • ForeverFrame
    • polling lungo
  • Atmosphere per un backend Java
    • WebSockets
    • Eventi Server Side (SSE)
    • Polling lungo
    • sempre inquadrare
    • JSONP

IMO - WebSockets è NON eccessivo per questo tipo di problema e si presterebbe bene a questo tipo di applicazione.

1

Ho avuto un problema simile e ho fatto molte ricerche su questo. A quanto mi risulta, ci sono tre opzioni principali:

  1. brevi elettorali: Che endpoint che i ping client JavaScript ogni secondo. Questa è l'opzione peggiore, poiché i ping aggiungono una latenza fino a un secondo alla comunicazione e, a seconda di come si implementa, l'endpoint potrebbe interrogare il database ogni secondo, aggiungendo un sovraccarico non necessario.
  2. Polling lungo: avere un endpoint che il client javascript esegue il ping che mantiene la connessione finché a) l'evento si verifica o b) la connessione scade. Se l'endpoint restituisce una risposta, il client ottiene le informazioni sull'evento. Se l'endpoint non restituisce una risposta, non si è verificato alcun evento e il client invia una nuova richiesta. Questa è una buona opzione perché gli eventi possono immediatamente attivare la risposta al client, assumendo che si disponga di un livello di comunicazione interprocesso asincrono (come 0MQ) per inviare il messaggio senza alcun tipo di polling.
  3. Websocket: consente al client javascript di collegarsi a un server Websocket, che invierà un messaggio al client immediatamente dopo l'attivazione dell'evento.

Penso che un websocket è la scelta migliore, perché ospita comunicazione immediata della manifestazione senza tutte le spese generali di richiesta/risposta. E, soprattutto, questo è esattamente ciò che i websockets sono progettati per fare! Come tale, probabilmente dovrai scrivere la minor quantità di codice personalizzato con questa soluzione.

1

WebSocket non è certo eccessivo. Anzi. Con le websocket, hai un canale di comunicazione bidirezionale; ciò significa che il server può iniziare la comunicazione ogni volta che sembra opportuno (ad esempio quando i dati del sensore cambiano).

In un progetto precedente, ho utilizzato node.js insieme a socket.io, per monitorare più di 50 sensori. I dati sono stati aggiornati in tempo reale in un browser. I dati sono stati visualizzati utilizzando smoothie.js. Ogni volta che un valore del sensore è stato aggiornato, è stato comunicato al browser. Alcuni sensori aggiornati solo una volta al minuto, gli altri una volta al secondo, ... Polling sarebbe stato eccessivo, perché sarebbe recuperare tutti i dati per tutti i sensori, anche da quelli che non sono stati ancora aggiornato.

3

Senza discutere specificamente quadri o sapere che cosa è in esecuzione nel backend del server (s), abbiamo alcune opzioni da considerare per il frontend:

WebSockets

WebSockets sono progettati per bidirezionale comunicazione, anche se è un po 'scioccante il numero di utenti che navigano sul Web in un browser che non supporta le web socket. Raccomando sempre un fallback per questo, come gli altri metodi elencati di seguito.

SSE

SSE è una specifica HTML5 ed è ancora traballante al meglio. Prova a scorrere su una pagina mentre un evento SSE si attiva ... Potrebbe essere un po 'più facile sul backend, metterlo a volte sul lato client poiché viene eseguito all'interno dello stesso thread in cui viene eseguito il DOM.

Polling lungo

Mantiene aperta la connessione. E non scala bene con PHP, ma si esibisce a meraviglia con Python + ritorto sul backend, o Node.JS

Good Old Ajax

Tenere le richieste piccole, e si dispone ancora di una soluzione scalabile. Sì, una richiesta GET completa è la più costosa, ma è supportata in quasi tutti i browser lanciati negli ultimi dieci anni. Vale anche la pena notare che le richieste GET sono facili da scalare orizzontalmente con più hardware.

In un mondo perfetto:

Si potrebbe rompere l'applicazione in pochi componenti, che operano dietro un proxy inverso, come Nginx. Quindi usa Node.Js + Socket.IO per gestire gli aspetti realtime della tua app.

Un'altra opzione potrebbe essere l'utilizzo di richieste Ajax di piccole dimensioni e il supporto di Websocket per i browser che lo supportano. Questo è un consiglio specifico per PHP nel backend.

1

Ci sono due grandi servizi commerciali che potrebbero funzionare per voi.

  • Firebase - un database gerarchico javascript e la piattaforma in tempo reale messaggistica/sincronizzazione, usa WebSockets e ha altre ricadute

  • PubNub - un messaggio in tempo reale di passaggio e di sistema coda, usa WebSockets

+0

PubNub in realtà non utilizza solo socket web.PubNub è indipendente dal protocollo e utilizza il miglior trasporto a seconda della situazione. * Divulgazione lavoro per PubNub * – sharpper

Problemi correlati