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


  • 115 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

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

Mobile Multi Agent Systems

  • Application: interconnection of agents

  • Wide Area Network

  • Fine grained component structure

  • Frequent migration of components


Mobile multi agent systems1

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

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

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


Cborg1

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

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

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

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


Overview1

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

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

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

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

PICO/Call by Name

a:50

delay(f())::f

delayed:delay(display(a))

a:=600

delayed()

: 600


Pico objects

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


Overview2

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

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

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

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


Overview3

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

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


Migration1

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 (I)


Use of migration ii

Use of Migration (II)


Use of migration iii

Use of Migration (III)

yahoo

1

My application

2

3

4

repository


Use of migration iii1

Use of Migration (III)

yahoo

1

My application

2

3

4

repository


Cborg migration

CBorg/ Migration

  • CBorg supports the notion of strong migration.

    agentmove(place(“void.tecra”))


Cborg migration1

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))

}


Overview4

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

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

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

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


Overview5

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

CBorg/ Creation/Killing

  • Interactive

  • Dynamic

    createagent(<object>,<name>)

    agentdie(agent)

>

- makes a deep copy of the <object>

- super will not be copied


Cborg creation

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()


Overview6

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

Demonstration

  • Examples

  • Cborg: multi threaded link

  • Cborg: single threaded link


Overview7

Overview

  • 1 -- The Agent System

  • 2 -- Demonstration

  • 3 -- Internals

    • a -- Naming and Routing

    • b -- Migration

  • 4 -- Future Work


Routing problem

Routing Problem

  • Whenever an agent migrates its name changes

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


Forwarding

Forwarding

B

D

a

Forward msg

a

C

Send msg

A

b


Forwarding1

Migrate

Send locationupdate

Forwarding

B

D

a

Forward msg

C

Send msg

a

A

b


Forwarding2

Forwarding

  • Pro:

    • easy implemented

    • logging is easy

  • Contra:

    • communication is slowed down

    • interacting agent clusters are slow when migrated


Forwarding3

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

Notifying Partners

E

B

a -> D

D

a

a -> D

C

Send msg

A

ba->D


Notifying partners1

Migrate

Send LocationUpdates

Notifying Partners

E

B

a -> C

D

a -> C

C

a

Send msg

A

ba->C


Notifying partners2

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 partners3

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

Name Serving & Routing

D

b -> Aa -> C

Fetch addr

A

C

Send msg

b

a


Name serving routing1

Send location update

Migrate

Name Serving & Routing

D

b -> Aa -> C

a

Fetch addr

A

C

Send msg

b


Name serving routing2

Name Serving & Routing

  • Pro:

    • easy implemented

    • routing mechanism is independent of naming system

  • Contra:

    • name updates are slow

    • name lookups are slow


Name serving routing3

Name Serving & routing

  • Message send: T + t

    • lookup name

    • send message

  • Agent move: T + t

    • update name

    • migrate agent


Name serving caching

Send msg

Name Serving/Caching

D

b -> Aa -> B

A

ba->B

B

a


Name serving caching1

Send Location Update

Migrate

Name Serving/Caching

D

b -> Aa -> B

a

A

ba->B

Send msg

B


Name serving caching2

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 caching3

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 caching4

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


Merging nameserving routing

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


Merging nameserving routing1

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 routing2

Merging Nameserving & Routing

  • Pro:

    • sends messages in O(t)

    • sends agents in O(t)

  • Contra:

    • requires special ‘hierarchical’ architecture


Performance estimations

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


Overview8

Overview

  • 1 -- The Agent System

  • 2 -- Demonstration

  • 3 -- Internals

    • a -- Naming and Routing

    • b -- Migration

  • 4 -- Future Work


Strong migration

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 migration1

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 migration2

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 migration3

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 migration4

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 migration5

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 migration6

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 migration7

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 migration8

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 baseprocess data coupling

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

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

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

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


The cborg mobile multi agent systems

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


4 no coupling

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

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

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

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

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

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

CBorg/ Evaluation (III)

  • Main-loop

while(1)

{CNT:POP_CNT();

CNT.invoke()}


Cborg evaluation pre iv

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

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

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

CBorg/ Stack Trace

Program

Display(200+300)

evaluate

display(200+300)


Cborg stack trace1

CBorg/ Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


Cborg stack trace2

CBorg/ Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


Cborg stack trace3

CBorg/ Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


Cborg stack trace4

CBorg/ Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


Cborg stack trace5

CBorg/ Stack Trace

Program

Display(200+300)

swap

evaluate

[500]

apply

display


Cborg stack trace6

CBorg/ Stack Trace

Program

Display(200+300)

evaluate

display

apply

[500]


Cborg stack trace7

CBorg/ Stack Trace

Program

Display(200+300)

native #83

apply

[500]


Cborg stack trace8

CBorg/ Stack Trace

Program

Display(200+300)

“500”


Overview9

Overview

  • 1 -- The Agent System

  • 2 -- Demonstration

  • 3 -- Internals

  • 4 -- Future Work


Future work metalevel

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

Future Work/ Concurrency

  • Adding unification to the language

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


Future work creation

Future Work/ Creation

  • Creation of agents

  • Ownership of data

  • Atomic types


Cborg2

Cborg

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

[email protected]

[email protected]

[email protected]

[email protected]


The cborg mobile multi agent systems

The END


The cborg mobile multi agent systems

ProblemS


Naming 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

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