290 likes | 443 Views
Coordination middleware for decentralized applications in dynamic networks. Kurt Schelfthout, Tom Holvoet. Elevator Talk. Dynamic networks Changing composition over time Decentralized applications Application components spread over the network nodes no single component has global control
E N D
Coordination middleware for decentralized applications in dynamic networks Kurt Schelfthout, Tom Holvoet
Elevator Talk • Dynamic networks • Changing composition over time • Decentralized applications • Application components spread over the network nodes • no single component has global control • Coordination both important and difficult for application developer • Coordination support needed • Appropriate abstractions • Support abstractions through middleware
Overview • Case Study • Automatic Guided Vehicle control • Views • gather and maintain context information • Roles • setup and maintain a group of components interacting through a protocol
Description of purpose • Decentralization • Collision avoidance • Deadlock avoidance • Job assignment • Dynamic network • Mobility of AGVs • Coordination • Support a higher level of abstraction wrt “message sending” • Deal with network dynamics
Goal Statement • Develop • Abstractions for the coordination of application components • Supported by middleware • Advantages • Offers a suitable architecture to structure application • Allows reuse of common functionality • Accelerates application development
Methodology • Case-driven • Analyse case • Propose abstraction • Develop middleware • Evaluate in case study • Two iterations • Views for information gathering in mobile ad hoc networks • Roles for protocol-based coordination in mobile networks
Node Node Node Views Node
Views • Application components use • tuplespace for publishing information tuples • View for gathering information tuples • Declarative description • Which nodes? Which tuples? • E.g. ‘gather all printers within 30 meters’ • Middleware collects the tuples in the view • As network changes • As content of tuplespaces changes
Related Work • Tuplespaces-based systems • LIME: shared tuplespaces • EgoSpaces: views • TOTA: Distributed tuples • Publish/subscribe-based systems • STEAM : Location-dependent subscriptions • JEDI: moveIn and moveOut operator • Related to both • View ~ gathering of tuples from neighboring tuplespaces • View ~ subscription on events on neighboring tuplespaces
Views for collision avoidance? • Can be used as “discovery mechanism” • Detect possible overlapping hulls • But: complex coordination • Involving more than information exchange • Mutual exclusion protocol needed
Roles • Behavior of one partner in an interaction protocol • To describe object collaborations in OO • Framework design • OO related languages (EpsilonJ) • Role pattern • To describe protocols in multi-agent systems
Participant Participant Participant Roles Node Node Node Initiator Node
Roles for protocol-based interaction • Group • declaratively describes with which nodes to execute the protocol • Determines activation of roles • Middleware maintains groups of activated roles • Executing an interaction session • Group is updated as network changes
Colllision Avoidance in AGV case Start Requester Role
Colllision Avoidance in AGV case voter requester
Colllision Avoidance in AGV case voter Request(Hull) requester
Colllision Avoidance in AGV case voter Deny requester
Colllision Avoidance in AGV case Requester (waiting)
Evaluation: Views • Developed protocol to support views in a MANET • Experiments • Analytically & in a simple MANET similator • Overhead: <10% • Correctness: best-effort, very dependent on mobility of nodes • In progress: ns-2 simulations • More realistic • Comparison with related protocols • Application • Updating network stacks in an active network • E.g. dynamically adding compressor/decompressor to improve quality of service
Evaluation: Roles • Real world application: Automatic Guided Vehicle control • Role-based middleware used throughout • Collision avoidance, deadlock avoidance, job assignment,… • Gain experience • Real life testing • 2 vehicles in test setup • More vehicles in simulation • Not “just” prototype implementation
Thank you! Questions?