megaphone I

Previously...

• I created the sender.
• I started planning the megaphone module.
• I did some more planning for the megaphone module.

The start of the megaphone module needs to kick off the sender and the receiver:

start({gen_tcp, Socket}, _Opt) -> 

    megaphone_receiver:start(Socket),

    megaphone_sender:start(Socket),

    Pid = spawn(megaphone, start_module, []),

    register(megaphone, Pid).

Incidentally, I haven't tested any of this code so it probably doesn't work.  In fact, I'm counting on finding, revising and fixing the various bugs in the system to serve as the foundation for many tedious blog posts.  This is partially because I need something to write about but also because that is the way that real software happens.

Anyways, back to the module.  The start_module function just sets up the state for the new process:

start_module() ->

    State = #megaphone_main_state{connectionToResults = dict:new()},

    main_loop(State).

The main_loop function sits in a loop waiting for events to process.  Specifically, it waits for messages from the receiver for new packets and the clients asking for new packets:

main_loop(State) ->

    receive

        { get_data, From, ConnectionID } ->

            State2 = getData(State, From, ConnectionID),

            main_loop(State2);

        { put_data, ConnectionID, Data } ->

            State2 = putData(State, ConnectionID, Data),

            main_loop(State2);

        { send_data, ConnectionID, Data } ->

            State2 = sendData(State, ConnectionID, Data ),

            main_loop(State2);

        { shutdown } ->

            megaphone_receiver ! { shutdown },

            megaphone_sender ! { shutdown },

            ok

    end.

It is not clear to me if the logic deals with multiplexing outbound messages really belong in megaphone or in on the of sender or receiver module.  For right now the notion of having one interface that does everything is a nice goal to strive for, with the understanding that I can change my mind and use a different architecture if it appears that the newer approach is better.  We shall see.

  

I'm adding the shutdown message with an eye towards being able to gracefully shut down the megaphone module.  Note that, when propagating the shutdown message to the sender and the receiver, megaphone does not wait for those modules to actually complete a shutdown.  This is because there is no guarantee that these processes will actually be running (they may have crashed).  

I will probably add some sort of restart capability for those rare (HA) situations where one of the sub-modules have crashed and needs to be restarted.  I could also use the monitor capability.

The nice thing about being decisive is that you can make a decision over and over again.

Next time, the implementations of the various main_loop functions.