the cborg mobile multi agent systems an overview werner van belle karsten verelst theo d’hondt...
TRANSCRIPT
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
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
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
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
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
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
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
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
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
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
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
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
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
Name Serving/Caching
Send msg
D
B
A
ab -> Aa -> B
ba->B
Send Location Update
Migrate
54
Name Serving/Caching
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
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
65
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
66
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
67
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
68
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
69
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
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