Mobile UNITY: Reasoning about Physical and Logical Mobility

Gruia-Catalin Roman

August 2002

2

Presentation Overview

1. Mobile Computing

2. Reasoning about Motion and Space

3. Coordination in the Presence of Mobility

4. Formal Derivation

5. Applications of Mobile UNITY

3

Mobile Computing

Technological and social trends Research opportunities Perspectives on mobility Research directions

1

4

Introduction

Software Engineering is a discipline that studies• Software artifacts

• Processes as (approximate) guarantors of quality

• People as (imperfect) producers of software Mobile Computing entails the study of systems in which

computational components may change location Mobile Computing Laboratory (MobiLab) is committed to the

development of formal models, algorithms, middleware, and applications for mobile computing• Context aware computing

• High mobility environments (e.g., highways)

5

Mobile Computing Laboratory

Formal models of mobility (Mobile UNITY) Algorithms and protocols for mobile computing

– Nomadic computing (guaranteed message delivery)

– Ad hoc networks (group membership, termination)

Middleware for mobile computing (LIME) Mobile applications

– Highway environment

– Outdoor games

– Indoor collaborations

6

Advent of Mobility

Societal pressures• Computing and communication melting into the fabric of society

Technological advances• Wireless communication

– Nomadic systems

– Ad hoc mobile systems

• Miniaturization

• Advances in sensor technology Software engineering

• Ubiquitous connectivity (global or localized)

• Service discovery and provision

• Context aware computing

• Mobile code

7

Physical Mobility

Fixed network Nomadic computing Ad hoc computing

8

Research Issues and Trends

New design constraints• Frequent disconnection

• Unpredictable movement

• Asymmetric bandwidth

• Limited resources Interesting opportunities

• Spatial knowledge

• Movement profile Increased demands

• Reasoning about behavior

• Connectivity maintenance

• Adaptation

9

Logical Mobility

Code on demand Remote evaluation Mobile agents

10

Research Issues and Trends

Code on demand is made popular by Java Mobile code languages (e.g., Obliq, Facile, Telescript) are

losing ground Mobile agent systems (e.g., D’Agents) are an emerging new

technology Middleware is growing in practical importance

11

Emerging Mobility Paradigms

Continued access to remote resources Delegation to mobile agents Disconnected operation Ad hoc grouping of people and devices Mass mobility Wide open systems

12

A Special Challenge: Ad Hoc Networks

No fixed network infrastructure Frequent disconnections Transient interactions Decoupled computing Open environment Physical and logical mobility Limited guarantees

13

Sample Applications

Highway information management Disaster response Military applications Contamination zone exploration Wireless anywhere classroom Self-organizing office and factory Cave and mine exploration Video games in physical spaces

14

Distinct Perspectives

Milner et al (π-calculus) Meseguer (Mobile Maude) Cardelli et al (Mobile Ambients) Wermelinger and Fiadeiro (connector semantics) DeNicola et al (LLinda) Riely and Hennessy (disconnection as process failure)

15

Abstract Treatments of Mobility

∏-calculus

Mobile UNITY

Mobile Ambients

…

16

mobileagent

federated tuple space

hosttuple space

A Pragmatic Perspective — LIME

Model characteristics• Linda-style coordination

extended to ad hoc settings

• Transparent data sharing based on connectivity

• Atomic and transitive engagement and disengagement

• Selective data sharing

• Transparent tuple migration

• Novel reactive constructs Formal semantics

• Reduction to Mobile UNITY Distribution

• Open source on SourceForge

17

Research Considerations

Unit of modularity, execution, and mobility Treatment of space Definition of movement Compositionality Integration of physical and logical mobility Open environment Decoupled computing Coordination versus communication Model delivery mechanics Effective implementation Expressive power

18

Reasoning about Motion and Space

Unit of execution and modularity A notation system A proof logic Unit of mobility, execution, and modularity Decoupled system specification and design Location-based coordination Exploring the space concept Proof logic revisited

2

19

A Starting Point — UNITY

Understand and manage programming complexity Identify what is common Develop a small theory adequate for a broad range of tasks

• Tasks– Specification

– Derivation

– Verification

• Theory– Computational model (minimalist)

– Proof logic (assertional)

– Design heuristics

20

Computational Model Fundamentals

State• Static set of named variables

Deterministic assignment statement (state transition)• Conditional multiple assignment

Non-deterministic flow of control (concurrency) Synchrony and asynchrony Missing elements

• No flow of control constructs (weakly fair selection)

• No notion of explicit termination (fixed point) Program is the unit of modularity and execution Program UNION provides the means for composition

21

Programming Notation

Problem definition: Given two ascending sequences f and g, determine if they represent the same set

Assumptions:f[0] = g[0] f[N-1] < f[N]

f[N] = g[N] g[N-1] < g[N]

i : 0 ≤ i ≤ N :: h[i] ≤ h[i+1] where h denotes f and g Illustration:

1 3 3 3 3 4 4 6 6 8 8 8 9

1 3 3 4 4 6 6 6 7 7 7 8 9

22

Sample Program

Program Compare

declare u, v : integer

initially u, v = 0, 0

assign

u := u+1 if u < N f[u] = f[u+1]

v := v+1 if v < N g[v] = g[v+1]

u, v := u+1, v+1 if u < N v < N f[u+1] = g[v+1]

end

23

Sample Program

Problem definition: Compute the largest value in array A Solution:

Program Maximum

declare A : array [0, 2M-1] of integer

assign || i : 0 ≤ i < M :: A[i] := max(A[2i], A[2i+1])

end Illustration:

0 1 2 3 4

0/1 2/3 4/5 6/7 8/9

0/1/2/3 4/5/6/7 8/9/...

24

Basic Proof Logic

Hoare triple—assertions over programs{p} s {q} where s is a statement in program P

{y = k} x, y := 0, y+1 {x > -3 y > k} Assignment axiom makes mechanical verification feasible

{p} x := exp {q} p q[x/exp]

{y = k} x, y := 0, y+1 {x > -3 y > k}

y = k 0 > -3 y+1 > k Quantification over program statements is all that is needed

25

Safety Properties

Unless relation s : s in P :: {p q} s {p q}

________________________________________________________________________________________

p unless q Derived relations

stable p p unless false

const p stable p stable p

inv p (init p) stable p Illustration (Program Compare)

u = k unless u > k

stable u = N

const f[3] = g[8]

inv set i : 0 ≤ i ≤ u :: f[i] = set i : 0 ≤ i ≤ v :: f[i]

26

Simple Progress Properties

Ensures relationp unless q s : s in P :: {p q} s {q}

________________________________________________________________________________________

p ensures q Illustration (Program Compare)

? u = k ensures u > k

? f = g u = k < N ensures u > k

3 3 4 — no statement increments u

3 3 4

provable f[u] = f[u+1] ≠ g[v+1] u = k < N ensures u > k

27

Leads-to Relation

Base casep ensures q

___________________________________

p leads-to q Transitivity

p leads-to r r leads-to q___________________________________________________________

p leads-to q Disjunction

m : m W :: p(m) leads-to q ______________________________________________________________________

m : m W :: p(m) leads-to q

Illustration (Program Compare)u < u0 v < v0 u+v = k leads-to u+v > k

where set i : 0 ≤ i ≤ u0:: f[i] = set i : 0 ≤ i ≤ v0 :: f[i]

28

Program as Unit of Mobility

Rationale• Program size is arbitrary

• Uniform treatment ofmobility, modularity, execution

• Reuse of composition rules

• Reliance on existing proof logic

• Abstract treatment of logical and physical space

Adjustments to the model• New location variable • Total separation of name spaces

(e.g., program.variable) UNITY + + unique names

X

Y

29

A Notation for Mobility

Program Cart at declare x, d : integer

initially x, d, = 0, -1, 0

assign

d := +1 if = 0 x ≠ 0

d := –1 if = N x = 0

:= +d if 0 < +d < N

end

30

Technical Implications

Space definition is outside the model Programming schemas allow for location aware, location

controlling, or location oblivious program specification Motion is reduced to value assignment The proof logic remain unchanged Programs share the space but cannot interact with each other

• x ≠ 0 leads-to = N provable

• x ≠ 0 leads-to x = 0 ?

31

Decoupled System Specification

System PayloadTransfer

Program Cart(k) at ... end

Program Loader(i) at ... end

Program Unloader(j) at ... end

Components

Loader(1) at 0 Cart(1) at 0 Unloader(2) at N

Interactions

... coordination statements

end Technical Notes:

• Modifications assumed in the definition of Cart

• Formally, the system is closed and bounded in size

32

Location-Based Coordination

The simplest coordination statement is the asynchronous data transfer

Coordination statements can reach across program boundaries in a manner transparent to the programs

Operationally, one can treat the coordination section as an additional program to be composed

The software engineering advantage rests with the separation of concerns and strong decoupling

Illustration:

Loader(i).q, Cart(j).x := 0, Loader(i).q

when Loader(i). = Cart(j).

33

Exploring the Space Concept

The when clause is not space specific (general predicate) Spatially dependent coordination is schema induced

• co-location

• relative distance

• co-existence within a space

• remote coordination across logical spaces Both physical and logical spaces can be modeled

• separately

• combined Movement rules are space specific Schemas can be enhanced with specific program properties

34

Sample Spatial Structures

Line Circle Physical plane Network hosts and links Directed graphs and lattices Gradient fields Embedded spaces

• coordination within S

• move into S

• move out of S

35

Proof Logic Revisited

Composition of programs and interactions follows the basic rule of program union: join the corresponding sections of all the programs involved

UNION Theorem• p unless q in F G (p unless q in F) (p unless q in G)• p ensures q in F G

(p unless q in F) (p ensures q in G)(p unless q in F) (p ensures q in G)

Corollaries (relation denotes unless, inv, and ensures)

p relation q in F stable p in G__________________________________________________________________

p relation q in F G

36

Coordination in the Presence of Mobility

Coordination perspective Seeking minimalism Coordination primitives Sample system Proof logic implications Expressive power Coordination schemas

3

37

The Coordination Advantage

Origins rest with the temporal and spatial decoupling advocated in Linda

Coordination models• separate computational and communication aspects of a system

• make communication transparent using high level constructs

• are amenable to rapid deployment by means of middleware Tuple space models dominate coordination research Communication complexities in mobile computing make

coordination strategies particularly attractive A broad range of coordination models can be built

38

Minimalist Formal Perspective

What primitives offer sufficient expressive power to construct a reasonably rich set of coordination models and modalities

What is the criteria by which are we judge richness• empirical evaluation

Is there a formal notion computational power• not yet established

Mobile UNITY employs a very small set of distinct constructs• labeled statement

• assignment

• transaction

• inhibitor

• reaction

39

One-Bit Communication

Sender at s

Variable• Sender.bit

Actions• write0 :: bit := 0

• write1 :: bit := 1

Receiver at r

Variable• Receiver.bit

Actions• read :: h := h • bit

40

Transfer Statement

Sender at s

• write0 :: bit := 0

• write1 :: bit := 1

Receiver at r

• read :: h := h • bit

• INTERACTIONS •

Receiver.bit := Sender.bit when Sender.s = Receiver.r

inaccurate history with repeated and missed values

41

Reactive Statement

Sender at s

• write0 :: bit := 0

• write1 :: bit := 1

Receiver at r

• read :: h := h • bit

Receiver.bit := Sender.bit reacts-to Sender.s = Receiver.r

inaccurate history but the values of bit are consistent

42

Inhibit Statement

Sender at s

• write0 :: bit, n := 0, n+1

• write1 :: bit, n := 1, n+1

Receiver at r

• read :: h, n := h • bit, n+1

Receiver.bit := Sender.bit reacts-to Sender.s = Receiver.r

inhibit writei when Sender.n > Receiver.n Sender.s ≠ Receiver.r

inhibit read when Sender.n ≤ Receiver.n Sender.s ≠ Receiver.r

accurate history at most one step behind

43

Transaction

Sender at s

• write0 :: bit := 0; bit :=

• write1 :: bit := 1; bit :=

Receiver at r

• h, f := h • bit, 1 reacts-to bit ≠ f = 0

• f := 0reacts-to bit =

Receiver.bit := Sender.bit reacts-to Sender.s = Receiver.r

time

44

Clocked Transmission

Sender:

write :: bit := reacts-to odd(t/2) t > 0

tic :: t := t+1

Receiver:

read :: := bit reacts-to even(t/2) t > 0

tic :: t := t+1

engage

disengage

45

Clock Synchronization

Receiver.bit := Sender.bit reacts-to Sender. = Receiver.

on := true || Sender.t := 0 || Receiver.t = 0

reacts-to on Sender. = Receiver.on := false || Sender.t := 0 || Receiver.t = 0

reacts-to on Sender. ≠ Receiver.inhibit Sender.tic when Sender. ≠ Receiver.inhibit Receiver.tic when Sender. ≠ Receiver.

inhibit Sender.tic when Receiver.t - (Sender.t+1) >1

inhibit Receiver.tic when (Receiver.t+1) - Sender.t >1

46

Reduction to UNITY

The overall system must appear as a set of atomic statements whose selection satisfies a weak fairness constraint• Take the union of all non-reactive statements

• Strengthen the guards of all inhibited statements The weakest precondition must be computable for each

statement appearing in the program text• Treat all reactive statements as a program which executes to

fixpoint after each non-reactive statement (including inside transactions)

47

Hoare Triple Redefined

For a proper choice of H and reactive statements R

p (s) q, {p (s)} s {H},

H leads-to (FixPoint(R) q) in R__________________________________________________________________________________

{p} s* {q}

48

Transaction Semantics

Reduction to sequential composition

{p} s1; s2; ... sn-1* {r}, {r} sn* {q}__________________________________________________________________________________

{p} s1; s2; ... sn* {q}

49

High Level Constructs

Read only shared variableA.x B.x when r

Shared variableA.x ≈ B.x when r

Engage clauseengage(A.x, B.x) when r value

Disengage clausedisengage(A.x, B.x) when r value 1,2

50

Transitivity

YX

2

2

2

2Z4

4

4

4

2

4

4

X to Y Y to X

for composition

Y to Z

2

X := 4

51

High Level Constructs

Co-selectionA.s B.t when r

Exclusive co-selectionA.s B.t when r

Co-executionA.s | B.t when r

Exclusive co-executionA.s | B.t when r

52

Transitivity

Co-selection• share trigger variable Ai., initially set to idle

• execute a two step transaction– Ai. := go

• execute each statement Ai.s as a reaction

• disable Ai.s

– Ai. := idle

• reenable Ai.s

53

Coordination Schemas

Complex coordination constructs are contrary the spirit of the approach (subtle and counterintuitive behaviors, termination problems)

The use of schemas is a powerful design tool that simplifies reasoning and offers built in guarantees

Sample schemas• read only sharing

• single shared variable update

• synchronized clocks

• simple co-location based sharing

• synchronized motion

54

4Formal Derivation

Factoring mobility in the derivation process Termination detection problem Sample derivation Lessons learned

55

Factoring Mobility

Refinement strategies• Specification refinement

• Program refinement– process refinement

– data refinement

• Mixed specification and program refinement Open questions

• When should mobility concerns appear in the derivation?

• Should problem specification refer to motion and space?

• How is refinement affected by the novel architecture?

• Are there mobility specific refinement steps?

56

Computing Environment

57

Sample Multi-Phased Application

Software update on the factory floor• protocol or key update

– distribute the new software• use both keys

– detect completion of the distribution

– distribute command to disable old key• disable old key

– detect completion of the distribution

58

Problem Specification

Once all hosts are idle, no host ever becomes active again System quiescence will be recorded in one distinguished

component

59

Formal Specification

stable W (S1)

claim detects W (P1)

W i : 0≤i<N :: idle[i]

60

Activation Requirement

Activation requires the existence of at least one active host

61

R1: Activation Principle

idle[i]

unless

j: j≠i :: active’[j] active[j] active[i] (S2)

Refinement Status: P1, S2

62

Token-based Accounting

Associate a token with each idle host Termination is verified by counting tokens

63

R2: Token-based Accounting

inv. T = I (S3)

claim detects T = N (P2)

T +i :: token[i]I +i : idle[i] :: 1

Refinement Status: P2, S2, S3

64

Token Consumption

Correct counting of tokens requires a token to be consumed upon each activation

65

Refinement Status: P2, S3, S4

R3: Token Consumption

idle[i] (S4)

unless

j: j≠i :: active’[j] active[j] active[i]

token(i) + token(j) = token’(i) + token’(j) – 1

token(i) + token(j) ≥ 0

66

Token Collection

Flow tokens towards a collection point Detect termination at the collection point

0

1

3

8

6

2

4

7

5

67

Refinement Status: P3, P4, S3, S4

R4: Token Collection

= k > 0 until < k (P3)

claim detects = 0 (P4)

= max i : = N token[i] > 0 :: i = +i : idle[i] :: token[i]

68

Rank Independence

Every host holiding tokens must pass them on The highest rank among hosts carrying tokens cannot increase

02

34

7

69

R5: Rank independent behavior

token[j] > 0 = N j ≠ 0 (P5)until token[j] = 0 = N

stable ≤ k (S5)

Refinement Status: P4, S3, S4, S5, P5

70

Pairwise communication

0

1

2

34

56

7

71

R6: Pairwise Communication

idle[i] (S6)unless j: j ≠ i :: active’[j] active[j] active[i] (token(i) + token(j) = token’(i) + token’(j) – 1 ≥ 0) com(i,j)

token[j] > 0 = N j ≠ 0 (P7)leads-totoken[j] = 0 = N i : i < j :: com (i,j)

token[j] > 0 = N j ≠ 0 (S7)unless token[j] = 0 = N i : i < j :: com (i,j)

Refinement Status: P4, S3, S5, S6, P7, S7

72

Contact Guarantee

A host with tokens will meet a lower ranked host, if one exists Tokens will be passed to some other host as long as the token

carying node with the highest rank does not pass tokens to a higher ranked node

02

3

4

7

02

3

74

Decentralization

Every idle node should pass tokens to a node of lower rank, not just the highest ranked token carying host

Uniform behavior eliminates the need to know who is

02

34

7

75

Refinement Status: P4, S3, S6, S7, S8, P10

R8: Decentralization

token[j] > 0 = N j ≠ 0 (S8)

unless

token[j] = 0 = N

i : i < j :: com(i,j) token[i] = token’[i] + token’[j]

claim detects token[0] = N (P10)

76

Mobile Program

Program HOST(i) at declare

token, n: integer idle, claim: booleanalways

active = idleinitially

token = 1 if idle 0 if active claim = false n = N if i=0 0 if i ≠ 0assign

idle :: idle := true if active || token:= token + 1 detect :: claim := (token = n) if i = 0 move :: := Move(i, )

end

77

Communication and Co-location

com(i,j) (host(i). = host(j).)

78

Mobile Program

System MobileSystem

Program host(i) at …

end

Components

i : 0 ≤ i < N :: host(i) at i

Interactions

Activation

Token passing

Inhibitions

end MobileSystem

79

Interactions

host(i).idle, host(i).token, host(j).token :=false,(host(i).token+host(j).token-1)/2,(host(i).token+host(j).token-1)/2

when host(i).idle host(j).active host(i). = host(j). host(i).token + host(j).token > 0

activate and redistribute tokens host(i).token, host(j).token := host(i).token + host(j).token, 0 when host(i).idle host(j).idle host(i). = host(j).

host(j).token > 0 j > ipush tokens towards lower rank

inhibit host(i).move and host(j).move when host(i).idle host(j).idle host(i). = host(j).

host(j).token > 0 j > iguarantee token passing

80

Observations

Knowledge about the number of hosts undermines the idea of open system design

Only hosts involved in the computation should participate in termination detection

A better solution relies on the notion of diffusing computations• Each host keeps track of the activated children

• When a host becomes idle a termination report is generated

• Termination reports are relayed to the root of the computation along a partial order along activated hosts

81

Lessons Learned

Formal treatment of mobility is feasible and desirable The solution accommodates both physical and logical mobility The problem definition is independent of mobility

• When do we need to address mobility from the onset? A precise definition of space was not required

• How should we exploit properties of space? Refinement order is important Late introduction of location-dependent communication simplified

the derivation• Is this always the case?

The underlying architecture greatly affects the derivation process The coordination constructs also shape the refinement process

• Can we take advantage of this?• Are tailored abstract coordination constructs useful?

Conditional properties are key to reasoning about open systems

82

Applications of Mobile UNITY

Protocol specification and verification Mobile code paradigms Coordination model semantics

5

83

Protocol Verification

Mobile IP

home

agent

foreign

agent

mobile

node

correspondent

node

agent

advertisement

84

Modeling Issues

Correctness is only w.r.t. the choice of level of abstraction• Most errors are likely to rest with unexpected interactions

Components as programs• network—collection of subnets

• mobile node, foreign agent, home agent Space as a set of subnet locations for mobile nodes and

stationary agents Coordination via shared variables

• subnet in/out queues for local and remote routing

• ether for transient wireless connectivity Packets as tuples

• types: regular, request, reply, encapsulated

85

Modeling Issues

Unicast and multicast• unicast

– sender sets ether and receiver resets it in a reaction)

• multicast– sender sets ether inside a transaction– receiver reads and disables itself– sender resets ether inside the transaction– receiver reenables itself

Network communication as internal data movement Packet loss as a random action

86

Modeling Issues

No global time, i.e., reliance on local clocks and minimal synchronization

Local actions• clock advancing• time outs (e.g., delete registration when lifetime expires)• time driven actions (e.g., inhibit timer until action is done)

Clock synchronizationA.clock synch B.clock

when condition within drift_rate (e.g., 1.01)• save the clock value• inhibit timer when constraint is violated

87

Verification Issues

Since no guarantees are provided, all properties must be conditional properties (prove C assuming H holds)

H___________________

C Assuming bounded-time delivery and processing

• Given a mobile node n in some subnet s– eventually, its registration is up to date or n moved away

– its registration is up to date or n moved away

– eventually, any message forwarded to n by its home agent arrives or n moved away

88

Code Mobility Revisited

Unit of mobility profile• data state

• control state

• bindings Code mobility paradigms

• Code on demand

• Remote evaluation

• Mobile agents

89

Relocation Modes

Weak mobility• code restarted in the initial state

Strong mobility• code and current state are relocated

• state relocation may be partial (e.g., only the data state)

• bindings add complexity to the process– remote bindings preservation

– local rebinding

– transfer of the bindings closure

90

Distributed Simulation Problem

Each process has a local simulation time The Global Virtual Time (GVT) is the global minimum The GVT controls which process proceeds next

ti = until ti = GVT =

ti = GVT = until ti >P1

P3

P2

time

91

Client Server Paradigm

Interactions: asynchronous transfer

Server.qi, Pi.Q := Pi.Q, when ServiceRequested(i)

Server.qi, Pi.Q := , Server.qi when ServiceReady(i)

Server

qi

Pi

QT

t

T

ti

T

t

92

Proof Sketch

The estimated GVT eventually converges to the correct value• inv ≤ GVT

• true leads-to = GVT where denotes Server.T

The number of recorded local clock values below the GVT will decrease to zero

Each process will eventually report the local clock value

Each report will eventually reach the server

Each reported value is eventually recorded

If no recorded local clock values are below the GVT the estimate will eventually reflect the GVT

93

Observations

Data transfer could be replaced with message passing with minimal impact on the proof• a delivery assumption would be required

There is nothing special about the proof• interactions are treated as normal statements

94

Mobile Agent Paradigm

Interactions: location-dependent read-only variable sharing

Pi.T Agent.T when Pi. = Agent.engage Agent.T

Agent.t Pi.t when Pi. = Agent.engage Pi.t

AgentPi

T

t

T

t

arrivingfromPi-1

95

Proof Sketch

The estimated GVT eventually converges to the correct value• inv ≤ GVT

• true leads-to = GVT where denotes Agent.T

The number of recorded local clock values below the GVT will decrease to zero

Each process will eventually encounter the agent and

upon engagement the local clock value is reported

Agent movement is round robin

Each report is recorded before moving on

If no recorded local clock values are below the GVT the estimate will eventually reflect the GVT

96

Observations

Data sharing schema• pair wise and unidirectional

• termination of the reactive program is guaranteed Movement schema

• round robin

• departure guarantee requires the proof of a lemma The reactive aspects of the interactions are reduced to simple

assignment augmentations• Local assignments to shared variables are logically augmented

by a second parallel assignment in the other program

• Movement actions are augmented with the engagement actions in the form of simple assignments

97

Remote Evaluation Paradigm

ServerMini

T

t[]

T

t[]

MiniPi

T

t

T

t

t

engage Server.t[]

disengage , Server.t[]

engage Server.T

98

Remote Evaluation Paradigm

Interactions:• pair wise read only variable sharing

• transitive variable sharing

• code movement

Mini. := Server. when ServiceRequested(i)

Mini. := Pi. when ServiceReady(i)

99

Proof Sketch

The number of recorded local clock values below the GVT will decrease to zero

Each process will eventually request a GVT estimate

Code carrying a local clock value below the GVT

will reach the server and the GVT estimate will be reset

The local clock report is eventually recorded

A new GVT estimate is eventually computed

100

Observations

Multiparty variable sharing• repeated engagements that reset data values may impede

progress (e.g., if T were to be reset on engagement, Mini may never depart)

• the shared variable update pattern (one at a time) guarantees termination of the reactive program

Movement schema• code movement patterns that are built into the system can be part

of the Interactions section• application level code movement may be made explicit as part of

the application programs In the absence of true dynamic code creation, code fragments

need to be reused• it is possible to create a pool of identical code fragments and use

each only once but some bound needs to be established

101

MinPi

T

t

T

t

Minj

T

t

Code on Demand Paradigm

Interactions: one time dynamic code binding

• binding request in Pi is satisfiedby moving free code Minj at thesame location

102

Observations

In the absence of true dynamic code creation problems persist regarding the need to manage a pool of code fragments

Binding schema• special constructs can be envisioned to express the book keeping

necessary to manage dynamic binding

103

Linda Coordination Model

Temporal and spatial decoupling in Linda

out

in

rd(blocked)

104

Coordination Semantics

Shared tuple space representation• single statically shared variable TS

Pattern matching operations• non-deterministic assignment (x := x’.Q)

Blocking operations• reduction to skip

105

LIME Coordination Model

Partitioned set

out

in

rd(blocked)

106

Coordination Semantics

Partitioned set• each process owns a tuple space TS

• co-located processes share the tuple spaces– engagement is modeled as union

– disengagement is modeled as partition followed by union

Co-location is based on transitive communication connectivity Semantics of basic operations are affected in a transparent

manner by changes in the scope

107

Logical and Physical Mobility

Mobile agents as programs

Mobile hosts and ad hoc networks captured by a connectivity predicate

Only tuple spaces with the same name are shared

Connectivity can abstract other considerations as well, e.g., safe distance rule

agenttuple space

host tuple space

federated tuple space

108

Transparent Tuple Migration

Tuples are augmented with current and desired location• operations can be location specific

Reactions fire in the presence of misplaced tuples when connectivity is established

109

Reactive Programming

Strong reactions are supported at host level Weak reactions are supported at federation level

registered reaction

110

Custom Coordination Models

Event subscription in ad hoc networks• Shared event tuple space for event distribution• Reaction registration and deregistration for event subscription

Service provision in ad hoc networks• Shared service registry tuple space• Pattern matching for service discovery and proxi extraction• Proxi to service transparent communication, even in the presence

of mobility Secure sharing of tuple spaces in ad hoc networks

• Tuple spaces defined by a name and a password• Tuple space names are encrypted and sharing limited to identical

encrypted names• Operations crossing host boundaries encrypted through an

interceptor pattern

111

Conclusions

Mobility challenges our way of thinking• we explore novel uses of location information and more

A solid grounding in traditional distributed computing is a prerequisite for success• we leverage off past work on formal models and algorithms

An unprecedented level of complexity demands an increasing reliance on pragmatic application of rigorous design technique• we focus on coordination models having precise semantics

Sensitivity to the market place and application demands is more important than ever• we emphasize application-driven empirical evaluation

cs.wustl.edu/mobilab/

the end