Lecture 19

1. Lecture 19 • Distributed Programming (Ch. 10) • Other message-passing programming models • Channels vs mailboxes • Synchronous vs asynchronous

2. Why Distributed • Natural decomposition of the problem • Examples: • chat system – user agents and server; • storefront – customer agent and store server; • file sharing – peer-to-peer interactions between hosts that have files and hosts that want them • Performance • Apply multiple processors to get the work done faster • Availability • Backup resources to take over if primary fails

3. Erlang approaches • “Distributed Erlang” • simple extension of the Erlang programming model to run on multiple computers (Erlang nodes) • Nodes are authenticated: to participate in a cluster a node must possess the cluster cookie • Nodes are trusted: fundamentally a node will do whatever another node in its cluster asks it to do • rpc:call(bilbo@hauser-office, erlang, halt, []). • Socket-based distribution • Nodes have an explicitly identified set of services that they are willing to perform for other nodes

4. Distributed Erlang • What is a node? • A running instance of erl • Has a name given with -sname or -name switch • Has a hostname obtained from the machine on which it is running • A host may have many erlang nodes • Primitives • spawn(Node, Fun) spawn(Node, M, F, A) • spawn_link(Node, Fun) etc. • Query functions for node identities, connectedness, etc. pp. 175-6

5. Example -module(echo). -export([start/0, server/0]). start() -> register(echo, spawn(fun() -> server() end)). server() -> receive {Client, M} -> Client ! M, io:format("~p~n", [M]) end, server() . On another node spawn(‘bilbo@hauser-desktop’, echo, start, []). {echo, ‘bilbo@hauser-desktop’} ! “abc”. S2 = spawn(‘bilbo@hauser-desktop’, echo, server, []). S2 ! 17.

6. Socket-based Distribution • Node’s available services defined in a configuration file {port, Portnum} {service, S, password, P, mfa, Mod, Func, ArgsS} • lib_chan:start_server(Conf) • lib_chan:connect(Host, Port, S, P, ArgsC) • Called on client • Returns {ok, Pid} • Pid is a localproxy for talking to the server • When client connects call on the server: • Mod:Func(MM, ArgsC, ArgsS)

7. Socket-based distribution (2) • The server code has to be prepared to receive and send very specific messages – the socket distribution protocol (see pp. 181-182) • Client sends X to the proxy, server sees {chan, MM, X} • Server replies by sending {send, Result} to MM. • Server may see {chan_closed, MM} in mailbox meaning client disconnected • Main thing to note: server only interacts with clients who know the password for that service and node only exposes specific service

8. Channels vs mailboxes • Erlang mailbox is implicit part of a process – no separate identity • A channel is a value – it can be passed, stored, like any other value • Any process can send or receive on a channel • Channels are typically FIFO • Problem: with two or more channels how do you process the first message to arrive on either? C = select(C1, C2, …, CN); receive(C)

9. Asynchronous vs Synchronous MP • Erlang uses asynchronous message passing: sender does not wait for receiver to be performing a receive operation; messages are buffered • Concurrent ML uses synchronous message passing: sender does not proceed past the send operation until the receiver has received the message • select extended to handle both send and receive

10. select {receive, c1, V1} -> V1; {receive, c2, V2} -> V2+4; {send, c3, “def”} -> 17 end Observe this is very similar to Erlang receive except can only distinguish on channel, not entire message content Only one of the clauses of the select is successful. Its expression is the result of the select select {send, c1, 37} -> True; {send, c3, “abc”} -> False; end Select in Concurrent ML

11. Synchronous MP virtues and flaws • More powerful than asynchronous – you can implement an asynchronous MP system using a synchronous MP system but not vice versa • More prone to deadlock • Essentially impossible to implement in a distributed fashion

12. Toward the next project: Lifts • Known in the USA as elevators • Simulation of physical system using agents • Idea: use a process (agent) to model the behavior of the important physical objects involved in controlling a set of elevators • Button set on each floor (call Up or Down) • Button set in each lift (selected destinations) • Lifts themselves: position, direction of travel, ordered destinations to visit • Scheduling: which lift should respond to a particular call?

13. Example – Floor Agent • Receive message up or down • Change state of button light • Figure out which lift should service the request • Send each lift a message asking it to predict how long it will take to arrive based on its current schedule • Collect responses • Choose best response • Send an accept to that lift – which adds that floor to its schedule • Send reject to the others • Note “check then act” in the lifts’ part of this protocol – do they wait for the accept or reject before doing anything that would invalidate their answer? • Receive message ArrUpward or ArrDownward • Change state of button light

14. Lift cars • Have buttons for stopping at different floors • Take time to move from position to position • Take time to load/unload each time they stop • We’ll simplify to say that they take 1 sec/floor moved and pause for 5 seconds when they stop at a floor.