From: Robert Klemme <shortcutter@...>
Date: 2011-12-14T21:59:13+09:00
Subject: Re: Servers, Threads, and the Ruby Way -- Architecture Question

On Tue, Dec 13, 2011 at 9:47 PM, EP PG <epasquali@hotmail.com> wrote:
> EP PG wrote in post #1036583:
>> Hi there, I'm a TOTAL Ruby newbie, but not new to programming.
>
> [snipped, it is long!]
>
>> Architecture ideas?
>
> OK., I thought of something. Please let me know if it sounds ridiculous.
>
> I will  have 2 processes. ONe is the "server" process which listens on
> 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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/