Browser utente, WebSockets, server C # / MVC, gioco

0

Spostamento di un gioco desktop Windows in un server Web basato su uno. L'utente utilizzerà un browser Web moderno e comunicherà con il server tramite WebSockets (SignalR). Il server funziona .Net4.5 / MVC - cioè senza stato. Il gioco stesso consente a uno o più utenti di connettersi e viene eseguito costantemente in un processo separato dall'host IIS (presumibilmente migliore in ogni caso) e potrebbe eseguire contemporaneamente diversi giochi, ciascuno con uno o più utenti. Trattare con quel sistema di avvio / arresto / gestione di altri ex è un'altra storia a questa domanda.

Pur comprendendo la maggior parte delle parti componenti del sistema e ho eseguito varie parti in isolamento perfettamente bene, il bit che non riesco a capire è come un server Web con connessioni WebSocket / SignalR dai client mappa e comunica con processi esterni, anche se sulla stessa macchina.

Voglio mantenere il livello web separato dalla logica di gioco, dal momento che lo strato web non fa altro. Potrei prevedere che il gioco exe comunichi con il server web con messaggi socket TCP come "invia questi dati al client X", tutto il server web comunica in modo simile con il gioco exe con "ecco un messaggio dal client Y". WCF sembra una possibilità. Non sono troppo preoccupato per il ritardo (un paio di secondi dopo che l'utente sta facendo qualcosa per ottenere una risposta è ok), anche se sono preoccupato per ulteriori livelli di complessità con ritardi ed elaborazione delle comunicazioni tra processi.

Sto andando in questo modo nel modo giusto - come in un gioco in esecuzione autonomo che funziona insieme al processo del server Web IIS? C'è un modo migliore?

FWIW Ho cercato per tutti i tipi di tutorial ed esempi, ma tutti sembrano essere a turni, cioè il client provoca il server a reagire e inviare aggiornamenti ad altri client - ad esempio chat, o trascinando un rettangolo attorno al proprio browser. Nel mio caso il gioco sta facendo sempre e sta inviando aggiornamenti ai client non provocati.

Grazie. Spero di averlo spiegato abbastanza bene!

    
posta GeoffM 15.03.2016 - 20:37
fonte

1 risposta

0

La risposta mi stava fissando in faccia. L'app di gioco può essere un client SignalR al server SignalR del server Web. Il server Web agisce quindi da server non solo per i client dell'utente, ma anche per il gioco stesso. L'app di gioco è un'applicazione Windows standard di bog e, utilizzando le chiamate del server SignalR >, non importa che il server sia stateless perché a quel punto la maggior parte delle informazioni viene inviata a client selezionati con pochissimo elaborazione da parte del server web (si pensi ad una sorta di centro di smistamento della posta).

WCF era davvero una possibilità e l'ho provato, ma ciò ha aggiunto livelli di complessità come i diritti amministrativi. Tubi con nome ok, ma sono necessari più legwork. Né insormontabile ma più lavoro.

    
risposta data 18.03.2016 - 04:22
fonte

Leggi altre domande sui tag