The cborg mobile multi agent systems
Download
1 / 103

The CBorg Mobile Multi Agent Systems - PowerPoint PPT Presentation


  • 148 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The CBorg Mobile Multi Agent Systems' - kiona


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

[email protected][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

[email protected][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 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 Send Agent Migration

Forwarding 2T T + t

Notfy partners t T + (C+1).t

NS & Caching t + (T+2t).m/n T + t

Notfy con part t + T.n/m T + (C+1).t

NS & Routing t t


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


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


4 no coupling
4. No Coupling / restricted usage is a bothersome thing.

  • 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/ / restricted usage is a bothersome thing.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/ / restricted usage is a bothersome thing.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/ / restricted usage is a bothersome thing.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/ / restricted usage is a bothersome thing.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/ / restricted usage is a bothersome thing.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/ / restricted usage is a bothersome thing.Evaluation (III)

  • Main-loop

while(1)

{CNT:POP_CNT();

CNT.invoke()}


Cborg evaluation pre iv
CBorg/ / restricted usage is a bothersome thing.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/ / restricted usage is a bothersome thing.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/ / restricted usage is a bothersome thing.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/ / restricted usage is a bothersome thing.Stack Trace

Program

Display(200+300)

evaluate

display(200+300)


Cborg stack trace1
CBorg/ / restricted usage is a bothersome thing.Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


Cborg stack trace2
CBorg/ / restricted usage is a bothersome thing.Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


Cborg stack trace3
CBorg/ / restricted usage is a bothersome thing.Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


Cborg stack trace4
CBorg/ / restricted usage is a bothersome thing.Stack Trace

Program

Display(200+300)

evalargs

swap

evaluate

[200+300]

apply

display


Cborg stack trace5
CBorg/ / restricted usage is a bothersome thing.Stack Trace

Program

Display(200+300)

swap

evaluate

[500]

apply

display


Cborg stack trace6
CBorg/ / restricted usage is a bothersome thing.Stack Trace

Program

Display(200+300)

evaluate

display

apply

[500]


Cborg stack trace7
CBorg/ / restricted usage is a bothersome thing.Stack Trace

Program

Display(200+300)

native #83

apply

[500]


Cborg stack trace8
CBorg/ / restricted usage is a bothersome thing.Stack Trace

Program

Display(200+300)

“500”


Overview9
Overview / restricted usage is a bothersome thing.

  • 1 -- The Agent System

  • 2 -- Demonstration

  • 3 -- Internals

  • 4 -- Future Work


Future work metalevel
Future Work/ / restricted usage is a bothersome thing.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/ / restricted usage is a bothersome thing.Concurrency

  • Adding unification to the language

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


Future work creation
Future Work/ / restricted usage is a bothersome thing.Creation

  • Creation of agents

  • Ownership of data

  • Atomic types


Cborg2
Cborg / restricted usage is a bothersome thing.

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

[email protected]

[email protected]

[email protected]

[email protected]


The END / restricted usage is a bothersome thing.


ProblemS / restricted usage is a bothersome thing.


Naming problems
Naming/ / restricted usage is a bothersome thing.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 / restricted usage is a bothersome thing.

  • 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


ad