[erlang-questions] Re: A discussion in application design and event propagation
Mon Apr 19 18:14:23 CEST 2010
On Mon, Apr 19, 2010 at 10:58 AM, Jay Nelson <> wrote:
> Fred Hebert wrote:
>> I'm starting this thread to spark a discussion about Erlang software
> Just yesterday I wanted to start a similar thread on "concurrency patterns."
> I will do that as a separate thread.
> I've found that with other languages I think of "software design." With
> erlang, I find it more fruitful to think of "architectural design" because
> the language allows you to make system level choices and enforce them in the
> software structure. Limiting your thinking to "software patterns" and
> "software design" may not get you thinking about the right elements of your
> problem. It's just that other languages have no other elements to the
> problem than the software itself, so our tendency is to revert to what's
>> You'd have (I imagine) one process representing the dealer and the table
>> (D). Then you have 3 players, P1, P2 and P3, each represented as a
> That's a good start using software as the principle. Instead let's look at
> the architectural issues:
> 1) Where are users coming from?
> - I'll assume Internet connected.
> 2) What to do if a connection is lost?
> - Most game tables don't allow you to bail when you are losing.
> - A 'bot' finishes the game for you since money is on the line.
> 3) How many connections are you expecting?
> - One game table is easy inside erlang distribution.
> - Many tables is too much inter-node chatter.
> Using distributed erlang you get node-to-node pings to detect node failures.
> This can lead to too much data traffic. If many users are expected, you
> probably want TCP connected users rather than erlang node connected users.
> Distributed erlang (using the OTP distribution techniques) tends to require
> predetermined node names and process configurations, as opposed to
> Distributed TCP which leads to dynamic connectivity without enumerating
> participants in configuration files.
> pg also uses global names to manage the groups. This introduces potential
> contention for the global name (no global resource goes unpunished in
> concurrent architectures -- Patrick Nyblom SF 2010).
> If you consider the architecture, you are missing some elements in your
> sketch. You should include them before you evaluate the design choices:
> 1) User initiates a connection from a browser (assumption on my part)
> 2) TCP connects the user to some erlang server process
> 3) User needs to be represented by a proxy in case of connection loss
> 4) Current game should be able to finish if a user disconnects
> 5) New game may or may not be allowed to start if user missing
> New requirements:
> 6) Can non-players observe the game?
> 7) Can non-players interact with game players (chat with them)?
> I can see an approach that there is a gallery and the players at the table.
> The gallery can chat amongst themselves, and the players can interact
> amongst themselves. The gallery observes all, the players only see the
> table (for example).
> Architecturally, I would determine the principles that define a good
> solution before choosing a software pattern:
> 1) How many users can be supported?
> 2) What happens in the common failure scenarios?
> 3) How do you enforce the game rules (audience vs players, etc)?
> 4) What kind of responsiveness is needed?
> 5) How much hardware are you willing to configure?
> 6) How dynamic is your configuration and user participation?
> For this problem gen_event probably has the most opportunities for you as
> the central design element. It allows multiple groups to observe events
> with differing functionality for the groups. You could use pg for the
> players and for the gallery, and gen_event to distribute the messages. But
> you are missing the connecting server and the proxying user process that
> automatically represents (and governs) the users actions.
> With erlang, don't just look at software patterns, step back and look at
> architectural patterns. You will find yourself architecting loosely coupled
> systems, with layers of connectivity, routing, application constraints and
> application logic. Each of these elements can use different software
> patterns, but the way they interact should be flexible, dynamic and
> Also remember, there is no "good" or "bad" solution. Each solution has
> certain characteristics it exhibits such as speed, resilience, capacity,
> etc. One solution may be better for one situation and worse for another,
> based on the measurement that matters in each case. Don't be biased against
> an approach that was rejected in a previous problem application -- it may
> turn out useful in a different situation.
Thinking in architectural terms, this strikes me as a pub/sub problem
that a message broker would handle well. RabbitMQ (AMQP), e.g., would
let you publish events to an exchange, which can then be routed to
various queues via bindings. RabbitMQ in particular is a nice option
for Erlang developers.
More information about the erlang-questions