Non vedo praticamente nessuna applicazione web in cui il server invia messaggi al client. Sebbene i messaggi multiplayer da server a client siano ampiamente utilizzati nei giochi multiplayer, perché questo modello è così poco utilizzato nelle app Web?
È sbagliato? Distrugge il modello client-server?
Alcune architetture e protocolli sono stati progettati per tipo di comunicazione richiesta-risposta . In HTTP, il client chiede al server di GET, POST, DELETE, HEAD ecc. Qualcosa, e il server risponde (o non risponde). In POP3, il ruolo del server è limitato a rispondere alle richieste, nient'altro.
Alcuni altri sono progettati in modo che il client e il server comunichino insieme , il che consente scenari difficilmente possibili in un modello di richiesta-risposta. IMAP, ad esempio, ha un vantaggio rispetto a POP3 per consentire la consegna immediata dei nuovi messaggi al client. Per ottenere lo stesso comportamento quasi immediato con POP3, l'unica cosa che puoi fare è interrogare il server per nuove e-mail una volta al secondo, il che ovviamente aumenta i problemi di utilizzo delle prestazioni e della larghezza di banda.
In generale, spingere le informazioni dal server al client può essere totalmente accettabile in alcuni casi. Hai citato te stesso un esempio di un tipo di prodotti in cui questa è una pratica comune: giochi multiplayer.
In un'applicazione web, è inusuale vedere le informazioni che devono essere inviate dal server al client per diversi motivi:
In molti casi, non hai bisogno di tale funzionalità in un'applicazione web . Ad esempio, perché MSDN o Google Immagini inizieranno a inviare qualcosa al mio browser? O perché TheDailyWTF cambierà il suo contenuto al volo mentre lo stai consultando?
Per un po 'di tempo, era impossibile farlo senza utilizzare applet Java o componenti simili non HTML , rendendo molto complicato l'implementazione in un sito web. Se stavi creando un'applicazione di chat, l'utilizzo di un'applet Java non era probabilmente troppo difficile, ma per qualsiasi altra app web era eccessivo. Ad esempio, immagino a malapena che eBay crei un'applicazione Silverlight che stabilisca una comunicazione bidirezionale con il server per aggiornare le offerte in tempo reale.
Alcune persone sono venute con soluzioni alternative, ma avevano i loro lati negativi (prestazioni e utilizzo della larghezza di banda). Ad esempio, non è raro vedere alcune bacheche di annunci che fanno richieste regolari AJAX (ogni dieci secondi per esempio) per vedere se qualcosa è cambiato.
Oggi le cose iniziano a cambiare con HTML 5 e WebSockets. Stack Exchange è un eccellente esempio di un uso corretto di questi: in realtà, quando vedi le notifiche su nuovi commenti o risposte o quando vedere i voti alti e bassi in tempo reale, è fatto con WebSockets.
Con WebSockets, puoi immaginare altri usi validi della comunicazione bidirezionale nei browser:
Informazioni in tempo reale. Esempio: per le grandi città , Google Maps ha funzionalità Traffico. Che ne pensi di aggiornare queste informazioni in tempo reale o di notificare immediatamente i conducenti quando un incidente stradale causa un ingorgo?
Interazioni sociali. Esempio: quando si fa un commento su un blog, che ne è della capacità di vedere i commenti di altre persone immediatamente dopo che sono stati pubblicati? Un altro esempio: cosa succede se, in un sistema di tracciamento dei bug, riesco a vedere immediatamente i rapporti sui bug appena creati?
Casi in cui è richiesta una risposta immediata. Esempio: un pannello di monitoraggio usato da un amministratore di sistema può essere scritto in HTML e con WebSockets, può informare immediatamente il sysadmin se un server è inattivo.
ecc.
Non penso che sia sbagliato. Per esempio. La società che offro offre un sistema di controllo delle versioni client-server, che invia un messaggio di avviso in anticipo quando la manutenzione programmata è scaduta.
Leggi altre domande sui tag networking push