Yet another simple server in erlang, also a look at use of eunit test framework



The diagram above depicts my simple architecture for an Erlang server and library that responds to various client character requests. You should already be familiar with some of Erlang's advantages and know that the strength of Erlang is its lightweight parallel process/thread management and network programming. Not to mention, it is not a bad easy to learn, general purpose functional programming language.

Starting the server:


The following set of instructions are used to start the server and two processes are created. The first is a simple one that waits for incoming requests from the server middleware piece.

%% Simple functional test for the server library
simple_server_lib() ->
    io:format("starting server <with server library support>~n"),
    AppHandler = start(),
    io:format("trace: top-level app handler~p~n", [AppHandler]),
    Client = #irc_server_info{app_handler=AppHandler},
    ServStart = server_lib:start_link(Client),
    case ServStart of
        { ok, P } ->
            io:format("trace: app:server pid/lib [~p]~n", [P]),
            server_lib:server_listen(P),
            State = server_lib:get_cur_state(P),
            io:format("trace: state [~p]~n", [State]),
            server_handler(#serv_handler_info{lib_handler=P}, idle)         
    end.


The simple wait for messages process



wait_for_messages(idle) ->
    io:format("trace: app:waiting for messages~n"),
    receive
        { connection_closed } ->
            io:format("trace: app: client connection closed~n");
        { shutdown } ->         
            io:format("trace: app: shutting down server.~n"),
            % Exit point for the application, full shutdown.
            erlang:halt();
        Else ->
            io:format("trace: app: invalid message~n")
    end.

The server library



handle_call(irc_server_bind, _From,
            #server_state{client=Client } = State) ->
    Port = Client#irc_server_info.port,
    io:format("trace: lib:handle_call:bind Port:<~p>~n", [Port]),
    {ok, ServSock} = server_bind(Port),
    {reply, ok, State#server_state{serv_sock=ServSock, state=connecting}};
handle_call(irc_accept_clients, _From,
            #server_state{serv_sock=ServSock, app_handler=AppHandler } = State) ->

    io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]),
    ClientSock = server_accept(ServSock),
    %***************
    % Start the handler process
    %***************
    io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]),
    % Pass the main app handler, serv lib handler, client sock
    % And launch the handler process.
    ClientInfo = #client_info{app_handler=AppHandler,serv_lib=self(),
                              client_sock=ClientSock},
    { ok, ClientServ } = client_handler:start_link(ClientInfo),
    % Assign a new controlling process.
    gen_tcp:controlling_process(ClientSock, ClientServ),
    % Active the socket so that the client handler can handle the
    % tcp data.
    inet:setopts(ClientSock, [{packet, 0}, binary, 
                              {nodelay, true},{active, true}]),
    {reply, ok, State};
handle_call(get_cur_state, _From, #server_state{} = State) ->
    % Generic method to get the current state.
    io:format("trace: lib:handle_call:get_cur_state~n"),
    {reply, {ok, State}, State}.

The Client Handler



handle_info({tcp, Sock, Data}, State) ->    
    inet:setopts(Sock, [{active, once}]),
    io:format("trace: lib:info.tcp data [~p]~n", [Data]),
    {Prefix, Command, Args} =
        try data_lib:scan_string(Data)
        catch
            _:X ->
                io:format("ERROR: error attempting to parse input command error:[~p]~n",[X]),
                {"", (Data), ""}
        end,    
    % Invoke the client data handler to process incoming messages.
    HandleState=client_handle_data(State, {Prefix, Command, Args}),
    {noreply, State};
handle_info({tcp_closed, Sock}, State) ->
    %*************************
    % Client has closed the connection.
    %*************************
    io:format("trace: lib:info.tcp_closed state:[~p]~n", [State]),
    AppHandler = State#client_state.app_handler,
    inet:setopts(Sock, [{active, once}]),
    gen_tcp:close(Sock),
    % Send a request to the handler; we lost a connection.
    AppHandler ! {connection_closed},
    {noreply, State#client_state{state=disconn, client_sock=nil}};
handle_info({tcp_error, Sock, Reason}, State) ->
    io:format("trace: lib:info.tcp_error~n"),
    inet:setopts(Sock, [{active, once}]),
    {noreply, State#client_state{state=disconn}};
handle_info(Msg, State) ->
    % Generic handle info handler
    io:format("trace: lib:info.<generic> [~p] [~p]~n", [Msg,State]),
    {noreply, State}.

Running the Application



Full Source (through subversion)

http://openbotlist.googlecode.com/svn/trunk/botlistprojects/laughingman/test/ircserver

Comments

Post a Comment

Popular posts from this blog

On Unit Testing, Java TDD for developers to write

It has been a while, let's kick off 2017 with a blog entry. I have read and I am reading about four or five posts a day about unit testing. It really has been a long time obsession for me. I have moved past the technical and practical considerations on unit testing frameworks and done with the debates with "should you use Junit or Mockito or Karma?" I am more interested in the psychology of unit testing, who does it, likes it, hates it? It really is one of those easy to learn, hard to master concepts. For example, many many may play chess when they are young and can end up being horribly chess players most of their life, I am part of that majority. Unfortunately, I have never played chess and sat down for hours and tried to master it. I never see the common patterns or have a developed end game. I mostly just play with a knowledge of the basic rules. Following good unit testing practices within your software development shop is a lot like playing chess. It is easy to le...
Read more

Is Java the new COBOL? Yes. What does that mean, exactly? (Part 1)

Image
"If you want to know the past, look at your present. If you want to know the future, look at your present." -- Gautama Buddha Java is the new COBOL, whaaaat?     If you are software developer that mainly writes applications for the web; even if you aren't a Java/J2EE developer, you have probably heard the new meme circulating the web and blogosphere. "Java is the new COBOL" . Most blogs and technical writers regurgitate that statement and follow-up by saying that EJBs suck, and some companies are considering Ruby on Rails. I didn't really think much of these posts. I get the impression that a lot of these "managers" don't write any Java or COBOL code. They are really not highlighting the seriousness of the problem. COBOL development has remained stagnant for decades. Java may see the same problem in the future. The Pentagon/DOD has a trillion dollar COBOL problem because it is so difficult to change their ancient infrastructure. Anyon...
Read more

JVM Notebook: Basic Clojure, Java and JVM Language performance

Image
"Measure, don't guess. The primary goal of all performance tuning exercises should be maximize the end user experience given the resource constraints." [1] "It isn't so much a "farewell to the J" as an expansion of the platform opportunities Java provides. Sun's investment to power ongoing development of JRuby and Jython broadens the range and reach of Java, as a whole." -- Rick Ross Overview and JVM Languages    One of the exciting trends to recently emerge from the Java community is the concept of the JVM language. These technologies are all that you would expect them to be. They are implementations of languages that run on the Java Virtual Machine. Some are newly created and some are based on existing, more mature languages. JRuby, Jython are two JVM languages based on CRuby and CPython. Groovy, Scala, Clojure are three completely new JVM languages that were created to add new language features that weren't supported by the core Ja...
Read more