A 2-process server

[Vincent Le Goff]

Hi everyone,


I'm trying something and would like some feedback on what strategy I
should choose.  I'm designing a very small game which includes a web
server (though it will include other things).  The game itself is in a
process that's bound to restart pretty often to fix bugs, possibly add
content and so on.  But of course, it would be ideal if users weren't
disconnected while playing.


So I have the following design in mind: the game and the portal will be
on two different processes: the game hosts all the game mechanism, has
access to the database and the virtual world.  The portal (lacking a
better term) receives incoming connections and maintains the ones it
should.  The portal is the process users will access to if they want to
connect using non-web clients (TCP connections): they reach the portal,
the portal contacts the game process to let it know there's a new
connection and the game sends whatever information it wants to display. 
The portal plays in the middle.  If the game has to restart, the portal
still exists.  If a client sends some information to the portal and the
game is not ready, the portal will delay the data and send it to the
game once it's up and running again.


But where should the web server stands in this structure?  My first idea
was to add a kind of "proxy" to the portal and have the web server on
the same process as the game, which would allow the web server to access
the same database without conflict for instance.  But building an
efficient proxy might not be a good option, particularly since web
sockets will have to be supported. How to maintain web socket
connections doesn't seem that obvious at first glance.


I could let the web server be on the portal.  It would receive HTTP
requests directly and answer to them, possibly reaching out to the game
when needing to access the database or other data in memory.  And this
wouldn't pose any problem for websockets, since the portal doesn't have
to restart.  But here's another problem: the game, if it has to handle
web requests from the portal, needs the request object or something
similar.  If the portal receives the request it can't just forward it to
the game process (pickling requests fails, and that's quite logical). 
Perhaps I could "duplicate" request data manually and send them to the
game, but I'm afraid to forget something important in the process.  It
doesn't sound like the ideal solution either.


I hope I explained the situation thoroughly.  Any help would be greatly
appreciated!


Thanks,


Vincent