[erlang-questions] Re: A discussion in application design and event propagation

[Garrett Smith]

On Mon, Apr 19, 2010 at 10:58 AM, Jay Nelson <jay@REDACTED> wrote:
> Fred Hebert wrote:
>
>> I'm starting this thread to spark a discussion about Erlang software
>> design.
>
> 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
> available.
>
>
>> 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
>> process.
>
> 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
> auto-healing.
>
> 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.

Garrett