Cache updates in a peer to peer network of mobile agents
This presentation is the property of its rightful owner.
Sponsored Links
1 / 46

Cache Updates in a Peer-to-Peer Network of Mobile Agents PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on
  • Presentation posted in: General

Cache Updates in a Peer-to-Peer Network of Mobile Agents. Elias Leontiadis Vassilios V. Dimakopoulos Evaggelia Pitoura Department of Computer Science University of Ioannina Greece. Introduction. Multi-Agent system (MAS) Network of software agents

Download Presentation

Cache Updates in a Peer-to-Peer Network of Mobile Agents

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Cache updates in a peer to peer network of mobile agents

Cache Updates in a Peer-to-Peer Network of Mobile Agents

Elias LeontiadisVassilios V. DimakopoulosEvaggelia Pitoura

Department of Computer ScienceUniversity of IoanninaGreece


Introduction

Introduction

  • Multi-Agent system (MAS)

    • Network of software agents

    • Computational resources are distributed across this network

    • The agents cooperate to fulfill a specified task

      To do so, they need resources provided by other agents

  • Open MAS

    • No global knowledge of the agents in the system

    • Thus, agents are not aware of which agent provides a particular resource


Resource discovering in open mas

Resource discovering in open MAS

Issue

How to locate an agent that provides a particular resource

Approaches:

  • Central directory

    • There is a single agent which holds a directory, matching resources to agents

  • Middle agents

    • Some agents (middle agents) keep a fraction of the directory

  • Our approach:

    Distributed caches: each agent keeps part of the directory

    • Performance

    • Failure tolerance


Distributed cache model

Distributed cache model

Cache of a1

R4: A2

R8: A6

R1R2R3

  • Each agent maintains cache entries about k different resources of other agents

  • Cache entries: keep the contact information of one agent that provides the resource

  • The system is modeled as a directed graph G(V;E) called the cache network

  • If agent u  v, then v is a neighbor of u

a1

R4R7

a2

a3

R9

a4

a5

R1

R6

a6

R8R5R2

R1


Searching for a resource

Searching for a resource

  • We consider the following flood-based search methods

    • Plain flood

      • Forward the query to all its neighbors for a maximum number of steps (TTL: Time-To-Live)

    • Teeming

      • Propagates the search message only to a random subset of its neighbors

      • Φ the fixed probability of selecting a particularneighbor

    • Teeming with decay

      • like teeming, but the subset gets smaller as we go deeper into the tree

      • Φ = (1-d)level d < 1. d is called decay parameter

    • K-Random paths (K-walkers)

      • The agent that initiates the search selects K random neighbors

      • All the other agents forward the message to only one random neighbor

Plain flood

Teeming

2-Random paths


The problem cache network and mobility

The Problem: Cache network and mobility

  • Mobility

    • Agents may move (e.g. change IP)

    • Resources may move from one agent to another

  • Problem: when an agent A moves

    • Other agents that cached A’s resources before, now have invalid cache entries

      In fact, no one knows the new location of agent A: when it moved, it didn’t inform anyone

New location

a3

a1

a2

a3

Old location

a4

a5

a6


Cache update policies

Cache update policies

We consider the problem of cache updates in a peer-to-peer network of mobile agents

  • We propose a number of update policies that combine two basic techniques:

    • Pull-based method

      • Initiated by the agent that wants to update its cache

    • Push-based method

      • Initiated by the agent that moves.

        Since the cache entries form our overlay network, what we update is the network topology itself.


Pull based method

Pull-based method

Initiated by the agent that wants to refresh a cache entry (either periodically or on-demand when it discovers that an entry is invalid)

  • Any flood-based search algorithm can be used

    • Plain flood

    • Teeming (with decay)

    • K-Random paths

  • Pull method

    • search the network for an agent that knows the new location


Pull search example

Pull search example

Old location

Agents knows the new location

Agent that pulls

New location


Pull search example1

Pull search example


Pull search example2

Pull search example


Pull search example3

Pull search example


Pull search example4

Pull search example

Replies Directly


Pull search example5

Pull search example


Push based method

Push-based method

  • Pull cannot work alone

    When an agent moves, it must inform at least oneother agent about its new location

Push method

When an agent moves, it “pushes” a message to the network to inform other agents about its new location


Push example

Push example

Needs the update

Old location

Needs the update

Needs the update

New location


Push example1

Push example


Push example2

Push example


Push example3

Push example


Push example4

Push example


Our update policies

Our Update Policies

  • Plain Push/Pull combination with appropriate variations of flooding

  • Push with snooping directories combined with periodic pullsa novel variation of push, where agents that receive information about other moving agents maintain it for a short period of time

  • Inverted Cache with Leasingan informed push approach combined with leasing


Plain push pull method

Plain push/pull method

  • Plain push

    The moving agent does not know which agents need the update

    It blindly floods the network with messages that contain its new location.

    When an agent receives the push message: it updates its cache entries, if needed


Plain push pull method1

Plain push/pull method

  • A wide push is needed to inform a sufficient number of agents

    • Large TTL and small decay

  • An agent may not receive the update because:

    • Offline during push

    • Push messages may not reach it

      • Larger TTL and decay values needed

      • Disconnected network

  • Such agents should perform on-demand pull.


Push with snooping directories and periodic pulling

Push with snooping directories and periodic pulling

Push with snooping directories

Every agentmonitors the network and maintains a directory of recently moved agents. This directory is termed snooping directory.

  • How it works:

    • Anagent that receives a push message concerning other moving agentsstores this information in its own snooping directory

    • It does so, even if it doesn’t need this information to update its own cache.

    • Keeps it for a small period of time (expiration time)

      So, each agent remembers the new location of every recently moved agent that came to its knowledge


Push with snooping directories example

Push with snooping directories example


Push with snooping directories example1

Push with snooping directories example

Snooping dir

-a1 moved to …

Snooping dir

-a1 moved to …


Push with snooping directories example2

Push with snooping directories example

Snooping dir

-a1 moved to …

Snooping dir

-a1 moved to …

Snooping dir

-a1 moved to …

Snooping dir

-a1 moved to …

Snooping dir

-a1 moved to …

a1


Push with snooping directories and periodic pulling1

Push with snooping directories and periodic pulling

  • All agents perform periodic pulls

    Periodically, they search the network for agents in their cache that have recently moved and update the cache, if necessary

  • Why periodic pulling?

    • To take advantage of the snooping directories: if we pull after a long time, information about old moves might have already been deleted

    • Time between two subsequent pulls < expiration time of entries in the snooping directories


Push with snooping directories and periodic pulling discussion

Push with snooping directories and periodic pulling:Discussion

  • This method allows the use of narrower push/pull flooding Less message overhead

    For example:

    If agents pull periodically from their two-hop neighborhood:

    • All the nodes that are two-hop away from push-informed agents will eventually receive the update when they pull.

    • So, it is sufficient to push-inform just one agent in each two-hop neighborhood

  • We prefer to use a k-walkers algorithm for pushing

    • We spawn K-walkers and we require that all agents be two-hops away from the walk-paths at the most


Push with snooping directories

Push with snooping directories

Changed location


Inverted cache push pull

Inverted cache push/pull

  • Every agent keeps a list of the agents to which it is known, called inverted cache.

  • When the agent moves, it informs the agents found

    • in its inverted cache to update their plain cache

    • in its plain cache to update their inverted directory

  • By knowing where to send the updates

    • Avoid flooding  Low message overhead

  • Drawback: When an agent adds/replaces/deletes a resource from its cache, a message has to be sent to the resource owner.

A

B

C

A

C

B


Inverted cache push pull1

Inverted cache push/pull

Issue

Storing the entire inverted cache directory may not always be preferable, as there may exist popular agents/resources

Solution

  • Only a limited directory may be maintained

  • The inverted cache strategy can be combined with leasing

  • The agents that are not informed could use on-demand pull.


  • Inverted cache push pull leasing

    Inverted cache push/pull: Leasing

    • Every entry in the cache gets a lease time issued by the resource owner

    • After the expiration the resource owner may delete the entry from its inverted cache, without ever informing the leaser

    • We could control the size of inverted cache directory through lease times

      • Shorter lease times  smaller inverted cache directories

    Lease time

    Time interval, during which the resource owner guarantees that it will notify the leaser in case the former moves.


    Experimental results

    Experimental results

    • Evaluation using a simulator

    • Create a random graph

      • Each agent shares some resources

      • Some resources (few) are more popular than others

      • Initially, all agents have valid cache entries

    • The simulation runs for a number of turns:

      • At each turn, an agent can

        • Move

        • Search for a resource (on demand pull if necessary)

        • Make a cache replacement etc.

    • We keep statistics

      • Push/pull messages

      • Percentage of valid cache entries

      • Average directory sizes

      • Number of steps needed for the update to propagate


    Simulation

    Simulation

    • There are 1000 agents owning 3000 resources. We run the simulation for 250 turns.

    • We are mainly interested in:

      • The percentage of valid cache entries during the simulation

      • The message overhead produced by

        • Pull

        • Push

        • Cache replacements


    Plain push pull extend of flooding and percentage of valid cache entries

    Plain push/pull Extend of flooding and percentage of valid cache entries


    Plain push pull extend of flooding and message overhead

    Plain push/pullExtend of flooding and message overhead


    Cache updates in a peer to peer network of mobile agents

    Push with snooping directories and periodic pullExtend of flooding and percentage of valid cache entries


    Push with snooping directories and periodic pull extend of flooding and message overhead

    Push with snooping directoriesand periodic pullExtend of flooding and message overhead


    Plain push pull vs snooping

    Plain push/pull vs. snooping


    Inverted cache push pull with leases lease time duration and percentage of valid cache entries

    Inverted cache push/pullwith leasesLease time duration and percentage of valid cache entries


    Inverted cache push pull replace frequency and message overhead

    Inverted cache push/pullReplace frequency and message overhead


    Comparison

    Comparison

    • Plain push/pull

      • Should be used only when we do not want to use any additional memoryfor cache update methods

      • Can be used in an unreliable environment (on-demand pull)

      • Achieves satisfactory results when using wide flooding

      • High message overhead: It should be avoided when we have high mobility

    • Push with snooping directories and periodic pull

      • Achieves the same cache quality with plain push/pull but with significantly less message overhead.

      • Uses additional memory

    • Inverted cache with leasing

      • Negligible push message overhead

      • One-hop update propagation

      • Replacing a cache entry requires contacting the resource owner

        • Unsuitable for systems with high replacement ratio.

      • Directory size can become quite large for popular agents

      • Not appropriate for unreliable open MAS

        • Agents rely on each other to be updated

        • Agents must be online to maintain a valid inverted cache


    Conclusions

    Conclusions

    • We considered the problem of cache updates in a peer-to-peer network of mobile agents

      • Each agent maintains in its cache information about other agents

      • When agents move, cached entries about them become obsolete

    • We propose a number of update policies that combine

      • pull-based techniques, that are initiated by the agent that wants to update its cache

      • push-based methods, that are initiated by the agent that moves.

    • Push/pull variations

      • We propose a novel variation of push, where agents that receive information about other moving agents maintain it for a short period of time in a snooping directory

      • We propose an Informed push approach and we combine it with leasing (inverted cache)

    • Our experimental results designate

      • Snooping directory leads to the attainment of the same cache consistency compared with plain push/pull but with ten times less message overhead

      • Inverted cache method is message-cost effective but only when cache replacements are not too frequent


    Future work

    Future work

    • Mobile agents resemble mobile (wireless) nodes in ad-hoc networks:

      apply our policies to message routing and resource discovery in these networks

    • File replicas in p2p systems

      apply our policies to keep replicas consistent


    Thank you

    Thank you

    • More details

      • www.cs.uoi.gr/~ilias/dcache/


  • Login