Framework over-HTTP basato su eventi

1

Sto progettando un server di gioco distribuito che supporterà sia i browser che i client UE4 (si spera sia su HTTP per semplicità) e continuo a sbattere la testa contro REST e facendo backflip semantici per ottenere la logica che voglio mettere in atto. / p>

Per alcune cose, REST ha perfettamente senso: ottieni un elenco di giochi, crea un nuovo gioco, ottieni metadati su un gioco specifico, ecc.

Ma per altre cose, il cliente vuole solo generare un "evento" - "Mi sono unito al gioco X", "Ho eseguito l'azione B nel gioco X", o ricevere la notifica che si è verificato un "evento" - "giocatore A si è unito al gioco in cui ti trovi "," il giocatore A ha eseguito l'azione X nel gioco in cui ti trovi ", ecc. All'interno del mondo REST, puoi fare questo lavoro (credimi, ci ho provato) ma implica sempre alcune peculiarità che distorcono il modello del dominio per adattarlo alla semantica di REST o distorcono REST per adattarlo alla semantica del modello di dominio.

Esiste qualche framework o paradigma per la creazione di un tale modello di pubblicazione / sub che supporti l'interazione dal browser? La mia idea attuale è quella di collegare un websocket - > Proxy MQ e utilizzare un server MQ come bus eventi, ma il problema è che sto trovando difficile trovare tali proxy e non sono sicuro di quali siano effettivamente le implicazioni di sicurezza di questa architettura (in particolare sono preoccupato per protezione contro gli attacchi DDoS, in cui più utenti distribuiti possono inviare spam al MQ e saturarlo, causando l'errore dell'intero sistema).

Anche i Websocket non sono preferibili in quanto, mentre UE4 supporta HTTP out of the box, non sono a conoscenza del fatto che abbia un supporto websocket quindi dovrei trovare e collegare una libreria websocket C ++ al client di gioco e suona già dolorosa.

    
posta Chris Browne 30.03.2017 - 08:43
fonte

2 risposte

2

Se stai cercando la semplicità, probabilmente finirai per utilizzare WebSockets. In termini di semplicità, ha due importanti vantaggi:

  • Un sacco di librerie per molti linguaggi di programmazione facilitano l'impostazione.

  • Poiché utilizza la porta 443 (o 80) ed è abbastanza maturo per essere supportato da un'ampia gamma di prodotti software, avrai meno problemi con firewall, proxy, proxy inversi, ecc.

Con l'aiuto di un servizio messaggi in coda, puoi raggiungere una piattaforma altamente scalabile dove, per supportare un numero crescente di richieste e utenti, dovrai semplicemente aggiungere nodi a MQS, o server che trasmetteranno eventi MQS upstream al client tramite WebSockets. I sistemi MQS più diffusi includono un supporto per WebSockets, ma i problemi di scalabilità potrebbero richiedere una soluzione manuale.

Gli attacchi DDoS possono essere evitati in modo simile a come faresti per un semplice servizio REST. Poiché i WebSocket sono un protocollo di comunicazione bidirezionale, è tecnicamente possibile utilizzarlo per inviare messaggi dal client al server, non ricevendo a malapena messaggi dal server. Tuttavia, potresti anche voler utilizzare WebSockets esclusivamente per inviare eventi dal server al client e mantenere le richieste REST per qualsiasi altra cosa. In entrambi i casi, la tua applicazione dovrebbe posizionarsi come intermediario tra il client e il MQS, non solo per proteggerti da DDoS, ma semplicemente per disinfettare gli input e fornire un livello di astrazione . In confronto, il fatto che un sito Web utilizzi un database SQL non significa che i client siano in grado di eseguire direttamente query SQL; con MQS, è esattamente la stessa cosa.

Se sei a un livello in cui WebSockets diventa un collo di bottiglia (anche se non ho mai sviluppato alcun gioco, potrei immaginare che alcuni giochi possano colmare il collo di bottiglia), e solo allora hai bisogno di cercare una sostituzione basata su UDP .

    
risposta data 02.05.2017 - 21:10
fonte
0

Potresti provare SignalR 2 .

Può essere utilizzato per legare insieme molti client e tutti (o filtrati) possono ricevere messaggi da qualsiasi post che viene inviato al server (o dal server che avvia il messaggio direttamente).

Ci sono molti esempi online che dimostrano le applicazioni di chat. Ma usando questi, invece di aggiornare una textarea con il messaggio di qualcuno, puoi inviare tutto ciò che è necessario per aggiornare qualsiasi client.

In pratica, puoi fare in modo che un client invii un post, che il server possa fare ciò di cui ha bisogno e quindi inviare un messaggio ai client richiesti / in ascolto.

I client possono ricevere il messaggio, quindi eseguire qualsiasi azione che desiderano.

Di default SignalR 2 utilizzerà i seguenti metodi di connessione (a seconda del supporto):

  • Websocket (full duplex su TCP)
  • Eventi inviati dal server (basati su HTML5 EventSource)
  • Frame per sempre (iframe nascosto)
  • Ajax long polling (connessione live live)
risposta data 31.03.2017 - 01:13
fonte

Leggi altre domande sui tag