Active Coordination in Ad Hoc Networks

Christine Julien Gruia-Catalin Roman

Mobile Computing LaboratoryWashington University in Saint Louis

2

Ad Hoc Networks

• Form opportunistically • Change rapidly in response to

mobility• Rely on no fixed infrastructure• Provide transient interactions• Foster decoupled computing

3

Computational Model• Ad hoc network• Host (mobile or stationary)

• Defines location in physical space• Agents/Application Components

• Unit of mobility residing on a host• Data

• Owned and generated by each agent

Host 1

Host 2

Host 3

4

Context-Awareness

• Software and hardware components constantly move and change

• Applications must opportunistically adapt• Context scope extends beyond the local host

• Perception of context varies by application• Application specific context definition• Asymmetric context interaction• Multiple contexts evolving over time

5

Example Application

6

EgoSpaces Middleware

• Presents coordination model for easing application development

• Facilitates asymmetric coordination• Allows applications to flexibly interact

with the environment• Based on tuple spaces

• Provides high-level abstractions of ad hoc network environment

7

The View Construct• Maximal context contains all available data• A view is a projection of the maximal context

• Egocentric abstraction of operating context• Tailored to an application’s individual needs

• Allow agent to control scope of views• Ease program development• Minimize performance penalties

Host 1

Host 2

Host 3

Reference agent’s view: yellow data within one

hop

8

Programming in EgoSpaces

• Application provides declarative view specifications

• EgoSpaces builds and maintains views

• Facilitates application’s interactions with views• Presents application with local-like data structure

Application

EgoSpaces

Network Support

9

Interacting with Context• Present view contents

as tuple space• Use Linda-like

operations• Content-based pattern

matching • retrieve tuples (rd)• remove tuples (in)

• Can affect overlapping views

• Atomic blocking, atomic probing, and scattered probing operations

1

3

2

4

rdgp(pattern)

match

5

10

Model Limitations

• Lacks natural adaptation mechanisms• Provides only polling operations• Allows interaction only with the system state

• Requires explicit interaction with individual data items• Difficult to specify behaviors that affect

general classes of data

• Does not cater to variations in programmer expertise

11

Reacting to Context

• Facilitate behavioral adaptation• Agents respond to

presence of certain tuple

• Application responds by removing or changing the tuple

Reactive view

FCreact

change

=react to p [remove] [and out modifiers()]

12

Transactional Programming

• Atomic sequence of operations over a set of views• Intermediate results are not visible• Requires locking all view participants• Cannot include blocking operations

• Reference agent provides view restriction• Makes a deadlock-free implementation

possibleT=transaction over v1, v2, … begin op1, op2, … end

13

Augmented Reactions• Extended reaction

• Local trigger• Reaction and

transaction are atomic

• Followed reaction• Remote trigger• Trigger, removal, and

notification are atomic• Transaction is a

separate step

Reactive view

TA

react

=react to p [remove] [and out modifiers()] followed by T()

TTinpg

out

14

Active Coordination

• Applications benefit from high-level coordination with context• Active views capture natural context interactions• Apply lessons learned in other coordination

middleware while accounting for ad hoc networks

• Reference agents attach behaviors to views• Encountering specified conditions triggers an

automatic response

• Generality and extensibility

15

Active Coordination:

Data Migration• Replica management

is impractical• Transparently collect

certain data• Without explicitly

reading each data item

• Migration automatically collects matching data• Responds to changes

in the view

Migration view

workorder

migrate

workorder

M=migrate p [modifiers()]

16

Active Coordination:

Data Duplication• Data availability is

often more important than consistency

• Duplicate certain data items• Duplicates available

upon disconnection• Originals are

unaffected

Duplication view

1

2

3

4

23duplicate

D=duplicate p [modifiers()]

5

17

Active Coordination:

Event Capture• Response to events

instead of state• e.g., agent/host arrival,

data access

• Special event generation mechanism• Multiple registrations for

same event

• Transaction specifies event’s callback

Event view

inspectorarrivedevent

!!

E=event p followed by Te()

18

Consistency Concerns

• Transactional semantics• Strong application guarantees• Can be expensive

• Can be guaranteed using special protocols

• Eager scheduling modality

• “Best-effort” semantics• Allow more flexible implementation• Increase performance• Lazy scheduling modality

19

Simplifying Programming• Programming abstractions

• Reduce programmer error• Tailored to common needs of real applications

• Reduced programming effort• Desirable changes in semantics

= [structural data on this floor]p = …pattern of data to collect…seenTuples = new Vector()while(true) sleep(time) data[] = .rdgp(p) if data null for i=1 to data.length data[i].newID() out(data[i]) seenTuples.add(data[i])

= [structural data on this floor]p = …pattern of data to collect…d = new Duplicate(p).enable(d, eager)

20

Conclusions

• Coordination middleware must address constraints of ad hoc networks• Allow adaptation to changing context• Tailor context provision to applications’ needs

• Programming abstractions must satisfy application developers’ requirements• Reactive and active constructs provide high-level

coordination in EgoSpaces

• Required middleware support should be minimized• EgoSpaces’ view abstraction defines context• Behaviors are reducible to reactive construct

21

Thank You

• For more information:• http://www.cse.wustl.edu/mobilab