User browser, WebSockets, server C#/MVC, game

Question

Moving a windows desktop game to a web server based one. User will use a modern web browser and communicate with the server via WebSockets (SignalR). Server runs .Net4.5/MVC - ie stateless. Game itself allows one to many users to connect and constantly runs in a separate process from the IIS host (supposedly better anyway), and could be running different games at the same time, each with one to many users. Dealing with that system of starting/stopping/handling other exes is another story to this question.

While I understand most of the component parts of the system and have run various parts in isolation perfectly fine, the bit I can't get my head around is how a web server with WebSocket/SignalR connections from clients maps and communicates with external processes, albeit on the same machine.

I want to keep the web layer separate from the game logic as the web layer does other stuff unrelated. I could foresee the game exe communicating with the web server with TCP socket messages like "send this data to client X", whole the web server similarly communicates with the game exe with "here's a message from client Y". WCF seems a possibility. I'm not too worried about lag (a couple of seconds from user doing something to getting a response back is okay), though I am concerned about additional layers of complexity with inter-process communication delays and processing.

Am I going about this the right way - as in standalone game exe(s) running alongside the IIS web server process? Is there a better way?

FWIW I have searched for all kinds of tutorials and examples but all seem to be turn-based, ie client provokes the server into reacting and sending updates to other clients - eg chat, or dragging a rectangle around one's browser. In my case the game is doing stuff all the time and is sending updates to clients unprovoked.

Thanks. I hope I explained that well enough!

Answer 1

The answer was staring me in the face. The game app can be a SignalR client to the web server's SignalR server. The web server therefore acts as the server not just to user clients but also to the game itself. The game app is a bog standard Windows application and, by using the SignalR client->server calls, it doesn't matter that the server is stateless because at that point the bulk of the information is going out to selected clients with very little processing by the web server (think of it as a kind of mail sorting centre).

WCF was indeed a possibility and I did try that, but that added layers of complexity like administrative rights. Named pipes okay but more legwork required. Neither insurmountable but more work.