In sostanza, si dispone di 3 opzioni, al momento della stesura di questo:
WebSockets
WebSockets è un protocollo di messaggistica leggero che utilizza il protocollo TCP, piuttosto che un'implementazione di JavaScript socket TCP, come si' ho notato Tuttavia, al di là dell'handshake iniziale, non ci sono intestazioni HTTP passate avanti e indietro oltre quel punto. Una volta stabilita la connessione, i dati passano liberamente, con un sovraccarico minimo.
lungo polling
lungo polling, in estrema sintesi, prevede il polling client al server per le nuove informazioni periodicamente con richieste HTTP. Questo è estremamente costoso in termini di CPU e larghezza di banda, poiché si invia una pesante nuova intestazione HTTP ogni volta. Questa è essenzialmente la tua unica opzione quando si tratta di browser più vecchi e le librerie come Socket.io utilizzano il polling lungo come fallback in questi casi.
WebRTC
Oltre a quanto già detto, WebRTC consente una comunicazione via UDP. UDP è stato a lungo utilizzato nei giochi multiplayer in ambienti non basati sul Web a causa del suo basso overhead (rispetto al TCP), bassa latenza e natura non bloccante.
TCP "garantisce" che ciascun pacchetto arriverà (salvo per errore di rete catastrofico) e che arriveranno sempre nell'ordine in cui sono stati inviati. Questo è ottimo per informazioni importanti come la registrazione di punteggi, hit, chat e così via.
UDP, d'altra parte, non ha tali garanzie. I pacchetti possono arrivare in qualsiasi ordine, o per niente. Questo è davvero utile quando si tratta di dati meno critici che vengono inviati ad alta frequenza, e deve arrivare il più rapidamente possibile, come le posizioni dei giocatori o gli input. Il motivo è che i flussi TCP sono bloccati se un singolo pacchetto viene ritardato durante il trasporto, con conseguenti grandi lacune negli aggiornamenti dello stato del gioco. Con UDP, puoi semplicemente ignorare i pacchetti che arrivano in ritardo (o non del tutto) e continuare con quello successivo che ricevi, creando un'esperienza più fluida per il giocatore.
Al momento della stesura di questo documento, i WebSocket sono probabilmente la soluzione migliore, anche se l'adozione di WebRTC si sta espandendo rapidamente, e potrebbe essere effettivamente preferibile al termine del gioco, quindi è una cosa da considerare.
In realtà ogni trasmissione contiene solo due byte di sovraccarico. L'handshaking http si verifica solo quando si apre un nuovo websocket e si può mantenere aperto il web socket fintanto che il browser rimane su quella pagina. –
Sì, lo sono. l'handshake HTTP viene eseguito una volta per aprire il socket. Quindi il sovraccarico è grande se si chiude il socket dopo un messaggio e insignificante se si mantiene aperto il socket per sempre. – Raynos
Perché il processo di handshaking è così complicato? Da quello che ricordo, si deve leggere in una manciata di stringhe, l'ultima delle quali è un insieme [casuale?] Di caratteri che devono quindi essere codificati in base64 in qualche modo e inviati al client. Ho provato a scrivere da solo il codice di handshaking sul lato server, ma non ha funzionato (il processo di handshaking non è mai stato completato, quindi non sono mai stato in grado di inviare e recuperare i miei pacchetti). Ho raggiunto lo stesso risultato esatto quando utilizzavo un pacchetto Java che qualcun altro aveva scritto per fare la stessa cosa. – Josh1billion