a framework OTP a server generic and specific OTP, Open Telecom Platform, the system that we have used:

Size: px

Start display at page:

Download "a framework OTP a server generic and specific OTP, Open Telecom Platform, the system that we have used:"

Jared Norris
7 years ago
Views:

1 a framework OTP OTP, Open Telecom Platform, the system that we have used Johan Montelius KTH VT16 compiler and run-time system set of libraries generic templates to implement servers tools and services database servers, parsers, debugger etc a server 1 / 25 generic and specific 2 / 25 gen_start(init) -> spawn(fun() -> init(init) end). init(init) -> server(state). What is generic, same for any server, and what is specific. An important factor in any systems development is to work with layers of abstraction. server(state) -> {request, Msg, From}-> server(updated); Separate the generic behavior of a set of services in one abstraction, and then use this abstraction when defining the actual services. 3 / 25 4 / 25

2 abstractions a server gen_start(init) -> spawn(fun() -> init(init) end). sum([]) -> 0; sum([h T]) -> H + sum(t). init(init) -> server(state). sum(l) -> foldr(fun(h,a) -> H + A end, 0, L). server(state) -> {call, Msg, From}-> server(updated); a generic server 5 / 25 a generic server 6 / 25 start(init) -> spawn(fun() -> gen_init(init) end). gen_init(init) -> {ok, State} = init(init), server(state). server(state) -> {call, Msg, From}-> {reply, Reply, Updated} = handle_call(msg, State), server(updated); -module(gen_server). start(module, Init) -> spawn(fun() -> init(module, Init) end). init(module, Init) -> {ok, State} = apply(module, init, [Init]), server(module, State). 7 / 25 8 / 25

3 a generic server the server server(module, State) -> {call, Msg, From}-> {reply, Reply, Updated} = server(module, Updated); apply(module, handle_call, [Msg, State]), -module(account). start(init) -> gen_serverstart(account, Init). init(state) -> {ok, State}. hande_call(saldo, _From, State} -> {reply, {saldo, State}, State}. gen_server 9 / 25 the gen_server api 10 / 25 The gen_server definition init(args) return {ok, State} or {stop, Reason}. handle_call(request, From, State) return {reply, Reply, New_state} Reply is sent to the requester {noreply, New_state} no reply is returned {stop, Reason, New_State} terminate/2 is called handle_cast(request, State) similar but no replies terminate(reason, State) opposite to init/1 there are more The gen_server interface gen_serverstart(module, Args, Options) starts the server defined in Module gen_servercall(server, Request) returns a reply from the server gen_servercast(server, Request) sends the request, no reply there are more 11 / / 25

4 the server gen_server -module(account). The gen_server defines a server with a request-reply pattern. start(init) -> gen_serverstart(account, Init). There is no implicit deferral of messages! saldo(account) -> gen_servercall(account, saldo). All messages must be handled by the handle_call and handle_cast functions. init(state) -> {ok, State}. A compiler directive in the module is used to have the compiler check that all necessary functions are included hande_call(saldo, _From, State} -> {reply, {saldo, State}, State}. -behaviour(gen_server). gen_fsm 13 / 25 event handlers 14 / 25 What is an event? There is a sister behavior gen_fsm, that tries to capture the generic behavior of a finite state machine. Send all events of a particular type to an event manager process. Register handlers modules wit the manager process. Each time an event is d by the manager, all handlers will be called. 15 / / 25

5 gen_event gen_event -module(error_handler). -export([init/1, handle_event/2, terminate/2]). init(name) -> {ok, []}. handle_event({error, Msg}, []) -> ioformat("error ~w~n", [Msg]), {ok, []}; handle_event(_, []) -> {ok, []}; terminate(_args) -> ok. supervision of processes 17 / 25 -module(test). start() -> Manager = gen_eventstart({local, tracer}), gen_eventadd_handler(tracer, error_handler, []), server(). server() -> {expected, Msg} -> handle(msg), server(); Error -> gen_eventnotify(tracer, {error, Error}), server() the generic supervisor 18 / 25 start(init) -> process_flag(trap_exit, true), Server = gen_serverstart_link(my_server, Init, []), supervise(server, Init). init(args) returns {ok, Modes, Specs} that describes which servers should be started and how the supervisor should operate supervise(server, Init) -> { EXIT,Server, _Reason} -> Restarted = gen_serverstart_link(my_server, Init, []), supervise(restarted, Init); terminate -> gen_servercast(server,stop_what_your_doing) Modes {Strategy, Allowed, Time} one_for_one if a server dies, restart it all_for_one terminate all servers and restart them rest_for_one terminate the ones after the server that died and then restart them 19 / / 25

6 the generic supervisor a supervisor tree Specs {Id, {Module, Name, Args}, Restart, Shutdown, Type, Modules} Id a name local to the supervisor {Module, Name, Args} description of the server to start Restart transient (do not restart), temporary (restart if exception) or permanent (always restart) Shutdown for how long is the process allowed to do clean-up when terminated Type a or supervisor Modules used when code base is updated supervisor supervisor 21 / 25 other OTP frameworks 22 / 25 An OTP server architecture becomes quite complicated. It is over-kill for smaller systems or when you re all alone. It is invaluable for larger systems or if you are more than one programmer. Try first to implement a supervisor tree from scratch, then you will appreciate (and understand) the power of the OTP framework. If you start by learning OTP without having done it yourself, you will most likely not understand how it works or why it is needed. application handle a set of modules, and possibly a supervisor tree, as one component release a set of Erlang applications and additional information that should be treated as a release release handling updating a running system to the next release rebar (not a proper part of OTP), the Erlang framework to automatically build applications and releases 23 / / 25

7 Summary The OTP framework is invaluable when developing larger applications. You should not start using it before you know how to program in Erlang. 25 / 25

THE BASIC SERVER IN ERLANG

THE BASIC SERVER IN ERLANG The first common pattern I'll describe is one we've already used. When writing the event server, we had what could be called a client-server model. The event server would calls