Re: Servers, Threads, and the Ruby Way -- Architecture Question

Robert Klemme wrote in post #1036718:
> On Tue, Dec 13, 2011 at 9:47 PM, EP PG <[e-mail]> wrote:
>> two ports via two threads like I already have. The other process is one
>> that basically creates a thread for each "game" that gets added to the
>> queue. Does this sound reasonable?
>
> You do not need two processes.  One process with multiple threads is
> much easier.  If game actions only occur for messages received from
> clients you could to this:
>
> - two listening threads (one per port obviously; if you want to get
> fancy you can use a single thread with select())
> - each listener spawns a reader thread per client
> - if the game is multiplayer, you need 1 shared instance per game - if
> not you want to have one instance per user
> - logic is done inside reader threads which must hold a lock on the
> game state (because it is shared)
> - if you need to process messages per client asynchronously (i.e.
> receive the next message while the previous one is processed, you can
> use an additional thread per client)
>
> If games have activities of their own (i.e. things happening after
> fixed time or such) you need additional threads (one or more) per
> game.
>
> Another option might be event machine.
> http://20bits.com/articles/an-eventmachine-tutorial/
> http://rubyeventmachine.com/
>
> Kind regards
>
> rober

Hi, thanks, after reading around the web and thinking about it I can see 
what you're saying and it makes sense. I've also decided that I won't 
run the games as a thread, but simply as a record on the database which 
contains the game "state" (the game runs slowly so I don't need to 
update it too often). That way when I get a user connection all I need 
to do is check to see if the user's move is "legal" and then update the 
game state in the database if it is. So I only really need the two 
threads for the two connections (from user and game creation command) 
and that's it (well, plus the threads that do the connecting to the 
database, and the rules checking I guess).

So yes, there are n games (records in the database) and each game has j 
players (users authorized to modify the state in the nth game). The 
server runs many games and listens to connections from many users. When 
a user connects, "something" (as separate thread?) sees what game that 
user is assigned to and reads the user's move. It then checks the user's 
move to see if it's legal and if it is, it modifies the game's state 
according to the move. Ideally, I should be able to handle several moves 
(from different users) simultaneously and handle accesses to different 
parts of the database (i.e. different games) by different users 
simultaneously.

I was also looking into EventMachine after doing some thinking and 
reading and thought it could be useful in case several users wanted to 
access the database at the same time (for say, different games). But I 
didn't quite understand the tutorials and couldn't quite figure out how 
to set up the two listening ports, plus the database accesses (different 
for each client/user connection) at the same time and without the 
database accesses blocking things. I guess I need to do more reading.

@Tony Arcieri: How is Celluloid different from EventMachine? And when 
would I use one vs the other?

Thanks and I apologize again for my newbie questions.

-- 
Posted via http://www.ruby-forum.com/.