webserver - Network structure for online programming game with webSockets -

problem

i'm making game provide piece of code represent agent program of intelligent agent (think robocode , like), browser-based. being ai/ml guy part, knowledge of web development was/is pretty lacking, i'm having bit of trouble implementing whole architecture. basically, after upload of text (code), naturally part of client-side, backend responsible running core logics , returning json data parsed , used client drawing part. there isn't need multiplayer support right now.

if model after robocode's execution loop, need separate process each battle assigns different agents (user-made or not) different threads , gives them execution time each loop, generating new information given agents data drawing whole scene. i've tried think of way structure multiple clients, servers/web servers/processes [...], , came multiple possible solutions.

favored solution (as of right now)

clients communicate node.js server works kinda interface (think websocketd) unique processes running on same (server) machine, keeping track of client , process via id , forwarding data (via websockets) accordingly. example scenario be:

1. client c1 requests new battle server s , sends code (not single step, know);
2. s handles code (e.g. compiling), executes new battle , starts connection it's process p1 (named pipes/fifo?);
3. p1 generates json, sends s;
4. s sees p1 "connected" c1, sends data c1 (steps 3 , 4 repeated long battle active);
5. client c2 requests new battle;
6. previous steps repeated; c2 assigned new process p2;
7. client c3 requests "watching" battle under p1 (using unique url or token);
8. s finds p1's id, compares received 1 , binds p1 c3;

this way, server forwards received data forked processes clients connected each specific battle.

questions

regarding approach:

• is simple enough? there easier or more elegant ways of doing it? scalability problem?
• is secure enough (the whole compiling , running code — c++ — on server)?
• is fast enough (this 1 worries me now)? seems bit counter intuitive have single server dealing entire traffic, far know, if i'd assign these processes separate web server, need different ports each of them, seems worse.

since theoretical , opinion based question... feel free throwing ball in different directions. i'll edit answer think things on or read comments.

1. a process per battle?

   sounds expensive. also, there issue of messages going , forth between processes... might able send messages between machines , have total separation of concerns.

   instead of forking battles, have them running on own, allowing them crash , reboot , whatever feel without ever causing of other battles or our server harm.

2. javascript? why 1 language?

   i consider leveraging object oriented approach or language - @ least battles, if not server well.

   if separating code, can use different languages. otherwise go ruby, it's easy me, maybe i'm mistaken , delving deeper javascript's prototypes do.

3. oh... foreign code - sanitization in order.

   how safe foreign code? should in localized sped language promises safety of using existing language interpreter, might allow code mess around things shouldn't...

   i write own "pseudo language" designed battles... or (if local project me , mine) use ruby 1 of it's sanitizing gems.

4. battles , web-services might not scale @ same speed.

   it seems me handling messages - both client->server->battle , battle->server->client - easy work. however, handling battle seems more resource intensive.

   i'm convincing myself separation of concerns unavoidable.

   having server backend , different battle backend allow scale battle handlers more rapidly , without wasting resources on scaling web-server before there's need.

5. network disconnections.

   assuming allow players go offline while agents "fight" in field ... happens when need send our user "mitchel", reconnected server x, message battle left raging on server y?

   separating concerns mean right start have communication system ready scale, allowing our users connect different endpoints , still messages.

summing these up, consider workflow:

• http workflow:

  • client -> web server : requesting agent identifier , optional battle data (battle data creating agent, omitting battle data used limiting request existing agent if exists).

    this step might automated based on client authentication / credentials (i.e. session data / cookie identifier or login process).

    • if battle data exists in request (request make):

      web server -> battle instance : creating agent if doesn't exist.

    • if battle data missing request:

      web server -> battle database, check if agent exists.

  • web server -> client : response agent (exists / created vs none)

    • if agent exists or created, initiate websocket connection after setting credentials connection (session data, unique cookie identifier or single-use unique token appended websocket request query).

    • if agent does't exist, forward client web form fill in data such agent code, battle type etc'.

• websocket "workflows" (non linear):

  • agent has data: agent message -> (battle communication manager) -> web server -> client

    it's possible put redis or similar db in there, allow messages stack while user offline , allow multiple battle instances , multiple web server instances.

  • client updates agent: client message -> (battle communication manager) -> web server -> agent