the cborg mobile multi agent systems an overview werner van belle karsten verelst theo d’hondt...

The CBorg Mobile Multi Agent Systems

An Overview

Werner Van BelleKarsten Verelst

Theo D’Hondt

Programming Technology Lab (PROG)Departement Computer Science (DINF)

Vrije Universiteit Brussel (VUB)

2

Mobile Multi Agent Systems Application: interconnection of

agents Wide Area Network Fine grained component structure Frequent migration of components

3

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

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

5

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

6

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

7

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

8

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

9

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

10




11

PICO/Standard Stuff Definition

a:900 a[10]:0 a(a,b,c):display(a+b+c)

Assignment a:=90 a[67]:=89

12

PICO/Eval -Apply

a:b:20ag:read(“a+b”)eval(ag) -> 40

f(a,b)::a+bf(1,2) -> 3f@[1,2] -> 3

13

PICO/Variable Argumentsf@args::

{sum:0;for(I:1,I<=size(args), I:=I+1,

sum:=sum+args[I]);sum}

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

14

PICO/Call by Namea:50delay(f())::f

delayed:delay(display(a))a:=600delayed()

: 600

15

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

16




17

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

18

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

19

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

20




21

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

22

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

23

Use of Migration (I)

Agent systeem Agent systeem Agent systeem

Agents

Positiebeheer Positiebeheer Positiebeheer

24

Use of Migration (II)

Agent systeem Agent systeem Agent systeem

Meta Agents

Agents

25

Use of Migration (III)

1

2

3

4

yahoo

My application

repository

26

Use of Migration (III)

1

2

34

yahoo

My application

repository

27

CBorg/ Migration CBorg supports the notion of strong

migration.

agentmove(place(“void.tecra”))

28

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

29




30

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

31

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

32

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

33




34

CBorg/ Creation/Killing Interactive Dynamic

createagent(<object>,<name>) agentdie(agent)

>

- makes a deep copy of the <object>- super will not be copied

35

CBorg/ CreationMakeStarter(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()

36


• a -- infrastructure• b -- the language (pico)• c -- communication• d -- migration• e -- concurrency management


37

Demonstration Examples Cborg: multi threaded link Cborg: single threaded link

38

Overview 1 -- The Agent System 2 -- Demonstration 3 -- Internals

• a -- Naming and Routing• b -- Migration

4 -- Future Work

39

Routing Problem Whenever an agent migrates its

name changes

Its name shouldn’t change but

How do we route messages ?

40

Forwarding

Forward msg

Send msg

DB

C

A

aa

b

41

Forwarding

Forward msg

Send msg

MigrateSend locationupdate

DB

C

A

a

a

b

42

Forwarding Pro:

easy implemented logging is easy

Contra: communication is slowed down interacting agent clusters are slow

when migrated

43

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

44

Notifying Partners

Send msg

DB

C

A

aa -> D

ba->D

Ea -> D

45

Notifying Partners

Send msg

Migrate

Send LocationUpdates

DB

C

Aa

a -> C

ba->C

Ea -> C

46

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

47

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]

48

Name Serving & Routing

Send msg

Fetch addr

D

CA

a

b -> Aa -> C

b

49

Name Serving & Routing

Send msg

Fetch addr Migrate

Send location update

D

CA

ab -> Aa -> C

b

50

Name Serving & Routing Pro:

easy implemented routing mechanism is independent of

naming system Contra:

name updates are slow name lookups are slow

51

Name Serving & routing Message send: T + t

lookup name send message

Agent move: T + t update name migrate agent

52

Name Serving/Caching

Send msg

D

B

A

b -> Aa -> B

ba->B

a

53


Send msg

D

B

A

ab -> Aa -> B

ba->B

Send Location Update

Migrate

54


Send msg

Send Location Update

D

B

A

ab -> Aa -> D

ba->B

MigrateFetch addr

Forward

Invalid add

55

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

56

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

57

Merging Nameserving & RoutingD

B.D

C.D

A.B.D

A.B.D:b

E.B.DC.D:a

A.B.D:b -> E

A.B.D:b

58

Merging Nameserving & RoutingD

B.D

C.D

A.B.D E.B.DC.D:a

A.B.D:b -> E

A.B.D:b

59

Merging Nameserving & Routing

Pro: sends messages in O(t) sends agents in O(t)

Contra: requires special ‘hierarchical’

architecture

60

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

61

Overview 1 -- The Agent System 2 -- Demonstration 3 -- Internals

• a -- Naming and Routing• b -- Migration

4 -- Future Work

62

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

63

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

64


65


66


67


68


69


70

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

71

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

72

1. Strong Coupling (I)

E.g: Binary process migration

Resource Acces ? Data Structures hidden in the OS ? Heterogeneous Environment ?

memcpy of the complete process

73

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 valid stack• Jumping to the new instruction pointer

74

3. Weak CouplingEg: 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

75

Migration of strong coupled processes, even

with controlled / restricted usage is a bothersome thing.

76

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

77

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

78

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

79

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

80

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

81

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

82

CBorg/ Evaluation (III) Main-loop

while(1) {CNT:POP_CNT(); CNT.invoke()}

83

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

84

CBorg/ Evaluation (IV)

evaluate EXP

EXP

evaluate thunk

void evaluate() {exp=PEEK_EXP(); if (exp instanceof Integer) return; if (exp instanceof Identifier) {POKE_EXP(lookup(exp)); return;}...

85

CBorg/ Evaluation (IV-bis)

evaluate EXP

evaluate thunkvoid 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); } }

applyevaluate

evalargs

IDENEXP[]

swap

86

CBorg/ Stack Trace

Program

Display(200+300)

evaluate display(200+300)

87

CBorg/ Stack Trace

Program

Display(200+300)

apply display

evaluate [200+300]

swap

evalargs

88

CBorg/ Stack Trace

Program

Display(200+300)

apply display

evaluate [200+300]

swap

evalargs

89

CBorg/ Stack Trace

Program

Display(200+300)

apply display

evaluate [200+300]

swap

evalargs

90

CBorg/ Stack Trace

Program

Display(200+300)

apply display

evaluate [200+300]

swap

evalargs

91

CBorg/ Stack Trace

Program

Display(200+300)

apply display

evaluate [500]

swap

92

CBorg/ Stack Trace

Program

Display(200+300)

apply

evaluate

[500]

display

93

CBorg/ Stack Trace

Program

Display(200+300)

apply [500]

native #83

94

CBorg/ Stack Trace

Program

Display(200+300)

“500”

95

Overview 1 -- The Agent System 2 -- Demonstration 3 -- Internals 4 -- Future Work

96

Future Work/ Metalevel Redefining the metalevel

architecture to allow the writing of glue components invocation: a.<brol>()… callbacks: a.calc(…)-> agentself() passing continuations

97

Future Work/ Concurrency Adding unification to the language Redefining the concurrency

management: CSP-like with extended sync

98

Future Work/ Creation Creation of agents Ownership of data Atomic types

99

Cborg

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

[email protected]@vub.ac.be

[email protected]@vub.ac.be

100

The ENDThe END

101

ProblemSProblemS

102

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

103

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

the cborg mobile multi agent systems an overview werner van belle karsten verelst theo d’hondt...

Documents

agent systema

agent systemsthe agent

agent systemswritten

cborg callbackstecrases1a

cborg communicationtecrases1a

w area

language picoc

cborgthe cborg appliation