The cborg mobile multi agent systems
This presentation is the property of its rightful owner.
Sponsored Links
1 / 103

The CBorg Mobile Multi Agent Systems PowerPoint PPT Presentation


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

The CBorg Mobile Multi Agent Systems. An Overview. Werner Van Belle Karsten Verelst Theo D’Hondt Programming Technology Lab (PROG) Departement Computer Science (DINF) Vrije Universiteit Brussel (VUB). Mobile Multi Agent Systems. Application: interconnection of agents Wide Area Network

Download Presentation

The CBorg Mobile Multi Agent Systems

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


The CBorg Mobile Multi Agent Systems

An Overview

Werner Van Belle

Karsten Verelst

Theo D’Hondt

Programming Technology Lab (PROG)

Departement Computer Science (DINF)

Vrije Universiteit Brussel (VUB)


Mobile Multi Agent Systems

  • Application: interconnection of agents

  • Wide Area Network

  • Fine grained component structure

  • Frequent migration of components


Mobile Multi Agent Systems

  • A Mobile Agent is an Active Autonomous Component

  • Able to Communicate with others

  • Able to Migrate to other ‘Agent Systems’

  • The Agent system is the “Operating System” to support these components


Overview

  • 1 -- The Agent System

    • a -- infrastructure

    • b -- the language (pico)

    • c -- communication

    • d -- migration

    • e -- concurrency management

    • f -- creation

  • 2 -- Demonstration

  • 3 -- Internals

  • 4 -- Future Work


CBorg

  • Developed at PROG

  • Goal is to implement a light weight MMAS for research purposes

  • We try to achieve as much transparency as possible

  • Features

    • location transparency

    • strong migration

  • Based upon an interpreted language Pico


CBorg

  • The Cborg appliation is the operating environment (the agent system) which runs on every participating computer.

  • Cborg takes care of

    • naming agents

    • routing and sending messages to agents

    • creating and destroying agents

    • executing agents concurrently

    • migrating agents


Naming/ Agent Systems

  • Every agent system has a unique hierarchical name;eg. tecra and void.tecra

  • Hierarchical interconnection between agent systems forms a mobile multi agent infrastructure


Naming/ Agents

  • Agentnames are based upon the name of the agent system and a freeform identifier. Eg:

    tecra/session1

    tecra/nameserveragent

Agent Names does NOT change

whenever an agent migrates


A CBorg Agent

  • Object Oriented

  • Own Code & Data Space

  • Single Threaded

  • Agents run concurrently

  • Can send messages to other agents

  • Can migrate to other agent systems

  • Written in PICO


Overview

  • 1 -- The Agent System

    • a -- infrastructure

    • b -- the language (pico)

    • c -- communication

    • d -- migration

    • e -- concurrency management

    • f -- creation

  • 2 -- Demonstration

  • 3 -- Internals

  • 4 -- Future Work


PICO/Standard Stuff

  • Definition

    • a:900

    • a[10]:0

    • a(a,b,c):display(a+b+c)

  • Assignment

    • a:=90

    • a[67]:=89


PICO/Eval -Apply

a:b:20

ag:read(“a+b”)

eval(ag) -> 40

f(a,b)::a+b

f(1,2) -> 3

f@[1,2] -> 3


PICO/Variable Arguments

[email protected]::

{sum:0;

for(I:1,I<=size(args), I:=I+1,

sum:=sum+args[I]);

sum}

f(1,2,3) -> 6

f@[1,2,3,4] -> 10


PICO/Call by Name

a:50

delay(f())::f

delayed:delay(display(a))

a:=600

delayed()

: 600


PICO/Objects

{ makePoi(x,y)::

{move(X,Y) :: { x := X; y := Y };

area() :: 0;

makeSqu(w) ::

{widen(W) :: w := W;

area() :: w^2;

clone() };

clone() };

Point: makePoi(0,0);

Square: Point.makeSqu(2);

Square.area() --> 4


Overview

  • 1 -- The Agent System

    • a -- infrastructure

    • b -- the language (pico)

    • c -- communication

    • d -- migration

    • e -- concurrency management

    • f -- creation

  • 2 -- Demonstration

  • 3 -- Internals

  • 4 -- Future Work


CBorg/ Communication

  • “tecra/ses1”

    a:agent(“void.tecra/disc”);

    a.calculate([[1,2],[3,4]]);

    “void.tecra/disc”

    calculate(matrix)::display(matrix)

- Automatic serialisation and deserialisation

- Transparant routering

- Connectionless


CBorg/ Callbacks

  • “tecra/ses1”

    a:agent(“void.tecra/negate”);

    a.calculate([[1,2]],agentself()) -> void

    “void.tecra/negate”

    calculate(matrix,resultto)::

    resultto.display(negate(matrix))

- Asynchronous message passing

- Queued at receiver side

- Returns always void at sender side


CBorg/ Serialisation

“tecra/ses1”

makepoint(x,y)::

{show()::display(x+”:“+y);

clone()}

a:agent(“tecra/ses2”)

p:makepoint(10,20)

a.show(p) -> 10:20

“tecra/ses2”

show(p)::p.show()

- pass objects by reference

- pass primitives by value


Overview

  • 1 -- The Agent System

    • a -- infrastructure

    • b -- the language (pico)

    • c -- communication

    • d -- migration

    • e -- concurrency management

    • f -- creation

  • 2 -- Demonstration

  • 3 -- Internals

  • 4 -- Future Work


Migration

  • Weak Migration

    • The agent can only migrate whenever the agent has stored its entire state in its objects

    • Cooperation from the agent is required

    • Code should be written in a special ‘state’-based manner


Migration

  • Strong Migration

    • At any moment an agent can migrate to another place without any special requirements towards the agent

    • The agent doesn’t need to take special precautions when executing

    • The agent doesn’t have to ‘cooperate’

    • Code mobility becomes useful


Use of Migration (I)


Use of Migration (II)


Use of Migration (III)

yahoo

1

My application

2

3

4

repository


Use of Migration (III)

yahoo

1

My application

2

3

4

repository


CBorg/ Migration

  • CBorg supports the notion of strong migration.

    agentmove(place(“void.tecra”))


CBorg/ Migration

Fac(n)::

{

if(n\\1 = 0,

agentmove(place(“tecra/ses1”)),

agentmove(place(“void.tecra/ses1”)));

if(n=1,1,n*Fac(n-1))

}


Overview

  • 1 -- The Agent System

    • a -- infrastructure

    • b -- the language (pico)

    • c -- communication

    • d -- migration

    • e -- concurrency management

    • f -- creation

  • 2 -- Demonstration

  • 3 -- Internals

  • 4 -- Future Work


CBorg/ Concurrency

  • Agent = single thread

  • Agents run concurrently

  • Agent queued incoming messages

  • Agent can synchronize with other agents and pass messages through this temporary channel

  • ** drawing plz **


CBorg/ sync (I)

  • “tecra/ses1”

    a:agent(“void.tecra/negate”);

    sync(a,100) -> 100

    “void.tecra/negate”

    a:agent(“tecra/ses1”);

    sync(a,100) -> 100

- both parties wait at the sync

- after both arriving at the sync they continue


CBorg/ sync (II)

  • “tecra/ses1”

    a:agent(“void.tecra/negate”);

    sync(a,[10,any]) -> [10,50]

    “void.tecra/negate”

    a:agent(“tecra/ses1”);

    sync(a,[any,50]) -> [10,50]

- Simple unification upon value

- keyword ‘any’ used as wildcard


Overview

  • 1 -- The Agent System

    • a -- infrastructure

    • b -- the language (pico)

    • c -- communication

    • d -- migration

    • e -- concurrency management

    • f -- creation

  • 2 -- Demonstration

  • 3 -- Internals

  • 4 -- Future Work


CBorg/ Creation/Killing

  • Interactive

  • Dynamic

    createagent(<object>,<name>)

    agentdie(agent)

>

- makes a deep copy of the <object>

- super will not be copied


CBorg/ Creation

MakeStarter(name,to)::

{go()::

for(i:1;i<=size(to);i:=i+1;

{agent:to[i];

agent.go()});

agentclone(clone(),name)}

init:MakeStarter(“I”,

[agent(“tecra/ses1”),

agent(“tecra/ses2”)])

init -> remotedict(“tecra/I”)

init.go()


Overview

  • 1 -- The Agent System

    • a -- infrastructure

    • b -- the language (pico)

    • c -- communication

    • d -- migration

    • e -- concurrency management

  • 2 -- Demonstration

  • 3 -- Internals

  • 4 -- Future Work


Demonstration

  • Examples

  • Cborg: multi threaded link

  • Cborg: single threaded link


Overview

  • 1 -- The Agent System

  • 2 -- Demonstration

  • 3 -- Internals

    • a -- Naming and Routing

    • b -- Migration

  • 4 -- Future Work


Routing Problem

  • Whenever an agent migrates its name changes

    Its name shouldn’t change butHow do we route messages ?


Forwarding

B

D

a

Forward msg

a

C

Send msg

A

b


Migrate

Send locationupdate

Forwarding

B

D

a

Forward msg

C

Send msg

a

A

b


Forwarding

  • Pro:

    • easy implemented

    • logging is easy

  • Contra:

    • communication is slowed down

    • interacting agent clusters are slow when migrated


Forwarding

  • Message send: 2T

    • time over network to reach home location

    • time over network to reach real location

  • Agent move: T + t

    • time over network to inform home location

    • time over network to migrate to new (nearby) position


Notifying Partners

E

B

a -> D

D

a

a -> D

C

Send msg

A

ba->D


Migrate

Send LocationUpdates

Notifying Partners

E

B

a -> C

D

a -> C

C

a

Send msg

A

ba->C


Notifying Partners

  • Pro:

    • doesn’t require a special architecture

    • suitable for fine grained secure systems

  • Contra:

    • impossible to know all possible communication partners

    • enormous overhead with popular agents


Notifying Partners

  • Message send: t

    • Time over network to reach (nearby) communication partner

  • Agent move: (C+1)t + [T]

    • Time needed to update all communication partners

    • Time needed to migrate to new position

    • [Time needed to update name server]


Name Serving & Routing

D

b -> Aa -> C

Fetch addr

A

C

Send msg

b

a


Send location update

Migrate

Name Serving & Routing

D

b -> Aa -> C

a

Fetch addr

A

C

Send msg

b


Name Serving & Routing

  • Pro:

    • easy implemented

    • routing mechanism is independent of naming system

  • Contra:

    • name updates are slow

    • name lookups are slow


Name Serving & routing

  • Message send: T + t

    • lookup name

    • send message

  • Agent move: T + t

    • update name

    • migrate agent


Send msg

Name Serving/Caching

D

b -> Aa -> B

A

ba->B

B

a


Send Location Update

Migrate

Name Serving/Caching

D

b -> Aa -> B

a

A

ba->B

Send msg

B


Send Location Update

Fetch addr

Migrate

Forward

Send msg

Invalid add

Name Serving/Caching

D

b -> Aa -> D

a

A

ba->B

B


Name Serving/Caching

  • Pro:

    • doesn’t require special infrastructure

    • fault tolerant

  • Contra:

    • if agents migrate frequently this solution takes too much overhead

    • we need a nameserver


Name Serving/Caching

  • Message send: t + (T+2t)m/n

    • time to send message

    • in m/n of the cases

      • update nameserver

      • forward message

      • update sender

  • Agent move: T + t

    • time to migrate agent

    • update nameserver


A.B.D:b -> E

A.B.D:b

Merging Nameserving & Routing

D

B.D

C.D

C.D:a

E.B.D

A.B.D

A.B.D:b


A.B.D:b -> E

A.B.D:b

Merging Nameserving & Routing

D

B.D

C.D

C.D:a

E.B.D

A.B.D


Merging Nameserving & Routing

  • Pro:

    • sends messages in O(t)

    • sends agents in O(t)

  • Contra:

    • requires special ‘hierarchical’ architecture


Performance Estimations

Message SendAgent Migration

Forwarding2TT + t

Notfy partnerstT + (C+1).t

NS & Cachingt + (T+2t).m/nT + t

Notfy con partt + T.n/mT + (C+1).t

NS & Routingtt


Overview

  • 1 -- The Agent System

  • 2 -- Demonstration

  • 3 -- Internals

    • a -- Naming and Routing

    • b -- Migration

  • 4 -- Future Work


Strong Migration

  • 1. Stop the execution of an agent

  • 2. Gather its ‘state’

  • 3. Remove the agent from memory

  • 4. Send its entire ‘state’

  • 5. Receive its entire state

  • 6. Create an agent

  • 7. Restore its entire state

  • 8. Start running the agent


Strong Migration

  • 1. Stop the execution of an agent

  • 2. Gather its ‘state’

  • 3. Remove the agent from memory

  • 4. Send its entire ‘state’

  • 5. Receive its entire state

  • 6. Create an agent

  • 7. Restore its entire state

  • 8. Start running the agent


Strong Migration

  • 1. Stop the execution of an agent

  • 2. Gather its ‘state’

  • 3. Remove the agent from memory

  • 4. Send its entire ‘state’

  • 5. Receive its entire state

  • 6. Create an agent

  • 7. Restore its entire state

  • 8. Start running the agent


Strong Migration

  • 1. Stop the execution of an agent

  • 2. Gather its ‘state’

  • 3. Remove the agent from memory

  • 4. Send its entire ‘state’

  • 5. Receive its entire state

  • 6. Create an agent

  • 7. Restore its entire state

  • 8. Start running the agent


Strong Migration

  • 1. Stop the execution of an agent

  • 2. Gather its ‘state’

  • 3. Remove the agent from memory

  • 4. Send its entire ‘state’

  • 5. Receive its entire state

  • 6. Create an agent

  • 7. Restore its entire state

  • 8. Start running the agent


Strong Migration

  • 1. Stop the execution of an agent

  • 2. Gather its ‘state’

  • 3. Remove the agent from memory

  • 4. Send its entire ‘state’

  • 5. Receive its entire state

  • 6. Create an agent

  • 7. Restore its entire state

  • 8. Start running the agent


Strong Migration

  • 1. Stop the execution of an agent

  • 2. Gather its ‘state’

  • 3. Remove the agent from memory

  • 4. Send its entire ‘state’

  • 5. Receive its entire state

  • 6. Create an agent

  • 7. Restore its entire state

  • 8. Start running the agent


Strong Migration

  • 1. Stop the execution of an agent

  • 2. Gather its ‘state’

  • 3. Remove the agent from memory

  • 4. Send its entire ‘state’

  • 5. Receive its entire state

  • 6. Create an agent

  • 7. Restore its entire state

  • 8. Start running the agent


Strong Migration

  • Problem: capturing the execution state of a running process.

  • State consist of

    • Data Space

    • Code Space

    • Runtime Stack & IP

    • Hidden variables in metaprocess

    • Links to Resources


MetaProcess/BaseProcessData Coupling

  • Strong coupling: hidden variables in meta-process

  • Weak coupling: no hidden variables in meta-process, except for the stack

  • No coupling: no hidden variables in meta-process

metaprocess can’t migrate baseprocess

baseprocess may want to migrate itself


1. Strong Coupling (I)

memcpy of the complete process

E.g: Binary process migration

  • Resource Acces ?

  • Data Structures hidden in the OS ?

  • Heterogeneous Environment ?


2. Strong Coupling (II)

Strong coupled process but with restricted usage. Eg: an evaluator which doesn’t use any special ’’abilities’’ of its environment.

Stack Introspection/Rebuilding

  • These stack frames are almost impossible to serialize unless we add recognizable type information

  • Capturing the instruction pointer

  • Deserializing means create a new validstack

  • Jumping to the new instruction pointer


3. Weak Coupling

Eg: Thread Migration in Java: controlled environment, even in such a way that it becomes difficult to look at your own stack.

Aspect Weaving: Add before and after every

method invocation save and restore code.

  • **tekening van die mannen in leuven **

  • Code Explosion

  • Slow

  • Doesn’t tackle the real problem, its merely a hack


Migration of strong coupled processes, even with controlled / restricted usage is a bothersome thing.


4. No Coupling

  • A snapshot of the complete execution state can be taken, just by copying/serializing everything

  • CPS transformations can be applied to an evaluator achieve this

Reification all variables including

the Runtime Stack


CBorg/ Agent Decoupling

  • No references from outside the agent to its inner workings

  • No references from inside the agent to objects in other agents.

  • A Cborg agent is only linked to the agent system with a pointer to the root environment.

  • No variables can be written in the real root environment because there exists a agent root environment

  • **drawing pleaze**


CBorg/ Agent References

  • No problem since all connections are based upon agent names. Agent names doesn’t change whenever an agent migrates so all my communication partners are still be able to reach me


CBorg/ Resources

  • Access to all resources is (should be) redirected trough non-migratable agents.

    Eg: when creating an agent by clicking on the new-agent button, two agents are created immediatelly: tecra/ses1 & tecra/ses1&ui

    ** drawing pleaze **


CBorg/ Evaluation (I)

  • 2 stacks

    • continuation stack (what do I need to do in the future)

    • expression stack (the expressions accompanying the continuations)

  • Before calling a continuation

    • the stack contains the arguments this continuation needs


CBorg/ Evaluation (II)

  • 2 stacks

    • continuation stack (what do I need to do in the future)

    • expression stack (the expressions accompanying the continuations)

  • After calling a continuation

    • the top of the stack contains the result of the continuation


CBorg/ Evaluation (III)

  • Main-loop

while(1)

{CNT:POP_CNT();

CNT.invoke()}


CBorg/ Evaluation (pre-IV)

public Object evaluate(Object exp)

{if (exp instanceof Applicable)

{Object closure=evaluate(exp.application()));

Object[] args=evalargs(exp.args());

return closure.apply(args);}

if (exp instanceof Identifier) return lookup(exp);

if (exp instanceof Integer) return exp;

...

Evaluator uses its own runtime stack to

simulate a stack for the evaluated program


CBorg/ Evaluation (IV)

  • evaluate thunk

void evaluate()

{exp=PEEK_EXP();

if (exp instanceof Integer) return;

if (exp instanceof Identifier)

{POKE_EXP(lookup(exp));

return;}

...

evaluate

EXP

EXP


CBorg/ Evaluation (IV-bis)

  • evaluate thunk

void evaluate()

...

if (exp instanceof Applicable)

{Object [] args=exp.args();

Object apl=exp.application();

POKE_EXP(apl);

PUSH_CNT(apply);

PUSH_CNT(evaluate);

PUSH_EXP(args);

PUSH_CNT(swap);

PUSH_CNT(evalargs);

}

}

evaluate

EXP

evalargs

swap

evaluate

EXP[]

apply

IDEN


CBorg/ Stack Trace

Program

Display(200+300)

evaluate

display(200+300)


CBorg/ Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


CBorg/ Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


CBorg/ Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


CBorg/ Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


CBorg/ Stack Trace

Program

Display(200+300)

swap

evaluate

[500]

apply

display


CBorg/ Stack Trace

Program

Display(200+300)

evaluate

display

apply

[500]


CBorg/ Stack Trace

Program

Display(200+300)

native #83

apply

[500]


CBorg/ Stack Trace

Program

Display(200+300)

“500”


Overview

  • 1 -- The Agent System

  • 2 -- Demonstration

  • 3 -- Internals

  • 4 -- Future Work


Future Work/ Metalevel

  • Redefining the metalevel architecture to allow the writing of glue components

    • invocation: a.<brol>()…

    • callbacks: a.calc(…)-> agentself()

    • passing continuations


Future Work/ Concurrency

  • Adding unification to the language

  • Redefining the concurrency management: CSP-like with extended sync


Future Work/ Creation

  • Creation of agents

  • Ownership of data

  • Atomic types


Cborg

http://progwww.vub.ac.be/poolresearch/cborg

[email protected]

[email protected]

[email protected]

[email protected]


The END


ProblemS


Naming/ Problems

  • Deze slides gaan wat verder in detail op de nameserver die er nu inzit en de manieren om nameclashes te vermijden en op te vangen !

  • Name clashes when an agent migrates and creates names on the other machine on behalf of the original. How to avoid name clashes ?

  • Nog in orde te brengen !!!!


Concurrency

  • Agent = single thread

  • experimented with multiple threads

  • synchronizatieprimitieven tussen agents niet intern

  • bestaande systemen: PI-calculus (synhroon, niet toepasbaar in WAN), CSP (ge moet owner zijn van ongeveer alles), actors (asynchrone send, ok in WAN, become doet concurrency management… wat scheelt er hier dan mee, wat doet dat ding in imperatieve talen ?)

  • So…. Simply added a sync primitieve


  • Login