Lecture 19

• Distributed Programming (Ch. 10)

• Other message-passing programming models Channels vs mailboxes Synchronous vs asynchronous

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

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

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

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 nodespawn(‘bilbo@hauser-desktop’, echo, start, []).{echo, ‘bilbo@hauser-desktop’} ! “abc”.S2 = spawn(‘bilbo@hauser-desktop’, echo, server, []).S2 ! 17.

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 local proxy for talking to the server

• When client connects call on the server: Mod:Func(MM, ArgsC, ArgsS)

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

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)

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

Select in Concurrent ML select {receive, c1, V1} -> V1; {receive, c2, V2} -> V2+4;

{send, c3, “def”} -> 17end• 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

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

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?

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

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.