[Haskell-cafe] Looking for architecture/infrastructure advice on coping with thousands of concurrent clients
alexander.kjeldaas at gmail.com
Wed Jul 9 20:48:42 UTC 2014
I'd have user state serviced by a thread per user. Then have separate game
state serviced by another thread. Then use zmq or cloud Haskell for
interconnect between the two states.
Scalability games then boils down to what cross sectional bandwidth you can
get by optimizing the interconnect and the placement/locality of the state.
Scaling the number of client connections can be done independently.
On Jul 9, 2014 7:40 PM, "Isak Hansen" <isak.hansen at gmail.com> wrote:
> Let's just imagine there aren't enough poker sites out there already and
> that it makes sense to build another one. Basically, there will be players
> connecting to one or more tables, most likely talking some kind of JSON
> based protocol with the server(s).
> #1 - What's a good way to set up and maintain compressed and encrypted
> connections from the clients to my cluster? I've been wanting to try out
> websockets, think that'll do?
> #2 - I'm new to Haskell and would appreciate thoughts on how to store and
> process game state. Imagine a plain application managing 1000 tables of
> poker, responding to player input (that magically appears) and timer events
> (e.g. folding players that fail to take action). What data structures and
> libraries should I be looking at here? Thoughts on concurrency and how I
> organize program flow?
> #3 - I'm thinking of ZMQ to wire components together. Would I be better
> off basing my cluster on Cloud Haskell or some other library for
> distributed work?
> Would love some quick pointers and feedback here, thanks in advance,
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe