Mobile UNITY: Reasoning about Physical and Logical Mobility

1
Mobile UNITY Reasoning about Physical and
Logical Mobility

• Gruia-Catalin Roman
• August 2002

2
Presentation Overview

• Mobile Computing
• Reasoning about Motion and Space
• Coordination in the Presence of Mobility
• Formal Derivation
• Applications of Mobile UNITY

3
Mobile Computing
1

• Technological and social trends
• Research opportunities
• Perspectives on mobility
• Research directions

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., DAgents) 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 (p-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
A Pragmatic Perspective LIME
federated tuple space

• 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

hosttuple space
mobileagent
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
2

• 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

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
• f0 g0 fN-1 lt fN
• fN gN gN-1 lt gN
• ? ?i 0 i N hi hi1 ? 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 u1 if u lt N ? fu fu1
• ? v v1 if v lt N ? gv gv1
• ? u, v u1, v1 if u lt N ? v lt N ? fu1
  gv1
• 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 lt M Ai max(A2i,
  A2i1) ?
• 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 tripleassertions over programs
• p s q where s is a statement in program P
• y k x, y 0, y1 x gt -3 ? y gt k
• Assignment axiom makes mechanical verification
  feasible
• p x exp q ? p ? qx/exp
• y k x, y 0, y1 x gt -3 ? y gt k
• y k ? 0 gt -3 ? y1 gt 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 gt k
• stable u N
• const f3 g8
• inv ? set i 0 i u fi ? ? set i 0
  i v fi ?

26
Simple Progress Properties

• Ensures relation
• p unless q ? ? ?s s in P p ? ?q s q ?
• __________________________________________________
  ______________________________________
• p ensures q
• Illustration (Program Compare)
• ? u k ensures u gt k
• ? f g ? u k lt N ensures u gt k
• 3 3 4 no statement increments u
• 3 3 4
• provable fu fu1 ? gv1 ? u k lt N
  ensures u gt k

27
Leads-to Relation

• Base case
• p 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 lt u0 ? v lt v0 ? uv k leads-to uv gt k
• where ? set i 0 i u0 fi ? ? set i
  0 i v0 fi ?

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)

Y
X
UNITY ? unique names
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 lt ?d lt 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
3

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

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, n1
• write1 bit, n 1, n1

• Receiver at ?r
• read h, n h bit, n1

Receiver.bit Sender.bit reacts-to Sender.?s
Receiver.?r inhibit writei when Sender.n gt
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 0 reacts-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 gt 0
• tic t t1
• Receiver
• read ? bit reacts-to even(t/2) ? t gt 0
• tic t t1

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.t1)? gt1
• inhibit Receiver.tic when ?(Receiver.t1) -
  Sender.t? gt1

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 variable
• A.x ? B.x when r
• Shared variable
• A.x B.x when r
• Engage clause
• engage(A.x, B.x) when r value ?
• Disengage clause
• disengage(A.x, B.x) when r value ?1,?2

50
Transitivity
X 4
Y
X
Z
4
4
4
2
2
2
4
4
4
2
2
2
X to Y
Y to X for composition
Y to Z
51
High Level Constructs

• Co-selection
• A.s ?? B.t when r
• Exclusive co-selection
• A.s ?? B.t when r
• Co-execution
• A.s ?? B.t when r
• Exclusive co-execution
• A.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
Formal Derivation
4

• 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 0iltN idlei ?

60
Activation Requirement

• Activation requires the existence of at least one
  active host

61
R1 Activation Principle

• idlei
• unless
• ??j j?i activej ? activej ? activei
  ? (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 tokeni?
• I ? ?i idlei 1?

Refinement Status P2, S2, S3
64
Token Consumption

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

65
R3 Token Consumption

• idlei (S4)
• unless
• ?? j j?i activej ? activej ? activei
  
• ? token(i) token(j) token(i) token(j)
  1
• ? token(i) token(j) 0?

Refinement Status P2, S3, S4
66
Token Collection

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

1
5
0
8
4
2
3
7
6
67
R4 Token Collection

• ? k gt 0 until ? lt k (P3)
• claim detects ? 0 (P4)
• ? ?max i ? N ? tokeni gt 0 i?
• ? ?i idlei tokeni?

Refinement Status P3, P4, S3, S4
68
Rank Independence

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

7
0
2
3
4
69
R5 Rank independent behavior

• tokenj gt 0 ? ? N ? j ? 0
  (P5)
• until
• tokenj 0 ? ? N
• stable ? k (S5)

Refinement Status P4, S3, S4, S5, P5
70
Pairwise communication
7
0
2
3
4
6
5
1
71
R6 Pairwise Communication

• idlei (S6)
• unless
• ? ?j j ? i activej ? activej ?
  activei
• ? (token(i) token(j) token(i) token(j)
  1 0) ? com(i,j) ?
• tokenj gt 0 ? ? N ? j ? 0 (P7)
• leads-to
• tokenj 0 ? ? N ? ? ?i i lt j com (i,j)
  ?
• tokenj gt 0 ? ? N ? j ? 0 (S7)
• unless
• tokenj 0 ? ? N ? ? ?i i lt 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

7
0
2
4
3
0
2
3
73
R7 Contact Guarantee

• tokenj gt 0 ? ? N (P8)
• leads-to
• tokenj gt 0 ? ? N ? ? ?i i lt j com(i,j)
  ?
• tokenj gt 0 ? ? N ? ? ?i i lt j com(i,j)
  ? (P9)
• leads-to
• tokenj 0 ? ? N ? ? ?i i lt j com(i,j) ?

Refinement Status S3, P4, S5, S6, S7, P8, P9
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

7
0
2
3
4
75
R8 Decentralization

• tokenj gt 0 ? ? N ? j ? 0 (S8)
• unless
• tokenj 0 ? ? N
• ? ? ?i i lt j com(i,j) ? tokeni
  tokeni tokenj ?
• claim detects token0 N (P10)

Refinement Status P4, S3, S6, S7, S8, P10
76
Mobile Program

• Program HOST(i) at ?
• declare
• token, n integer
• ? idle, claim boolean
• always
• active ?idle
• initially
• token 1 if idle ? 0 if active
• ? claim false
• ? n N if i0 ? 0 if i ? 0
• assign
• 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 lt 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).tokenhost(j).token-1)/2?,
• ?(host(i).tokenhost(j).token-1)/2?
• when host(i).idle ? host(j).active ?
  host(i).? host(j).? ? host(i).token
  host(j).token gt 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 gt 0 ? j gt i
• push 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 gt 0 ? j gt i
• guarantee 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
5

• Protocol specification and verification
• Mobile code paradigms
• Coordination model semantics

83
Protocol Verification

• Mobile IP

correspondent node
home agent
agent advertisement
foreign agent
mobile node
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
• networkcollection 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 synchronization
• A.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 gt?

P1
P2
P3
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)

t
t
ti
qi
Q
T
T
Pi
T
Server
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

arrivingfromPi-1
t
t
T
T
Agent
Pi
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
t
t
T
T
Mini
Pi
engage Server.t disengage ?, Server.t
t
t
t
T
T
engage Server.T
Server
Mini
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
Code on Demand Paradigm

• Interactions one time dynamic code binding
• binding request in Pi is satisfiedby moving free
  code Minj at thesame location

t
T
Minj
t
t
T
T
Min
Pi
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

(blocked)
rd
out
in
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

(blocked)
rd
out
in
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
the end

• 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/