A Coordination Model for Ad Hoc Mobile Systems (EUROPAR 2003)

The growing success of wireless ad hoc networks and portable hardware devices presents many interesting problems to system engineers. Particular, coordination is a challenging task, since ad hoc networks are characterized by very opportunistic connections and rapidly changing topologies. This paper presents a coordination model, called PeerSpaces, designed to overcome the shortcomings of traditional coordination models when used in ad hoc networks.

Transcript

1. 1
   A Coordination Model for Ad Hoc
   Mobile Systems
   Marco Túlio Valente1, Roberto Bigonha2,
   Mariza Bigonha2, Fernando Pereira2
   1 Catholic University of Minas Gerais - Brazil
   2 Federal University of Minas Gerais - Brazil
   Euro-Par 2003
   26th - 29th August 2003, Klagenfurt, Austria
   

   View Slide

2. 2
   Motivation
    A coordination model provides a framework where the
   interaction among active agents can be expressed
   – How agents communicate and synchronize?
   – How agents find another agents?
    Coordination in mobile computing is a challeging task:
   – Network reconfigurations (“agents can move away”)
   – Disconnections (“agents can disappear and become
   inconsistent”)
   – Limited resources (“agents should be lightweighted”)
    Coordination in ad hoc networks is even more challenging:
   – Absence of fixed infrastructures (“agents should not rely
   any form of central authority”)
   

   View Slide

3. 3
   Ad hoc Networks vs Central
   Authorities
    The circles represent the
   communication range of
   nodes.
    Nodes a and b are in
   communication range, but
   node b can not find the
   service provided by a, since
   the name service is
   inaccessible.
    Nodes a and b can not
   engage in a interaction,
   although they are in
   communication range.
   can not
   lookup
   can not
   register
   name
   service
   could
   communicate
   node b
   node a
   

   View Slide

4. 4
   Outline
    Linda
    Peerspaces
    Formal Semantics
    Conclusions
   

   View Slide

5. 5
   Linda
    Based on the idea of a tuple space accessed by 3 primitives:
   – out v: inserts tuple v in the tuple space
   – in v,x: removes a tuple that matches v and binds it to x
   – rd v,x: non-destructive version of in.
   <
   in  Printer, String?  out  Printer, aramis   Printer , aramis 
   

   View Slide

6. 6
   Linda in Ad hoc Networks
    Pros:
   – Communication is uncoupled in time and space
   – Communication is associative
    Cons:
   Tuple space is a global and centralized structure
   
   Participants should know its location and have continuous
   access to it
   
   Communication is not opportunistic
   

   View Slide

7. 7
   PeerSpaces
    As in Linda, processes can insert (out), remove (in) and read
   tuples (rd) from tuple spaces
    However, Peerspaces is based on a peer-to-peer architecture
   – Linda implementations are client/server
    PeerSpaces: each (mobile) node has its own tuple space
    Tuple space is used to:
   – Coordination among local and remote processes
   – Advertise services. Example:
   – Store results of service lookups. Example:
   

   View Slide

8. 8
   PeerSpaces: Main Concepts
    Node:
   – Mobile device equipped with a tuple space
    Service:
   – Any entity that can be useful to other nodes
   – They are advertised by a tuple inserted in local tuple space
    Group:
   – Set of nodes. Groups have a name and can contain
   subgroups, creatinga tree structure
    Network:
   – Set of nodes. Connectivity among nodes is transient
   

   View Slide

9. 9
   PeerSpaces: Main Primitives
    Local primitives:
   – From Linda : out v, in v,x e rd v,x
    Remote Primitives:
   – Operate in the remote space of a well-known node h:
   – out h,v, in h,v,x e rd h,v,x
    Service Lookup:
   – How to find the location h of a service in the network?
   – Using: find g,p
   – Queries hosts in group g for tuples matching service p
   – Macthing tuples are inserted in the local space of the host
   that has issued the operation
   

   View Slide

10. 10
    Formal Semantics
     Based on the asynchronous -calculus:
     Main departure from the -calculus:
    – Communication using tuple spaces (and not channels)
     As usual in the -calculus, operational semantics is defined in
    terms of reductions:
    N, E, X  N’, E’, X’ Computation
    N, E, X  N’, E’, X’ Structural Congruence
    E  E’ Network reconfigurations
    

    View Slide

11. 11
    Computation
     Computation:
    N, E, X  N’, E’, X’
     N is an ad hoc network defined by:
    H 1
    | H 2
    | ...... | Hn
     Hi
    is a mobile node defined by:
    hi
    [ Pi
    ,Ti
    ], where hi
    is the host name, P is the process
    running in the host and T is its local tuple space
     E is the connectivity map ot the network
    E: H x H, where H is a set of host names
     X is a set of global names
    

    View Slide

12. 12
    Local Primitives
     Local primitives change the state of the local tuple space
     Reductions specify the state of the tuple space before and
    after each operation
    ´
    if
    ,
    ,
    |
    ]
    ´
    ,
    |
    }
    ´/
    {
    [
    ,
    ,
    |
    ]
    ´
    ,
    |
    .
    ,
    [
    ´
    if
    ,
    ,
    |
    ]
    ,
    |
    }
    ´/
    {
    [
    ,
    ,
    |
    ]
    ´
    ,
    |
    .
    ,
    [
    ,
    ,
    |
    ]
    ,
    [
    ,
    ,
    |
    ]
    ,
    |
    [
    v
    v
    X
    E
    N
    T
    v
    Q
    x
    v
    P
    h
    X
    E
    N
    T
    v
    Q
    P
    x
    v
    rd
    h
    v
    v
    X
    E
    N
    T
    Q
    x
    v
    P
    h
    X
    E
    N
    T
    v
    Q
    P
    x
    v
    in
    h
    X
    E
    N
    T
    v
    P
    h
    X
    E
    N
    T
    P
    v
    out
    h
    
    
    
    
    
    
    
    
    
    

    View Slide

13. 13
    Find
     Operation find g,p issued by host h:
     A service lookup tuple is inserted in the local space:
    –
     Tuple is propagated is propagated to connected nodes
     When tuple reachs a node of group g, a process is created in
    this node:
    – !(rd p,x. out h, x)
     Process continuously reads matching tuples and send the
    results to the local space of host h
    

    View Slide

14. 14
    Remote Primitives
     Remote output (out h’,v ) is a two step operation:
    – 1st step: tuple is inserted in the local space
    – 2nd step: tuple is moved to its final destination h’ as soon
    as h’ is connected
     Operations in h’,p, x and rd h’,p,x:
    – Semantics is described using mobile processes
    – Process moves to h’, performs the operation and returns
    with the result
    

    View Slide

15. 15
    Structural Congruence
     N, E, X  N’, E’, X’
     Rules define how processes can be syntactically rearranged
    in order to trigger reductions
     Example: h [!(in v.P), T] | N, E, X
    – Does not match in reduction
     Structural congruence rules:
    !P  P | !P
    P  Q  h [P, T]  h [Q,T]
     Thus, h [!(in v.P), T] | N, E, X  h [in v.P | !(in v.P), T] | N, E, X
    

    View Slide

16. 16
    Reconfiguration
     Network reconfiguration:
    ´
    ´,
    ´,
    ,
    ,
    ´
    X
    E
    N
    X
    E
    N
    E
    E
    
    
     Reconfigurations should be propagated to the configuration
     Reconfiguration rules are left unspecified since they depend
    on the subjacent network
    

    View Slide

17. 17
    Related Work
     Linda implementations (IBM TSpaces, Sun JavaSpaces etc):
    – Client/server architecture
    – Assume a tight coupling between client and servers
     Jini: extension of Java RMI for “spontaneous networks”
    – Assume the existence of a centralized lookup server
     Lime: Linda for Mobile Environments
    – Transiently shared tuple spaces
    – Kernel creates the abstraction of a global and virtual space
    – Amount of global synchronization required to keep the
    consistency of the global space in presence of changes
    

    View Slide

18. 18
    Status of the PeerSpaces Project
     Formal semantics in -calculus
     Prototype implementation in Java
    – Ad hoc network is simulated by objects distributed in a
    fixed network
     PeerSpaces simulator
    – Provides support for prototyping and evaluating distributed
    applications built with PeerSpaces
    

    View Slide

19. 19
    Conclusions
     We have presented and formalized PeerSpaces:
     Semantics have two purposes:
    – Provides solid foundation for PeerSpaces implementations
    – Supports formal reasonig about PeerSpaces applications
     PeerSpaces overcome the main shortcomings of shared
    spaces coordination models when used in ad hoc networks:
    – The strict reliance on the traditional client/server model
     PeerSpaces preserves the main strengths of such models:
    – The asynchronous and uncoupled style of communication.
    

    View Slide