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!