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

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.

13beaa3b7239eca3319d54c6a9f3a85a?s=128

ASERG, DCC, UFMG

August 26, 2003
Tweet

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
  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”)
  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
  4. 4 Outline  Linda  Peerspaces  Formal Semantics 

    Conclusions
  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 
  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
  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: <printer, laser, 2nd floor> – Store results of service lookups. Example: <printer, ?, ?>
  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
  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
  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
  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
  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         
  13. 13 Find  Operation find g,p issued by host h:

     A service lookup tuple is inserted in the local space: – <k,g,p,h>  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
  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
  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
  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
  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
  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
  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.