Poker appliance

[Vance Shipley]

On Fri, Apr 01, 2005 at 06:39:24PM +0100, Joel Reymont wrote:
}  
}  Given that my remote nodes will be Python clients, what kind of behavior

First off you won't be able to do more than a couple hundred clients if
you intend to use erlang distribution.  The distribution method isn't
well suited to a lot of nodes.  There used to be a limit of something 
like 255 known nodes and although I think the hard limit was removed the
basic problem remains.  You'll need to implement your RUDP in both the 
client and server and use that for all communications.

}  should I choose for my server? Should I pick gen_server or gen_tcp? I

You probably want to implement the RUDP protocol in a gen_fsm behaviour
module.  You would use gen_udp as the lower layer and provide a service
to application processes.  

}  I see the poker game as a state machine that transitions from waiting for

Implement this in gen_fsm behaviour as well.

}  Players themselves have state. They can be logged in or not
}  authenticated. They can be watching a game or playing. 
  
The basic unit of abstraction in Erlang is a process.  You should model
your system using a process for each truly concurrent activity in the
real world.  A player would be represented by a process implemented in
a gen_fsm module.  A game could also be a gen_fsm process.  An RUDP 
association would need a gen_fsm process as well.

You store state in a term which is passed from call to call:

logged_in(Event, StateData) ->
   ...
   {next_state, authenticated, NewStateData};

authenticated(Event, StateData) ->
   ...
   {next_state, watching, NewStateData};

... and so on.

Now you could use a gen_server process to handle many clients by having
their state stored in the gen_server StateData but what would be the 
point?  Since processes are cheap you instead have one gen_fsm for every
actual state machine.

}  I read through the plain fsm thread and I'm not quite sure if I should go
}  with gen_fsm or plain fsm. I'll appreciate your advice here. 
  
I always suggest sticking with one of the OTP behaviours until you feel
you know better than the experts.  Way, way later (i.e. never) you may
elect to optimize by using your own implementation. 

Ulf's contribution is interesting but I think that in it's attempt to
make things more Erlangish it makes it less OTPish.  At this stage of
your project I think you'd benefit more from OTP purity.

[... /me prepares to be admonished ...]

}  Last but not least, my communications should be encrypted. I read how I
}  can establish inter-node SSL connections but I'm somewhat at a loss
}  regarding how to connect the Python side.

See the crypto module.  Use it directly to encrypt/decrypt your RUDP
payloads.

	-Vance