Lecture 19 Distributed Programming Ch 10 Other messagepassing

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

Socket-based Distribution • Node’s available services defined in a configuration file {port, Portnum} {service, S, password, P, mfa, Mod, Func, Args. S} • lib_chan: start_server(Conf) • lib_chan: connect(Host, Port, S, P, Args. C) § 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, Args. C, Args. S)

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(C 1, C 2, …, 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, c 1, V 1} -> V 1; {receive, c 2, V 2} -> V 2+4; {send, c 3, “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 {send, c 1, 37} -> True; {send, c 3, “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 Arr. Upward or Arr. Downward § 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.