Univerzita Hradec Králové Fakulta informatiky a managementu Katedra informačních technologií
Komunikace v multiagentním systému Diplomová práce
Autor: Bc. Radim Lulek Studijní obor: Informační management 2
Vedoucí práce: Ing. Pavel Čech, Ph.D.
Hradec Králové
duben 2014
Prohlášení______________________________
Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury. V Hradci Králové dne 30. 4. 2014
Radim Lulek
Poděkování_____________________________
Děkuji svému vedoucímu diplomové práce Ing. Pavlu Čechovi, Ph.D., za cenné odborné rady a připomínky, které mi poskytoval v průběhu zpracování této diplomové práce. Dále bych rád poděkoval své rodině za psychickou i finanční podporu v průběhu celého studia, svým přátelům za podporu při psaní této práce a také všem členům projektového týmu.
Anotace Diplomová práce se zabývá komunikační a transportní vrstvou distribuovaného multiagentního systému. Hlavním cílem práce je navržení komunikace mezi agenty a transportního mechanizmu, který obstarává zasílání zpráv nejen mezi agenty, ale i mezi platformami, kterým tak umožňuje jejich vzájemné synchronizování a objevování. Pro agentní komunikaci je vytvořen návrh struktury zpráv včetně všech parametrů, které by v nich měly být obsaženy. Pro realizaci zmíněného mechanizmu je navrženo několik služeb, které zajišťují zasílání, přijímání, konvertování a shromažďování zpráv. Práce poskytuje detailní rozbor navržených služeb včetně všech typů zpráv. Interakce a stavy jednotlivých komunikačních prvků systému jsou pak názorně zpracovány pomocí odpovídajících diagramů. V závěru práce je provedeno několik zátěžových testů, které slouží nejen k ověření funkcionality jednotlivých elementů, ale také k optimalizaci a zjištění možností, které systém nabízí.
Annotation Title: Communication in multi-agent system The diploma thesis deals with communication and transport layer of distributed multi-agent
system.
The
main
goal
of
the
thesis
is
to
design
a communication between agents and a transport mechanism, which caters messaging not only between agents, but also cross-platform, to which it enables mutual synchronization and discovery. Design of message structure including all parameters which should be contained in the messages is created for agent communication. Several services which ensure sending, receiving, converting and collecting messages are designed for implementation of the mentioned mechanism. The thesis provides detailed analysis of the designed services, including all types of messages. Interaction and states of individual communication elements of the system are clearly processed using the corresponding diagrams. Several stress tests, which are used not only to verify the functionality of individual elements, but also to optimize and determine the possibilities offered by the system, are made in the conclusion of the thesis.
Obsah 1
Úvod....................................................................................................................................................... 1
2
Literární rešerše ............................................................................................................................... 4
3
Metodika .............................................................................................................................................. 6
4
Analýza a návrh řešené oblasti ................................................................................................... 8
5
Návrh komunikace mezi agenty .............................................................................................. 11
6
5.1
Struktura zpráv ...................................................................................................................... 11
5.2
Parametry zpráv .................................................................................................................... 12
5.2.1
Sender a Receiver ......................................................................................................... 14
5.2.2
Konverzační ID .............................................................................................................. 14
5.2.3
Deadline zprávy............................................................................................................. 15
5.2.4
Komunikační akty ......................................................................................................... 16
5.2.5
Interakční protokoly.................................................................................................... 18
5.2.6
Jazyk obsahu zpráv ...................................................................................................... 20
5.2.7
Ontologie .......................................................................................................................... 21
Návrh transportních a komunikačních služeb ................................................................... 23 6.1
Výběr vhodného komunikačního a transportního frameworku ......................... 24
6.1.1
Ice vs ZeroMQ ................................................................................................................. 26
6.1.2
Využívané transportní protokoly v ASE a JADE ................................................ 27
6.2
Komunikační elementy v ASE ........................................................................................... 28
6.3
Rozbor typů zpráv a komunikačních prvků v ASE ................................................... 29
6.3.1
Sender a Broadcaster .................................................................................................. 29
6.3.2
Subscriber a Listener .................................................................................................. 30
6.3.3
MessageQueue ............................................................................................................... 32
6.3.4
MessageConverter ........................................................................................................ 33
6.3.5
MessageEntity ................................................................................................................ 33
6.3.6
HelloMessage.................................................................................................................. 34
6.3.7
WelcomeMessage ......................................................................................................... 34
6.3.8
SyncMessage a ByeMessage ..................................................................................... 35
6.4
Asynchronní vs synchronní způsob zasílání zpráv .................................................. 35
6.5
Interakce komunikačních prvků v systému ................................................................ 36
6.5.1
Vytváření konverzační zprávy ................................................................................. 37
6.5.2
Odesílání konverzační zprávy.................................................................................. 38
6.5.3
Přijímání konverzační zprávy .................................................................................. 39
6.5.4
Naslouchání přímých typů zpráv ........................................................................... 40
6.5.5
Nastavení nodů .............................................................................................................. 42
6.5.6
Nastavení ticků .............................................................................................................. 42
6.5.7
Získávání socketu ......................................................................................................... 42
6.5.8
Odesílání zprávy ByeMessage.................................................................................. 43
6.5.9
Odesílání zprávy SyncMessage ................................................................................ 43
6.5.10 Odesílání zprávy HelloMessage............................................................................... 43 6.5.11 Odesílání zprávy WelcomeMessage ...................................................................... 44 6.5.12 Naslouchání hromadným typům zpráv................................................................ 45 6.6 7
Rozdíly komunikačních prvků systémů JADE a ASE................................................ 47
Testování .......................................................................................................................................... 49 7.1
Test výkonu frameworků ................................................................................................... 49
7.1.1
Testování CMW.............................................................................................................. 49
7.1.2
Testování ASE ................................................................................................................ 51
7.2
Test proxy................................................................................................................................. 51
7.3
Testy postavené na BookTrading modelu ................................................................... 52
7.3.1
Test počtu vláken .......................................................................................................... 53
7.3.2
Test rychlosti načítání agentů.................................................................................. 54
7.3.3
Test doby simulace ...................................................................................................... 55
7.3.4
Test synchronizace systému .................................................................................... 56
7.3.5
Test komunikace a reportování dat....................................................................... 58
7.3.6
Test zatížení v JADE ..................................................................................................... 59
8
Shrnutí výsledků ............................................................................................................................ 60
9
Závěr a vyhodnocení .................................................................................................................... 62
10 Použitá literatura........................................................................................................................... 64 11 Přílohy ............................................................................................................................................... 71 11.1
Seznam požadavků multiagentního systému ASE ............................................... 71
12 Zadání práce .................................................................................................................................... 72
Seznam obrázků Obrázek 1: Přehled vrstev včetně jejich vlastností a funkcí v ASE ...................................... 10 Obrázek 2: Hierarchie služeb dle FIPA pro realizaci komunikace mezi agenty ............. 11 Obrázek 3: Struktura zprávy FIPA-ACL.......................................................................................... 12 Obrázek 4: Asynchronní řešení zasílání zpráv v systému JADE a ASE ............................... 36 Obrázek 5: Konzole s průběhem synchronizace dvou nodů .................................................. 57 Obrázek 6: Report získaných dat v Mongo databázi ................................................................. 58
Seznam diagramů Diagram 1: Diagram tříd zachycující rozhraní třídy komunikačních aktů ....................... 17 Diagram 2: Sekvenční diagram pro Request Interaction Protocol ...................................... 18 Diagram 3: Sekvenční diagram pro Contact Net Interaction Protocol ............................... 19 Diagram 4: Diagram tříd znázorňující content refference model ........................................ 22 Diagram 5: Diagram komponent reprezentující protokol komunikační architektury 23 Diagram 6: Stavový diagram elementu Sender ........................................................................... 30 Diagram 7: Stavový diagram elementu Listener ........................................................................ 31 Diagram 8: Stavový diagram elementu MessageQueue ........................................................... 33 Diagram 9: Sekvenční diagram vytváření konverzačního typu zprávy ............................. 38 Diagram 10: Sekvenční diagram odesílání konverzační zprávy ........................................... 39 Diagram 11: Sekvenční diagram přijímání konverzační zprávy .......................................... 40 Diagram 12: Sekvenční diagram naslouchání přímých typů zpráv ..................................... 41 Diagram 13: Sekvenční diagram získávání socketu .................................................................. 42 Diagram 14: Sekvenční diagram odesílání zprávy HelloMessage........................................ 44 Diagram 15: Sekvenční diagram posílání WelcomeMessage ................................................. 45 Diagram 16: Sekvenční diagram naslouchání hromadným typům zpráv......................... 46 Diagram 17: Diagram tříd agentů v BookTrading modelu ..................................................... 52
Seznam grafů Graf 1: Testování frameworků dle CMW týmu, klient odesílající na C++ server ........... 50 Graf 2: Testování frameworků dle CMW týmu, protokol pub-sub na C++ server ......... 50 Graf 3: Zobrazení počtu vláken v závislosti na čase .................................................................. 53 Graf 4: Rychlost načtení jednotlivých počtů agentů .................................................................. 55 Graf 5: Závislost počtu agentů na době simulace ....................................................................... 56
Seznam tabulek Tabulka 1:Parametry konverzačních zpráv ................................................................................. 13 Tabulka 2: Parametry systémových zpráv .................................................................................... 13 Tabulka 3: Nejčastěji využívané performativy zpráv ............................................................... 17 Tabulka 4: Testování frameworků ICE a ZeroMQ ...................................................................... 51 Tabulka 5: Výstup z testování vláken ............................................................................................. 53 Tabulka 6: Výstup z testování rychlosti načítání agentů ......................................................... 54 Tabulka 7: Výstup z testování doby simulace .............................................................................. 55
Seznam příloh Příloha č. 1 ................................................................................................................................................. 71
1 Úvod
Počítačové simulace jsou součástí etapy dynamického zkoumání systémů. Hlavním principem simulací je experimentování s počítačovými modely, které by měly co nejpřesněji odrážet reálný systém. Cílem simulací je nalezení takových výstupních hodnot modelu, které budou vyhovovat předem stanoveným cílům simulační studie [1]. Mezi výhody simulace patří především možnost studia a pozorování chování systému v reálném, zrychleném nebo zpomaleném čase, či možnost řešení velmi složitých systémů, které nejsou řešitelné analytickými metodami. Simulace jsou používány například v sektorech ekonomiky a podnikání, při zkoumání populační dynamiky, v systémech hromadné dopravy a v mnoha dalších oblastech [1] [2]. Speciálním druhem je tzv. multiagentní simulace, pro kterou je charakteristické využívání multiagentních systémů. Aplikováním agentního přístupu je simulaci umožněno, díky racionalitě, rozhodování a komunikaci agentů, přesněji zachytit reálný systém a také přesněji sledovat změny individuálních prvků (agentů) systému, než je tomu v případě klasických simulačních modelů [3]. Multiagentní technologie poskytují systémům výhody v podobě zrychlení a účinnosti, díky asynchronním a paralelním výpočtům, dále pak robustnost a spolehlivost, škálovatelnost, flexibilitu a možnost znuvupoužitelnosti [4]. Multiagentní systémy jsou využívány v oblastech sociálních věd, při distribuovaném dolování dat a získávání informací, ve virtuálních realitách a počítačových hrách k implementaci inteligentního chování nebo v robotice [4]. Na Fakultě informatiky a managementu Univerzity Hradec Králové probíhá již druhým rokem výzkumný projekt označovaný jako A.V.E – Artificial & Virtual Economies. Hlavní vizí tohoto projektu je, jak již z názvu vyplývá, zkoumání a vytváření simulací virtuálních ekonomik s využitím multiagentních technologií. Součástí projektu jsou dva vývojové týmy. První tým využívá prostředí AnyLogic a jeho úkolem je tvorba graficky vizualizovaného simulačního modelu, který zkoumá ekonomiku spíše na mikroekonomické úrovni. Autor práce se angažuje v týmu druhém, který je zaměřen na vytváření modelu simulujícím ekonomiku na 1
makroekonomické úrovni. K dosažení tohoto cíle je však zapotřebí zvolit vhodný nástroj,
který
bude
schopen
simulovat
počty
agentů
v řádech
statisíců.
Analýza dostupných prostředí, jako jsou JADE [5] [6], AnyLogic [7], Netlogo [8] a Flame [9], však ukazuje, že žádný ze systémů simulace takovýchto rozsahů neumožňuje. V důsledku toho bylo rozhodnuto o vývoji nového multiagentního systému nazývaného jako ASE – Agent Simulation Environment. Pro tento nový systém bylo stanoveno několik hlavních požadavků (viz příloha č. 1). Systém musí být schopen pracovat se stovkami tisíci agentů, distribuovat agenty na několik nodů a synchronizovat jednotlivé platformy. Pojem node v práci reprezentuje označení pro počítač, zatímco pojem platforma představuje označení pro container, který je vymezen pro život agentů. Vzhledem k tomu, že v systému ASE každý node obsahuje právě jednu platformu, mohou být tyto pojmy zaměňovány. Jedním z dalších hlavních požadavků systému je umožnění agentům vzájemně komunikovat. Komunikace je obecně řazena mezi základní vlastnosti multiagentních systémů a její navržení je pro systém ASE nezbytnou součástí. Tento podnět vedl autora k tomu, aby se touto problematikou blíže zabýval. Hlavním cílem práce je řešení a navržení komunikační a transportní vrstvy multiagentního distribuovaného systému. Úkolem těchto vrstev je zajištění transportu všech druhů zpráv a realizace komunikace na agentní i systémové úrovni. V rámci zvoleného cíle bude také rozebírána volba nejvhodnějšího frameworku, jehož úkolem
je
realizace
jednotlivých
komunikačních
a
transportních
služeb.
Zasílání zpráv mezi agenty slouží k vedení konverzací. V tomto případě je zapotřebí navrhnout odpovídající strukturu zpráv, tak aby zprávám porozuměly obě zúčastněné strany. Zasílání systémových zpráv naopak umožňuje synchronizování a objevování platforem. Návrh jednotlivých komunikačních elementů je přizpůsoben tak, aby vyhovoval systémovým požadavkům, zvolenému frameworku, a zároveň aby co nejvíce odpovídal agentnímu přístupu. Je zde zajištěna například autonomnost agentů při zasílání zpráv. O tom, kdy bude zpráva vytvořena a zaslána, totiž nerozhoduje systém, ale samotný agent. Práce je rozdělena na devět částí. V úvodní kapitole probíhá uvedení do zvoleného tématu a zachycení hlavních cílů, kterými se bude práce zabývat. Následující dvě kapitoly jsou věnovány použité metodice a literární rešerši. Ve čtvrté kapitole je 2
zpracována analýza a obecný návrh řešené oblasti. Kapitola pátá rozebírá návrh komunikace mezi agenty zahrnující strukturu a parametry zpráv. Šestá kapitola se zabývá návrhem transportních a komunikačních služeb. V této části je řešen výběr komunikačního a transportního frameworku. Dále jsou zde blíže rozpracovány použité komunikační elementy včetně jejich interakcí v systému, typy zpráv a způsob jejich zasílání. Sedmá kapitola se zabývá testováním systému. Poslední dvě sekce jsou pak věnovány shrnutí výsledků, závěrům a doporučením.
3
2 Literární rešerše
Multiagentní systémy jsou označovány za nové paradigma pro chápání a budování distribuovaných systémů, kde se předpokládá, že výpočetní složky systému jsou autonomní, a dokáží tak kontrolovat svá vlastní chování na základě prosazování svých vlastních cílů [10]. Multiagentní systémy v dnešní době nachází uplatnění například v oblastech simulací [11] [12] [13], v robotice [14] nebo v internetových aukcích a e-commerce [15]. Podle S.T. Leeho multiagentní systémy představují komplexní softwarový systém, který je složen z mnoha agentů, které mají lokální funkcionality a vlastnosti, a jejichž cílem je dosažení celkové systémové funkcionality [16]. Vlassis tvrdí, že oblast multiagentních systémů mísí klasické prvky, jako jsou teorie her nebo decentralizované řízení, s moderními prvky, jako je výpočetní technika nebo strojové učení [17]. D’Inverno a Luck uvádí, že multiagentní systém je jakýkoliv systém, který je tvořen ze dvou a více agentů, obsahuje minimálně jednoho autonomního agenta a zahrnuje alespoň jeden vztah dvou agentů, kde jeden uspokojuje cíle druhého [18]. Durfee a Lesser definují multiagentní systém jako volně propojenou síť řešitelů (agentů) problémů, kteří spolupracují na řešení problémů, které jsou nad rámec jejich individuálních schopností a znalostí [19]. Wooldridge uvádí definici multiagentního systému velmi obdobně. Charakterizuje ho jako systém, ve kterém agenty spolupracují, pomocí výměny informací, na vyřešení komplexních problémů určité oblasti [20]. Russel a Norvig definují agenta jako jakýkoliv prvek, který vnímá své prostředí skrze senzory a působí na něj pomocí aktuátorů [21]. Wooldridge popisuje agenta také jako počítačový systém, který je umístěn v nějakém prostředí a který je v tomto prostředí schopen autonomní akce s cílem splnit své stanovené cíle [20]. Wooldridge a Jennings uvádí definici, podle které jsou agenty objekty, které zastupují člověka a vlastní charakteristiky, jako je autonomnost, reaktivita, proaktivita a družnost [22]. Cambell a d’Inverno uvádí, že agenty jsou schopny komunikace, kterou využívají ke spolupráci a zajištění koordinace. Agent může přesvědčit jiné agenty, aby přijaly jeho 4
cíle a změnily své plány [23]. Weiss uvádí, že komunikace je přirozený způsob, pomocí kterého mohou agenty v systémech distribuované umělé inteligence vzájemně spolupracovat, což představuje jiný způsob než při náhodné spolupráci skrze prostředí. Teahan tvrdí, že mají-li být vytvořeny autonomní agenty se schopností vzájemné komunikace, je důležité nastavit soubor standardů, podle kterých bude komunikace probíhat. Tyto standardy nabízí FIPA [24] (Foundation for Intelligent Physical Agents), která je zaměřena na agentní technologie a jejich interoperabilitu s jinými technologiemi [25] [26]. McArthur a kol. uvádí, že tyto standardy našly uplatnění u mnoha vývojářů multiagentních systému [27]. V důsledku toho byla FIPA roku 2005 uznána jako oficiální standard organizace IEEE Computer Society. V rámci FIPA byl vytvořen koncept jazyka agentů nazývaného FIPA-ACL, který zároveň nahradil jeden z prvních agentních komunikačních jazyků KQML [24] [28] [29]. McArthur a kol. tvrdí, že FIPA-ACL je založena na teorii řečových aktů [27]. Weiss uvádí, že teorie řečových aktů [30], která vznikla ve filozofii, poskytuje základ pro komunikaci a je založena na myšlence, že jazyk neslouží pouze k činění prohlášení, ale také k vykonávání akcí [31]. Další oblast, která je ve FIPA-ACL řešena, jsou interakční protokoly definující sekvenčnost komunikačních aktů pro různé případy užití [5] [27] [32] [29]. Ontologie a jazyk obsahu zpráv naopak slouží k definování zpráv do takové podoby, aby jim agenty porozuměly [5] [10] [24] [27] [33] [34]. Luck a kol. uvádí ve zdroji [35] přehled multiagentních nástrojů, které se aplikováním FIPA-ACL zabývaly. Mezi tyto nástroje patří Zeus [36], JACK [37], living markets [35] a také JADE [6], který je vytvořen kompletně v souladu se všemi dostupnými FIPA standardy. Nástroj RETSINA [38] využíval naopak KQML, z kterého FIPA-ACL částečně vychází [27]. Vývoj a podstata výše zmíněných multiagentních prostředí souvisí s myšlenkou, kterou uvádí Bass. Ten tvrdí, že od roku 1990 jsou multiagentní systémy novým přístupem, jenž dominuje v agentově zaměřeném softwarovém inženýrství [39]. Wooldridge a kol. uvádí, že existuje zásadní rozpor mezi agentovým přístupem a koncepty, které jsou využívány v klasicky zaměřených paradigmatech softwarového inženýrství. Stávající techniky pro vývoj softwaru jsou pro zachycení podstaty agentního paradigmatu nevhodné [40]. Zambonelli a Omicini tvrdí, že agentní systémy mohou být považovány za nový univerzální vzor pro vývoj softwaru, který se snaží ovlivnit způsob, jakým bude softwarový systém koncipovaný a vyvinutý [41]. 5
3 Metodika
Oblasti, kterým je nutné věnovat pozornost při komplexním návrhu komunikace pro multiagentní systémy, byly analyzovány na základě zdrojů uvedených v literární rešerši. Shrnutí všech nezbytných komunikačních elementů poskytuje tzv. FIPA abstrakt architektonických specifikací [24]. Pro návrh zpráv zajišťujících komunikaci mezi agenty se vycházelo především z FIPA specifikací, které se problematikou multiagentní komunikace blíže zabývají a navrhují agentní komunikační jazyk FIPA-ACL [24]. Právě z této specifikace byla čerpána hlavní inspirace pro návrh struktury zpráv a jejich hlavních náležitostí, které by v nich měly být obsaženy. Vhodnost využití této specifikace pro navrhovaný multiagentní systém byl podložen několika dalšími zdroji [35] [36] [37], jenž tuto specifikaci ve svých multiagentních systémech také aplikují. Mimo výše zmíněné bylo využito také nástroje JADE [5], který je dle FIPA specifikací kompletně navržen. Využita byla například knihovna pro syntaxi jazyka obsahu zpráv, ontologie a s ní spojené aplikování tzv. refference content modelu a content manageru [5] [6]. Systém ASE neřeší implementaci všech parametrů, ale pouze těch, které jsou v souladu s nadefinovanými požadavky. Je požadováno, aby byla zajištěna správná funkcionalita, a zároveň aby nedocházelo k velkému zatížení aplikace. Při návrhu komunikačních prvků se vycházelo z komunikačního protokolu, který zachytává obecnou komunikační architekturu multiagentního systému [39]. Další inspirace byla čerpána ze služby MTS [5], která se stará o transportní služby v systému JADE. Návrh jednotlivých prvků a poskytovaných služeb je také přímo závislý na zvoleném komunikačním a transportním frameworku. Pro systém ASE byly testovány dva různé frameworky, ICE [42] a ZeroMQ [43]. ICE se však jevil jako nevhodná možnost, a proto byl nasazen ZeroMQ. Jednotlivé komunikační elementy tak využívají módů, které jsou tímto frameworkem poskytovány. K modelování jednotlivých elementů bylo využito specifikací modelovacího jazyka UML [44] a nástroje Enterprise Architect [45]. Pro reprezentaci samotných objektů, jejich atributů a metod bylo využito diagramů tříd. Vzhledem k řešenému tématu jsou v práci nejčastěji využívány sekvenční diagramy, které zachycují časovou posloupnost 6
interakcí objektů. Sekvenční diagramy byly v práci využity především pro znázornění interakčních protokolů a interakcí, které jsou v důsledku komunikace v systému ASE způsobeny. K zachycení stavu a životního cyklu objektů posloužily stavové diagramy. Pro zachycení již zmiňovaného komunikačního protokolu bylo využito diagramu komponent. Pro testování jednotlivých konfigurací modelu byla využita laboratoř počítačových sítí CEPSOS, která je součástí Fakulty informatiky a managementu Univerzity Hradec Králové.
7
4 Analýza a návrh řešené oblasti
Analýza komunikačních služeb probíhala především na základě předchozích zkušeností s prostředím JADE [5]. Přestože bylo toto prostředí plně založeno na agentových standardech FIPA [5] [24], nebylo pro dané účely postačující. V některých částech návrhu se však bude z těchto standardů vycházet. Nedostatky tohoto prostředí plynou především v nedostatečném výkonu a množství spuštěných agentů. Tento problém je přiznáván příliš velké centralizaci, čímž při spuštění komunikace mezi agenty dochází k velkému zatížení některých prvků. Mezi tyto prvky je řazen například tzv. Directory facilitator (DF) [5], jehož úkolem je poskytování služeb jiným agentům, registrace, deregistrace a modifikace jednotlivých služeb všech agent. JADE sice umožňoval využívání několika DF služeb, které se staraly o služby jednotlivých platforem, avšak toto řešení bylo pouze částečnou decentralizací, jelikož všechny služby byly posléze zapisovány a shromažďovány na centralizovaném místě. Kvůli centralizaci tak docházelo při spouštění většího počtu komunikujících agentů přibližně do pěti minut k přetížení. Komunikace agentů jsou totiž postaveny právě na vyhledávání daných služeb, na základě kterých mohou vést konverzace a vyjednávat s jinými agenty. V případě tohoto centralizovaného prvku však docházelo k přehlcení, protože přicházelo velké množství požadavků (počet požadavků je závislý na počtu agentů) v jednu chvíli, a služba tak nebyla schopna tyto požadavky zpracovávat. V důsledku toho docházelo k přerušením, které jsou pro běh simulace nežádoucí. Dalším důvodem přehlcení byl styl, kterým daná služba prováděla vyhledávání. Každý požadavek vyvolaný zasláním zprávy se odvolal na konkrétní DF, který na základě tzv. bílých stránek [5] vyhledával a vybíral všechny služby odpovídající hledaným parametrům. Vyhledávání tímto způsobem představuje pro systém obrovské zatížení, jelikož například každou sekundu musí DF stále projíždět celé seznamy služeb. Při návrhu budou proto tyto fakta brána v potaz a jednotlivé prvky shromažďující služby budou navrženy decentralizovaně, tak aby jednotlivé platformy při komunikaci zatěžovaly pouze sebe a žádný další centralizovaný prvek. Dále pak bude navrženo omezené vyhledávání služeb, které využívá principů omezené racionality dle Simona [46] a nekompletní informace od Hayeka [47]. Bližší rozbor proběhne v návrhové části práce. Co se týká konkrétního 8
řešení komunikačních služeb, tak JADE řeší veškerou komunikaci pomocí tzv. Message Transport Service (MTS) [5], která plně vychází ze specifikací FIPA. Jedním z dalších nedostatků, který JADE představuje a který je úzce spjat s komunikací,
je
neimplementování
synchronizačních
služeb
systému.
Pro distribuovaný systém je tato služba nezbytnou součástí. Realizace probíhá na základě komunikace resp. zasílání specifických typů globálních systémových zpráv. Práce abstrahuje od komplexního řešení synchronizačních služeb, protože se touto oblastí blíže zabývá jiný člen projektového týmu. Synchronizační služby jsou v práci rozebírány pouze na komunikační úrovni. Řešeny jsou tedy především akce a reakce, které jsou způsobeny zasíláním jednotlivých typů zpráv. Návrh systému vycházel především z proběhlé analýzy. V potaz byly brány však i všechny důležité vlastnosti, které jsou pro multiagentní systémy nadefinované v tzv. FIPA
abstraktu
architektonických
specifikací
-
standard
FIPA00001
[24].
Mezi nejdůležitější položky tohoto abstraktu, které by při návrhu neměly být opomenuty, jsou považovány následující čtyři vlastnosti. Prvním důležitým bodem je návrh zpráv sloužících ke komunikaci mezi agenty, následuje návrh transportních služeb starajících se o přijímání a zasílání všech typů zpráv. Dalším bodem je služba obstarávající sdílený informační repositář, ve kterém si mohou jednotlivé agenty vyhledávat jiné agenty. Posledním bodem je služba poskytující seznam služeb, které mohou agenty systému využívat. V této práci jsou detailně rozebírány především první dva body týkající se řešení a návrhu komunikačních a transportních služeb. Dalšími dvěma body se však práce bude také okrajově zabývat, protože jsou s komunikací velmi úzce spjaty. Komunikační prvky, které budou pro systém navrhovány, jsou ještě lépe přiblíženy v tzv. FIPA podvrstvách, které jsou sestaveny na základě klasického OSI nebo TCP/IP modelu. Mezi tyto vrstvy patří transport, kódování, řešení zpráv, ontologie, vyjádření obsahu, komunikační akty a interakční protokoly. Pro agentní komunikaci jsou využívány všechny vrstvy zachycené obrázku č. 1. Systémové zprávy, které zajišťující synchronizování a objevování platforem, využívají, s ohledem na svoji funkcionalitu, pouze vrstvy zabývající se strukturou a transportem zpráv.
9
Další důležitou součástí práce je rozbor a návrh vhodného komunikačního a transportního frameworku, který bude nejlepším způsobem realizovat všechny potřebné požadavky. Tento framework má mít v systému ASE podobnou roli jako služba MTS v JADE. Oproti MTS by však měl také poskytovat možnost synchronizace, měl by být jednodušší a co nejvýkonnější. Výběr vhodného komunikačního a transportního frameworku bude rozebírán v sekci 6.3.
Obrázek 1: Přehled vrstev včetně jejich vlastností a funkcí v ASE, vlastní tvorba
10
5 Návrh komunikace mezi agenty
V této části práce bude vysvětlen a rozebrán návrh zpráv, které slouží ke komunikaci mezi agenty. Součástí tohoto návrhu bude posledních pět vrstev zmíněných v kapitole 4. Inspirace pro návrh jednotlivých prvků zpráv byla čerpána především z FIPA specifikací [24], které se mimo jiné zabývají i agentním komunikačním jazykem označovaným jako FIPA-ACL (Agent Communicative Language) [5] [24] [29]. V rámci tohoto jazyka je definována hierarchie služeb potřebných pro uskutečnění komunikace mezi agenty (viz obrázek č. 2). Specifikace, které FIPA-ACL nabízí, byly využity u několika existujících multiagentních prostředí, jako je například Zeus [36], JACK [37], living markets [35] nebo JADE [5] [6]. Zprávy určené ke konverzacím agentů jsou označovány jako tzv. ACL zprávy [5] [24] [48]. V této práci je využíváno pojmu konverzační zpráva. Jednotlivé náležitosti, které by měla každá zpráva obsahovat, budou rozebírány v následujících podkapitolách. Součástí těchto podkapitol bude také rozbor nabízených možností řešení, způsoby využití jednotlivých řešení a odůvodnění, proč byly parametry navrženy zvoleným způsobem.
Obrázek 2: Hierarchie služeb dle FIPA pro realizaci komunikace mezi agenty [24]
5.1 Struktura zpráv Struktura zpráv v agentních systémech je rozebírána ve standardu FIPA00061 [24]. Na základě tohoto standardu byla navržena i struktura zpráv pro systém ASE (viz obrázek č. 3) Jak v systému JADE, tak v systému ASE je tato struktura charakteristická pro zprávy umožňující agentní komunikaci. Jádrem každé zprávy je tzv. content [5] [24] představující obsah, na základě kterého je agentu poskytována informace. 11
K tomuto obsahu jsou dále přiřazovány parametry, na základě kterých je daná zpráva kódována do potřebného formátu určenému k transportu. Co se týká struktury systémových synchronizačních zpráv zavedených v systému ASE, jejichž strukturu systém JADE ani FIPA specifikace neřeší, byla struktura částečně přizpůsobena dle tohoto obecného předpisu. Zásadním rozdílem je absence obsahové části (content), kterou si jednotlivé nody nemají zapotřebí předávat, protože je zajímají pouze odesílané parametry, které se také od klasické ACL (konverzační) zprávy liší. Tyto parametry jsou vždy závislé na jednotlivých typech zasílaných systémových zpráv.
Obrázek 3: Struktura zprávy FIPA-ACL
5.2 Parametry zpráv Parametry zpráv slouží k určení základních charakteristik pro každou vytvořenou zprávu. Dle FIPA specifikací je součástí každé ACL zprávy třináct parametrů. Jediným parametrem, který však musí zpráva vždy obsahovat je tzv. performativ určující typ komunikačního aktu [27]. Další parametry zpráv nejsou považovány za povinné, avšak pro lepší vedení konverzace je vhodné jich využít. Řešením parametrů zpráv se zabývá taktéž standard označení FIPA00061 [24]. Pro systém ASE bylo v souladu s tímto standardem vybráno devět parametrů, z čehož byl jeden poupraven. Z důvodu zjednodušení, urychlení průběhu a výpočtu celé simulace systému ASE nebyly další čtyři parametry zahrnuty. Jedná se především 12
o kontrolní prvky pro průběh prováděných konverzací. Ty jsou však dostatečně ošetřeny pomocí kontrolního parametru, který představuje identifikátor konverzace. Všechny parametry, které jsou součástí konverzačních typů zpráv v systému ASE, jsou přehledně zobrazeny v tabulce č. 1. Jednotlivé parametry budou v následujících kapitolách blíže rozebrány. Kromě zmíněných multiagentních prostředí v sekci 5, které
aplikují
FIPA-ACL,
je
s
využíváním
parametrů
spojen
i Trillian [49], který konkrétně využívá komunikačních aktů a protokolů. Typ parametru Type Sender Receiver Content Language Ontology Protocol Conversation-id Deadline
Význam parametru Typ komunikačního aktu zprávy. Označení odesílatele zprávy. Označení pro příjemce zprávy. Obsah zprávy. Jazyk, ve kterém je zpráva vyjádřena. Ontologie poskytující význam symbolů v obsahu zpráv. Typ interakčního protokolu určující strukturu konverzace. Identifikátor konverzace. Určuje existenci zprávy.
Tabulka 1:Parametry konverzačních zpráv, vlastní tvorba
Parametry systémových zpráv se vzhledem k jejich poupravené struktuře liší. Zasílání těchto zpráv probíhá pouze na úrovni nodů a jejich hlavním úkolem je podávat informace o stavech jednotlivých nodů. Z tohoto důvodu tyto zprávy neobsahují klasické parametry, jako jsou u konverzačních typů zpráv. Parametry, které jsou spojeny se systémovými zprávami, jsou zobrazeny v tabulce č. 2. Využívání a nastavování jednotlivých parametrů pro konkrétní typy systémových zpráv bude rozebíráno v rámci rozboru transportních služeb, které realizují přenos těchto typů zpráv (viz sekce 6.5). Typ parametru setNode setTick setAgents
Význam parametru Seznam nodů, které zprávu přijímají. Nastavení ticku daného nodu. Nastavení registrovaných agentů nodu. Tabulka 2: Parametry systémových zpráv, vlastní tvorba
13
5.2.1
Sender a Receiver
Tyto parametry označují hlavní aktéry vedených konverzací a slouží pro určení příjemce a odesílatele zpráv. Každý agent, který iniciuje vytvoření zprávy, je pro danou zprávu nastaven jako odesílatel (Sender). Parametr příjemců (Receiver) je zpravidla představován seznamem agentů splňujících konkrétní požadavky vyhledávání. Každý agent je registrován ve službě Registry, která shromažďuje všechny agenty (i z jiných platforem, ze kterých jsou získávány prostřednictvím systémových zpráv, viz sekce 6.5.10 a 6.5.11) dle jejich identifikátorů (AID) včetně jejich služeb, které poskytují. Způsob vyhledávání odpovídajících agentů, a způsob, kterým jsou jednotlivé agenty do těchto parametrů nastaveny, je v práci řešeno v sekci 6.5.1.
5.2.2
Konverzační ID
Konverzační identifikátor [5] [24] [39] zpráv je v systému ASE zaveden především jako kontrolní prvek, díky kterému je řešeno hned několik aspektů. V první řadě se stará o jednoznačné určení probíhajících konverzací, díky čemuž pak není možné reagovat na zprávy, které jsou označeny jinými konverzačními identifikátory. Identifikátor konverzace dále slouží k zaznamenávání historie všech provedených konverzací. V důsledku toho je možné zpětně dohledávat uskutečněné konverzace, což pro agenta představuje možnost opakovaného vyjednávání s agenty, s kterými byl v minulosti spokojen. O tom, zda se agent rozhodne znovu využít služeb agentů z předchozích
konverzací,
rozhoduje
jeho
konkrétní
nadefinované
chování,
momentální priority a výhodnost uskutečněné transakce. Další aspekt, který je zavedením konverzačního identifikátoru řešen, je mazání zpráv s daným ID. V případě, že je daná konverzace dokončena, je vhodné všechny ostatní zprávy s tímto ID ze systému smazat. Tím je zaručeno, že nebude docházet k pozdějšímu provedení určité transakce či pouhé konverzace s agentem, který již tuto akci dříve úspěšně dokončil. Zavedením tohoto řešení také dochází k odlehčení jednotlivých front zpráv, v důsledku čehož nebude docházet k jejich zatěžování a přetékání.
14
5.2.3
Deadline zprávy
Parametr deadlinu zpráv určuje životnost jednotlivých zpráv. Návrh funkcionality tohoto parametru je v systému ASE oproti systému JADE navržen trochu odlišným způsobem. V JADE je pro tento parametr využit název reply-by [5] [24]. Do tohoto parametru je nastavován čas, který pak určuje dobu, do které musí být na danou zprávu odpovězeno. Čas je nastavován na základě aktuálního systémového času. Ten je nastaven pomocí zavolání metody currentTimeMillis(). K této hodnotě je poté přičítána hodnota v milisekundách odpovídající deadlinu zprávy. Odesílatel po nastavení času všech svých zpráv vyčkává na odpovědi. Následně akceptuje pouze takové zprávy, na které adresované agenty zareagovaly v nastaveném limitu. Zbytek zpráv je smazán a nadále se s nimi v konverzaci nepočítá. Zavedení tohoto parametru má v obou systémech využití především pro řízení a regulaci prováděných konverzací. Jak v simulaci, tak v reálném životě není totiž praktické, aby odesílatel zpráv pokaždé čekal na všechny odpovědi po neomezenou dobu. Právě díky tomuto parametru je jednoznačně zaručeno, že odesílatel zpráv dostane pouze takovou množinu zpráv, na kterou bylo v nadefinovaném deadlinu zareagováno. V důsledku toho dochází k uvolňování jednotlivých front zpráv, čímž je redukováno jejich přetékání, a hlavně nedochází k zbytečně dlouhým čekacím lhůtám, které by vznikaly při neomezeném vyčkávání na všechny odpovědi a které by byly příčinou velkého zpomalení celé simulace. V systému ASE je první změnou v realizaci tohoto parametru přejmenování na deadline. Výraznější změny se však týkají až konkrétního návrhu tohoto parametru. Pro systém ASE je využití reálného systémového času jednotkou, kterou nelze jednoznačně vyjádřit virtuální čas, který v simulaci proběhl. Systémový čas je v tomto směru pro simulaci velice relativní. Nelze jednoduše určit, či jedna milisekunda systémového času představuje simulaci jednoho dne, týdne či měsíce. Výstupy takové simulace by pak byly pro výzkum velice zavádějící. Z tohoto důvodu je parametr deadlinu nastavován pomocí tzv. ticků, které odpovídají jednotlivým proběhlým akcím (vykonání chování, zaslání zprávy aj.) a pomocí kterých lze virtuální dobu simulace vyjádřit.
15
Konkrétní nastavení jednotlivých deadlinů zpráv bude probíhat až při optimalizaci komplexního ekonomického systému. Až v této fázi bude teprve objasněno, jaké lhůty jsou pro zprávy optimální volbou. Tato optimalizace bude nastavena tak, aby se systém zbytečně nezpomaloval dlouhým čekáním na jednotlivé zprávy a zároveň aby nedocházelo k nadměrné ztrátě zpráv.
5.2.4
Komunikační akty
Nastavení komunikačního aktu je pro zprávy nezbytně nutné, a to především z toho důvodu, že jasně určují funkci a význam jednotlivých zpráv při konverzacích v komunikaci. Tím je zajištěno jasné pochopení zprávy stejným způsobem jak pro příjemce, tak pro odesílatele. V důsledku toho jsou pak také odstraněny veškeré nejasnosti týkající se záměru odesílaných zpráv. Vzhledem k důležitosti tohoto parametru byly implementovány všechny komunikační akty, které jsou nadefinované ve FIPA specifikacích. Těmito specifikacemi se blíže zabývá standard FIPA00037 [24], který obsahuje knihovnu všech komunikačních aktů včetně jejich bližších rozborů. Všechny tyto akty jsou postaveny na tzv. Teorii řečových aktů sepsaných roku 1969 dle Searleho [30], který navázal na práci Austina, který se zabýval specifickou částí těchto aktů, tzv. performativními formulemi [50]. Pro multiagentní systémy jsou komunikační akty také označovány jako performativy. Knihovna komunikačních aktů pro multiagentní systém obsahuje celkem dvacet dva různých performativů označujících různé funkce zpráv. V následující tabulce č. 3 je zpracován výběr nejdůležitějších a nejvyužívanějších aktů včetně významů, které pro systém ASE představují.
16
Typ performativu Accept Proposal Agree Cancel Call for Proposal Failure Inform Propose Refuse Reject Proposal Request
Význam aktu Přijímá předložený návrh k provedení akce. Souhlasí s provedením nějaké akce. Informuje o tom, že již nehodlá provádět dříve požadovanou akci. Vyzývá k předložení návrhů na provedení dané akce. Informuje agenta o tom, že došlo k pokusu o provedení akce, avšak pokus byl neúspěšný. Zasílá pozitivní informativní zprávu. Předkládá návrh k provedení určité akce, na základě určitých předpokladů. Zamítá provedení dané akce a podává vysvětlení. Zamítá návrh na provedení nějaké akce během vyjednávání. Odesílá požadavek na provedení dané akce.
Tabulka 3: Nejčastěji využívané performativy zpráv, zpracováno na základě [5] [24]
Systém ASE se oproti systému JADE liší v implementaci komunikačních aktů. Pro určování performativů využívá rozhraní MessageType (viz diagram tříd č. 1). V tomto rozhraní jsou jednotlivé komunikační akty reprezentovány celočíselným datovým typem Integer, nikoliv řetězcovým typem String, jako je tomu v JADE [5]. Jednoznačným identifikátorem každého performativu tedy není jeho samotný název, ale číselné označení. Na základě tohoto označení je poté možné jednotlivým zprávám přiřazovat konkrétní typ performativu (viz sekce 6.5.1). class Design Mo... «interface» model::MessageType + + + + + + + + + + + + + + + + + + + + + +
ACCEPT_PROPOSAL: Integer {readOnly} AGREE: Integer {readOnly} CALL_FOR_PROPOSALS: Integer {readOnly} CANCEL: Integer {readOnly} CONFIRM: Integer {readOnly} DISCONFIRM: Integer {readOnly} FAILURE: Integer {readOnly} INFORM: Integer {readOnly} INFORM_IF: Integer {readOnly} INFORM_REF: Integer {readOnly} NOT_UNDERSTOOD: Integer {readOnly} PROPAGATE: Integer {readOnly} PROPOSE: Integer {readOnly} PROXY: Integer {readOnly} QUERY_IF: Integer {readOnly} QUERY_REF: Integer {readOnly} REFUSE: Integer {readOnly} REJECT_PROPOSAL: Integer {readOnly} REQUEST: Integer {readOnly} REQUEST_WHEN: Integer {readOnly} REQUEST_WHENEVER: Integer {readOnly} SUBSCRIBE: Integer {readOnly}
Diagram 1: Diagram tříd zachycující rozhraní třídy komunikačních aktů, vlastní tvorba
17
5.2.5
Interakční protokoly
Interakční protokoly [5] [29] [27] [32] jsou velmi úzce spjaty s jednotlivými komunikačními akty. Jejich hlavní funkcí je vytvořit návaznost jednotlivých komunikačních aktů pro různé případy konverzací tak, aby nedocházelo ke konfliktům v systému. Právě z tohoto důvodu je vhodná jejich implementace i do systému ASE. V rámci FIPA specifikací pro interakční protokoly [24] je předdefinováno jedenáct interakčních protokolů. Z těchto protokolů bylo pro systém ASE navrženo sedm z nich. Dva protokoly jsou totiž v experimentální fázi a nepatří mezi ověřené standardy, další dva pak v systému ASE nenajdou uplatnění z důvodu odlišné implementace, která nezahrnuje prvky potřebné k zavedení těchto protokolů. Naopak mezi stěžejní interakční protokoly, které budou v systému ASE při konverzacích nejčastěji využívány, patří protokoly Request a Contract Net [5] [24].
Diagram 2: Sekvenční diagram pro Request Interaction Protocol, zpracováno na základě [5] [24]
18
Request protokol definuje způsob řízení konverzace, která je vyvolána zasláním zprávy s performativem request na jiného agenta. Sekvenčnost komunikačních aktů obsažených
ve
zprávách
je
zachycena
na
sekvenčním
diagramu
č.
2.
Bližší specifikování a rozbor Request protokolu nabízí standard označení FIPA00026 [5] [24].
Diagram 3: Sekvenční diagram pro Contact Net Interaction Protocol, zpracováno na základě [5] [24]
Interakční protokol Contract Net (viz sekvenční diagram č. 3) je komplexnějším protokolem, který řeší sekvenčnost komunikačních aktů, na jejichž počátku se nachází perfomativ vyzývající agenty k předložení jejich nabídek. Jedná se tedy 19
o hlavní vyjednávací protokol zahrnující větší množství agentů lokalizovaných na různých platformách. V tomto protokolu si lze také povšimnout, jakou roli hraje již dříve zmiňovaný parametr určující deadline zpráv. Blížší specifikace a rozbor tohoto protokolu nabízí standard označení FIPA00029 [5] [24].
5.2.6
Jazyk obsahu zpráv
Jazyk obsahu zpráv neboli častěji využívané anglické označení „content language“ představuje další parametr zpráv [5] [24]. Tento parametr slouží k nastavení syntaxe, která slouží pro definování obsahu jednotlivých zpráv. Vzhledem k tomu, že systém ASE musí být schopen zpracovávat komunikaci na vyšší úrovni, než jen zasílání jedné primitivní hodnoty (například jen cena, název apod.), je vhodné do systému takovouto syntaxi zavést. Syntaxe určuje jasná pravidla, jak obsah zpráv formulovat, tak aby bylo zaručeno vytváření mnohem komplexnějšího obsahu zahrnujícího více informací najednou. Díky tomu, že je obsah všech zpráv vyjádřen stejnou syntaxí resp. jazykem, je zajištěna konzistence, a nemůže tak dojít k problému, že by některý z agentů obsahu zprávy neporozuměl. Pro návrh řešení jazyka obsahu zpráv pro systém ASE se nabízí několik možností. Samotná FIPA nabízí hned čtyři možnosti. Patří mezi ně Semantic Language (FIPASL), Knowledge Interchange Format (KIF), Resource Definition Framework (RDF) a Constraint Choice Language (CCL) [24]. Další možností je jazyk LEAP, který byl vytvořen speciálně pro systém JADE [5]. Vývojem nové syntaxe pro tzv. TIL-Script [51] [52], který má být alternativou jazyka FIPA-SL, se zabýval výzkumný projekt na Technické univerzitě v Ostravě. Tato syntaxe využívá Transparentní Intensionální Logiky navržené Tichým [53] [54]. Problematika jazyků je dále rozebírána ve zdrojích [10] [28] [55]. Ze všech těchto možností byl pro systém ASE vyhodnocen jako nejvhodnější standardizovaný jazyk FIPA-SL [24]. Hlavní důvod zvolení tohoto jazyka nespočíval pouze ve standardizaci, ale také například ve struktuře jazyka, která ze všech zmíněných působí nejpřehlednějším dojmem, dále pak v poskytnutí mnoha operátorů zahrnující i logické operátory, a hlavně také umožnění čitelnosti a porozumění člověkem, nikoliv pouze agentem. Tato vlastnost je užitečná především z důvodu odstraňování chyb a testování aplikace. Jedinou zvažovanou alternativou jazyka SL 20
byl již zmiňovaný TIL-Script, který se detailněji zabývá propracováním sémantiky a zpracováním přirozeného jazyka. Pro systém ASE, který je stavěn pro simulaci ekonomického modelu a využívá komunikaci především pro výpočty různých metrik agentů, je však postačujícím jazykem SL. Naopak mezi jazyky, které byly pro systém vyhodnoceny jako nevhodné, patří KIF, RDF, CCL a LEAP. První tři jazyky, které jsou specifikované dle FIPA, stejně tak jako vybraný jazyk SL, jsou bohužel stále v experimentální fázi a doposud nebyly oficiálně standardizovány. Jazyk LEAP zase představuje nevhodnou volbu především kvůli způsobu navržení. Je navržen totiž tak, aby mu rozuměly pouze agenty, nikoliv člověk.
5.2.7
Ontologie
Navržení jazyka SL do systému ASE vede také k přidání parametru označující příslušnou ontologii, jejíž využití je velmi úzce spjato se syntaxí obsahu zprávy. Ontologie totiž představuje slovník využívaných slov v syntaxi, nebo také sémantiku určující význam slov, která jsou v syntaxi použita. Díky ontologii jsou tak agenty schopny porozumět významu používaných slov v obsahu zprávy [5] [10]. Problematikou ontologií se zabývají také zdroje [27] [33] [34]. Pro implementování ontologie a jazyka SL do systému ASE bylo navrženo editovat již existující balíček content, který je součástí nástroje JADE. V tomto balíčku jsou pak pro systém stěžejní především balíčky lang, onto a schema [6]. Balíček content obsahuje také tzv. Content manager, který se stará o transformování a následné vkládání obsahu do zprávy. Při této transformaci je využíváno právě ontologie a jazykového SL kodeku. Ontologie se stará o konvertování informace z pohledu sémantiky, zatímco jazykový kodek obstarává překlad do textu dle syntaktických pravidel daného jazyka. Další použitý balíček schema definuje prvky tzv. content reference modelu (viz diagram tříd č. 4). Všechny tyto prvky mohou být využity při tvorbě obsahu zprávy. Jediné tři prvky však musí být nadefinovány i v jednotlivých ontologiích. Jedná se o predikáty, koncepty a akce agenta [5].
21
Diagram 4: Diagram tříd znázorňující content refference model, převzato z [5]
22
6 Návrh transportních a komunikačních služeb
V této části práce budou rozebrány prvky obstarávající transportní a komunikační služby. Pro inspiraci a snadnější určení hlavních elementů, potřebných k realizaci těchto služeb, byl využit komunikační protokol (viz diagram komponent č. 5) zachytávající obecnou komunikační architekturu [39].
Diagram 5: Diagram komponent reprezentující protokol komunikační architektury, převzato z [39]
Dle tohoto diagramu komponent je komunikace tvořena schránkami, které slouží ke shromažďování vedených konverzací nebo zasílaných zpráv. Dále jsou pro realizaci 23
komunikace
nutné
komponenty
zajišťující
kódování
a
dekódování
zpráv
a samozřejmě také prvky, které slouží k přijímání a odesílání těchto zpráv. Hlavním cílem této kapitoly je vysvětlení, rozbor a odůvodnění způsobů, jakými jsou tyto jednotlivé elementy v systému ASE navrženy. Návrh je také do velké míry ovlivněn volbou komunikačního frameworku, který se podílí na realizaci mnoha zmíněných služeb.
6.1 Výběr vhodného komunikačního a transportního frameworku Výběr vhodného komunikačního a transportního frameworku vychází, mimo jiné, z principů, které byly představeny švýcarským projektem The Controls Middleware [56]. Hlavním cílem tohoto projektu bylo sjednocení vhodných middleware1 řešení, které zajistí lepší řízení CERN akcelerátorů [57]. Knihovna RDA (Remote Devices Access) byla postavena na standardu zvaném CORBA [58]. Hlavním úkolem knihovny bylo umožnit komunikaci se servery, které řídí hardwarové senzory a pohony. Nedostatkem tohoto standardu byla špatná přizpůsobivost na změny či vzniklé problémy, v důsledku čehož bylo RDA velice obtížné udržovat či rozšiřovat. Další problém představovala příliš velká komplexnost systému, kde i při využívání pouze určité části docházelo k plnému zatěžování hardwaru. Z těchto důvodů měla být CORBA nahrazena některým z nově dostupných middlewarů, který by měl splňovat všechny požadavky a poskytovat možnost snadného zakomponování do současné infrastruktury systému. Systém JADE využívá služby MTS, která je založena na centralizované obsluze zpráv, při které však dochází k přetěžování systému. Pro systém ASE je tedy vhodné celkově poupravit infrastrukturu transportních služeb a zvolit k ní co nejjednodušší a nejvhodnější transportní framework. Provázanost řešené problematiky plyne i z kladených požadavků na nový framework. Požadavky obou projektových týmů se liší minimálním způsobem. Nový framework by měl splňovat následující požadavky:
Middleware představuje označení pro software, který zprostředkovává specifickou část služeb systému. 1
24
Je konzistentní v implementaci pro jazyky C++ a Java. Nové multiagentní prostředí ASE je vyvíjeno v jazyce Java, tudíž je postačující konzistence pouze s tímto jazykem.
Poskytuje snadné sledování komunikace peer-to-peer2 se spolehlivými protokoly request/reply [59] [43] a publish/subscribe [43]. Tento požadavek je i pro ASE jedním z těch nejdůležitějších, a to především z důvodu realizace zasílání přímých zpráv mezi agenty a hromadných zpráv pro synchronizaci a objevování jiných platforem.
Podpora synchronní a asynchronní komunikace. Při řešení a nasazení na multiagentní systém je důležitý především asynchronní typ komunikace, který zajišťuje rychlé výpočty systému a zvyšuje tak jeho výkonnost. Tento aspekt systému je detailněji rozebírán v sekci 6.4.
Kvalita služeb, jako timeout management, řešení front zpráv a priorit, různé typy řízení vláken, může při nasazení frameworku na multiagentní systém znamenat výhodu při implementaci a řešení jednotlivých prvků systému.
Malá velikost knihoven, nízké nároky na paměť a konfiguraci počítače. Tento požadavek je stěžejní i pro systém ASE. Minimalizací a optimalizací všech těchto prvků lze totiž docílit maximálního výkonu a navýšení tak počtu spuštěných a komunikujících agent systému.
Žádné, nebo pouze pár externích závislosti, které mohou být s aplikací spojené, preferování žádných doplňkových služeb. Tyto prvky jsou pro využívání multiagentního
systému
nežádoucí.
Systém
má
být
především
co
nejjednodušší a nejvýkonnější, a proto je nutné abstrahovat od prvků, které by pro systém mohly představovat další zbytečné zatížení.
Open source, dobrá dokumentace a podpora zahrnující velkou a aktivní komunitu. Open source verze je žádoucí jednak kvůli bezplatnosti, ale samozřejmě také kvůli možnosti volné úpravy a přizpůsobování při implementaci. Dobrá dokumentace a aktivní komunita sama o sobě vypovídá o kvalitě daného frameworku.
Jednoduchost a využívání API (Application Programming Interface), umožňuje snadnější pochopení a ulehčuje práci při implementování prvků systému.
Peer-to-Peer označuje přímou komunikaci na úrovni klient-klient, opakem je pak komunikace klientserver, kde je využíváno centrálního serveru. 2
25
Na základě těchto požadavků švýcarský CMW tým otestoval deset middlewarů včetně jejich současného. Dle těchto testů (viz sekce 7.1.1) byly jako nejlepší vyhodnoceny frameworky ZeroMQ [43] a ICE [42]. Pro samotnou multiagentní aplikaci ASE byly oba tyto frameworky implementovány a otestovány. Na základě testování byl posléze zvolen framework, který je pro systém ve všech směrech nejvhodnější volbou. Při testování frameworků byl kladen důraz především na jednoduchost jejich implementace a celkový výkon.
6.1.1
Ice vs ZeroMQ
Framework ICE je middleware, který neslouží ke klasickému zasílání zpráv, vytváří si pouze reference na vzdálené objekty, pomocí kterých je mu pak umožněno volat jejich metody. ZeroMQ oproti tomu umožňuje zasílání zpráv v podobě objektů, které jsou při přenosu převáděny na byty. ICE je řazen spíše mezi high-level frameworky [42], a nabízí tak mnohem více služeb, které jsou pro projekt nepotřebné. Naopak některé prvky, které jsou pro systém nezbytné, jsou v něm řešeny nevhodným způsobem. Příkladem může být využívání špatného protokolu pro odesílání systémových zpráv, které umožňují synchronizaci a objevování platforem (viz sekce 6.1.2). Na základě implementace programátorem projektového týmu bylo zaznamenáno několik následujících důležitých rozdílů mezi těmito frameworky. Díky tomu, že ZeroMQ představuje spíše low-level framework [43], bylo oproti nasazení ICE zaručeno celkové zjednodušení infrastruktury. Při stejné funkcionalitě obou frameworků byl u ZeroMQ dvanáctinásobně zredukován zdrojový kód a byla odstraněna jedna aplikační vrstva, což vedlo k celkovému zjednodušení, zpřehlednění a samozřejmě také k důležitému navýšení výkonu. Další výraznou změnou je využívání jiného protokolu a způsob rozesílání globálních systémových zpráv. Ve frameworku ICE byl pro rozesílání globálních zpráv využíván protokol UDP [60] a funkce multicastu [42]. Verze, ve které je využíván ZeroMQ, je zasílání globálních zpráv řešeno pomocí protokolu TCP [60] s využíváním centrálního proxy serveru [43] a jednoduché javascript aplikace Node.js [43], která se stará o sbírání příchozích zpráv a jejich přeposílání na jednotlivé nody v síti. Rozesílání globálních zpráv řeší místo metody multicast metoda broadcast [43], protože se jedná o spolehlivější a zároveň jednodušší metodu na implementaci.
26
Dalšími výhodami ZeroMQ je využívání tzv. Berkley socketů [43] [61] a nabídka velkého množství komunikačních a transportních protokolů [56]. Na základě testů jednotlivých frameworků (viz sekce 7.1) byl pro systém ASE zvolen framework ZeroMQ. Dle proběhlých testů, ale i testů, které poskytuje CMW tým, lze říci, že je ZeroMQ výkonnější, jednodušší a pro nasazení do multiagentního systému se jeví jako nejvhodnější řešení. Nasazení frameworku ICE bylo vyhodnoceno jako nevhodné, protože se primárně nezabývá zasíláním zpráv, je složitější a také náročnější na systémové požadavky. Využití tohoto frameworku bylo vyhodnoceno spíše pro vzdálené volání funkcí a komunikaci na vyšší úrovni, než je řešena v multiagentním systému.
6.1.2
Využívané transportní protokoly v ASE a JADE
Transportní protokoly v systému ASE slouží k zprostředkování komunikace respektive k transportu jednotlivých typů zpráv. Vzhledem k tomu, že je v systému implementován framework ZeroMQ, je využíváno jeho transportního protokolu. Jedná se o tzv. ZeroMQ message transport protocol (ZMTP). Tento protokol je přímo postaven nad protokolem TCP, který je řazen mezi spolehlivé protokoly, při jejichž použití nedochází ke ztrátě zpráv. Tato vlastnost je pro systém velice žádoucí. V porovnání s testovaným frameworkem ICE se tedy jedná o výrazné zlepšení. ICE poskytoval protokoly dva, TCP a UDP. TCP protokol se zabýval přímým zasíláním konverzačních zpráv. Problém však představoval protokol UDP, který obstarával zasílání hromadných synchronizačních zpráv. UDP protokol je oproti protokolu TCP jednodušší, avšak je nespolehlivý a nezaručuje, že se některá ze zasílaných zpráv neztratí [60]. V důsledku ztrácení zpráv tak docházelo k deadlockům3 celého systému. K přechodu do dalšího ticku simulace je totiž nutné, aby se jednotlivé nody synchronizovaly. V případě ztráty některé ze zpráv však k této vzájemné synchronizaci nikdy nedojde, protože se ztracená zpráva nikdy čekajícím nodům nedoručí. Protokol UDP byl tedy hlavní příčinou nefunkčnosti synchronizování a objevování jiných platforem. Aplikováním frameworku ZeroMQ a jeho protokolu ZMTP byl tento nežádoucí problém vyřešen.
Deadlock představuje stav zablokování, ke kterému dochází v důsledku čekání na dokončení předcházejícího stavu. 3
27
V systému JADE je transport zpráv řešen především dvěma hlavními protokoly, HTTP a IMTP. Využití protokolu HTTP začíná při inicializaci hlavního containeru. Slouží k naslouchání příchozích spojení na nastavené adrese. Pokud je spojení navázáno a je obdržena validní zpráva, MTP zprávu v rámci distribuované platformy přesměruje k cílenému agentu. Jednotlivé platformy pak lokálně využívají svůj vlastní transportní protokol IMTP. Tento protokol tedy slouží k zasílání zpráv mezi agenty, které žijí na jedné společné platformě, ale v různých containerech. Tento protokol se také stará o transport interních příkazů potřebných k řízení distribuované platformy, jako například vypnutí containerů, sledování nedostupných containerů apod [5].
6.2 Komunikační elementy v ASE Tato kapitola je zaměřena na rozbor a způsob realizace jednotlivých komunikačních elementů v systému ASE. Pro shromažďování uskutečněných konverzací mezi agenty slouží tzv. konverzační box [39]. Do tohoto boxu jsou ukládány všechny proběhlé konverzace na základě ID konverzací. Podle těchto ID lze později jednotlivé konverzace dohledávat. Řešení všech parametrů zpráv, včetně konverzačního ID, je podrobně řešeno v sekci 5.2. Pro ukládání zasílaných zpráv slouží tzv. fronta zpráv, která je v systému realizována třídou MessageQueue. Dalšími elementy komunikace jsou prvky zabývající se zasíláním a nasloucháním zpráv. Zasíláním zpráv se v systému ASE zabývají třídy Sender a Broadcaster. Jejich využití je závislé na typu zasílaných zpráv. V systému existuje pět různých typů zpráv. Tyto zprávy lze rozdělit buď na přímé a hromadné nebo na konverzační a synchronizační. O zasílání přímých zpráv se stará prvek Sender, zasílání hromadných zpráv má na starost prvek Broadcaster. Na druhé straně stojí prvky, které vlastní adresy, na kterých naslouchají. V důsledku toho mohou přijímat zasílané zprávy. Těmito prvky jsou Listener a Subscriber. Listener slouží k naslouchání přímých typů zpráv. Pokud je zpráva určena pro agenty, je zpráva předána do fronty zpráv, v případě, že je určena pro danou platformu, tak je poslána na platformu, která na zprávu reaguje. Naopak Subscriber slouží k naslouchání zpráv odeslaných Broadcasterem. Rozborem jednotlivých typů zpráv a způsoby jejich zasílání a přijímání se bude zabývat následující kapitola 6.3. Posledním elementem komunikace je služba řešící kódování a dekódování zprávy. V systému ASE je tato služba implementována pomocí třídy MessageConverter, která využívá služeb 28
frameworku ZeroMQ. Tato třída má za úkol při odesílání zpráv skrze síť převádět zprávy z objektů na byty, a při předávání do fronty zpráv pak znovu převádět zpátky z bytů na objekt. Tento způsob zajišťuje konzistentní a rychlý přenos zpráv po síti.
6.3 Rozbor typů zpráv a komunikačních prvků v ASE Tato kapitola je zaměřena na detailní rozbor jednotlivých typů zpráv. Dále pak prvků a způsobů realizujících jejich zasílání včetně důsledků, které z jejich zasílání plynou. Dále jsou vysvětleny hlavní důvody, proč je jejich existence v systému ASE nezbytnou součástí.
6.3.1
Sender a Broadcaster
Sender a Broadcaster mají v systému na starost zasílání zpráv. Součástí každé platformy je vždy jeden Sender a jeden Broadcaster. Sender se zabývá přímým zasíláním zpráv, řeší tedy nejčastěji odesílání zpráv mezi agenty. Řeší však také zprávy, které tvoří odpovědi na zprávy zaslané z Broadcasterů. Ty jsou pak odesílány přímo na adresované platformy. Sender vždy nejprve navazuje spojení na vzdálený Listener a odesílá zprávy v módu “push“ [43]. Pro zprávy lokálního typu, tedy zprávy, které jsou zasílány v rámci platformy se stejnou adresou, je implementován loopback. V tomto případě je obcházen mechanismus zasílání zpráv a zpráva je ihned umístěna do fronty zpráv pro agenty. Jednotlivé stavy objektu Sender jsou zachyceny na stavovém diagramu níže. Při inicializaci se nachází objekt v nečinném stavu. Z tohoto stavu může vykonávat vždy pouze jednu funkci, jelikož má přiřazené pouze jedno vlákno. Není tedy možné, aby souběžně nacházel ve dvou různých stavech. V závislosti na volaných metodách sendMessage() a sendWelcomeMessage() je přecházeno buď do stavu zasílání přímé konverzační zprávy, nebo do stavu zasílání přímé synchronizační uvítací zprávy. Po dokončení jednotlivých stavů se objekt Sender vždy navrací do nečinného stavu, ze kterého pak může přejít do koncového stavu představující ukončení existence objektu. Stavová struktura objektu Broadcaster je velice podobná jako u objektu Sender. Stavy se liší pouze v počtu a typu zasílaných zpráv.
29
Diagram 6: Stavový diagram elementu Sender, vlastní tvorba
Broadcaster se stará o hromadné zasílání systémových synchronizačních zpráv a funguje v módu “dealer” [43]. K zasílání zpráv využívá centrálního proxy serveru, který je napsán v jednoduché javascript aplikaci Node.js. Ta poskytuje dvě rozhraní. Jedno slouží pro příjem zpráv, druhé naopak pro jejich publikování. K naslouchání je tedy využíváno dvou portů. Pokud přijde zpráva, proxy jí publikuje na všechny platformy. Zpráva není nijak rozbalována ani analyzována, je předána ve stavu, ve kterém přišla, a to všem připojeným platformám včetně té, která zprávu odeslala. Pro příjem zpráv je využit návrhový vzor “router“ [43]. Cokoliv, co přijde, je přesměrováno jinam. Publikování zpráv naopak využívá návrhového vzoru “publisher“ [43]. Při naslouchání na nastaveném portu připojený klient pouze naslouchá a je pasivní. Proxy je naopak prvkem aktivním a zprávy odesílá. Proxy nemá v tomto případě žádné tušení o počtu či adresách připojených platforem.
6.3.2
Subscriber a Listener
Subscriber a Listener patří mezi služby, které v systému ASE naslouchají na nakonfigurovaných adresách, díky kterým jsou schopné přijímat a přerozdělovat zprávy daným adresátům. Každá platforma vlastní svůj vlastní Subscriber i Listener. Listener slouží k naslouchání přímých typů zpráv. Naslouchá pro příchozí připojení od prvku Sender a funguje v módu “pull“ [43]. Na základě adresáta je zpráva předávána buďto do fronty zpráv, určených pro agenty, nebo přímo adresované platformě. Subscriber v systému slouží pro naslouchání hromadných zpráv zaslaných 30
Broadcasterem. Tento prvek funguje v módu “subscribe“ [43]. Tyto zprávy jsou především systémového rázu a jsou určeny přímo platformám. V případě, že je na zprávy přijatých Subscriberem vyžadována odpověď, je vždy zpětně odesílána přímo, nikoliv znovu hromadně přes Broadcaster. Subscriber v takovýchto případech zpětnou zprávu pouze vytváří, o zaslání se poté stará element Sender. Na následujícím stavovém diagramu č. 7 si lze povšimnout, jakých stavů může element Listener při běhu aplikace nabývat. Při inicializaci se nachází v nečinném stavu. Do aktivního stavu naslouchání se dostává až při volání metody listen(). Před samotným nasloucháním však pomocí metody bind() [43] přechází do stavu binding, ve kterém je mu přiřazována adresa určená k naslouchání. V tomto stavu se nachází další dva podstavy zachycující stav, kdy má již Listener adresu přiřazenou a je tedy připraven. Na tento stav pak navazuje tzv. handling bytes představující přenášení zkonvertovaných zpráv v podobě bytů. První byte, který představuje typ přenášené zprávy, vždy rozhoduje o tom, kam Listener danou zprávu zařadí. V případě, že se nachází platforma v posledním kroku simulace, je volána metoda shutdown(), a Listener tak přechází znovu do stavu nečinnosti, ze kterého je mu umožněno přejít do koncového stavu. Jednotlivé stavy Subscriberu jsou téměř identické.
Diagram 7: Stavový diagram elementu Listener, vlastní tvorba
31
6.3.3
MessageQueue
MessageQueue je v systému velice důležitou komponentu. Představuje tzv. frontu zpráv, která shromažďuje všechny zprávy určené agentům. V systému ASE vlastní každá platforma jednu frontu zpráv. Posílání zpráv probíhá prostřednictvím ZeroMQ pomocí metody send(). O vložení do jednotlivých front se starají naslouchající Listenery. K frontám poté přistupují jednotlivé agenty daných platforem a voláním metody receive(), kterou mají nadefinovanou v konkrétních typech chování, si vybírají zprávy jim určené. V současné verzi systému je pro předávání zpráv používán model ”push”/”pull”. Přidávání zpráv do front zpráv má na starost metoda “push“, naopak o vybírání se stará metoda “pull“. Pořadí při vybírání zpráv je zcela náhodné. Agent si zprávy vybírá pouze dle jejich typu, který rozpozná díky nastaveným parametrům zprávy. Jestli však vybere zprávu, která do fronty momentálně přišla nebo zprávu, která ve frontě čeká již nějakou chvíli, není metodou “pull“ řešeno. Pro systém ASE však toto řešení nepředstavuje nutné pohoršení. Vzhledem k přednastaveným požadavkům, tedy maximalizaci výkonu celého systému, a spuštění tak co nejvyššího možného počtu komunikujících agentů, je nutné počítat s menšími omezeními. Jediné omezení, které toto řešení představuje, je možnost zadržení zprávy ve frontě na delší dobu. Jedná se však pouze o určitou šanci, nikoliv o podmínku, tudíž je toto omezení vzhledem k výkonnostnímu navýšení přijatelné. Fronta zpráv v systému ASE nabývá čtyř různých stavů. (viz stavový diagram č. 8). Po inicializaci této komponenty se fronta nachází v nečinném stavu. Z tohoto stavu je jí umožněno přejít do jednoho ze tří dalších stavů. Mezi tyto stavy patří přidávání zpráv, vyhledávání a vyhledávání dle typu zpráv. Po dokončení jednotlivých stavů se fronta pokaždé navrací do nečinného stavu. Do jednotlivých stavů fronta nemůže nikdy přicházet souběžně, využívá totiž vždy pouze jednoho vlákna. V důsledku toho je nemožné, aby se do fronty zpráv zapisovala nová zpráva a souběžně s tímto byla tato zapisovaná zpráva ihned vyhledávána. Život objektu může být ukončen pouze z nečinného stavu a to jen v případě, že se nachází simulace v posledním kroku.
32
Diagram 8: Stavový diagram elementu MessageQueue, vlastní tvorba
6.3.4
MessageConverter
MessageConverter
v systému
ASE
představuje
komponentu
zabývající
se
konvertováním zpráv. Tuto komponentu využívají pro konvertování elementy Sender, Broadcaster, Listener a Subscriber. Při zasílání zpráv prostřednictvím Sender či Brodcaster převádí MessageConverter zprávu z objektů do podoby bytů. Tyto byty lze pak konzistentně a rychle přenášet skrze síť. V případě, že zprávu Listener nebo Subscriber přijme, je vždy konvertována zpět do podoby objektu, a to jak v případě předávání do fronty zpráv, tak v případě předávání konkrétním platformám. Jak již bylo zmíněno, první byte zprávy vždy určuje, o jaký typ zprávy se jedná.
6.3.5
MessageEntity
MessageEntity v systému ASE představuje přímý typ zprávy obstarávající agentní komunikaci (konverzační zpráva). Zasílání tohoto druhu zpráv je založeno na asynchronním zasílání zpráv. Na základě zaslané zprávy je vytvořen požadavek na jiného agenta. Odesílající agent na odpověď však nevyčkává, proto se jedná o asynchronní typ komunikace, může odpověď pouze očekávat. Agent, kterému je zpráva adresována, totiž nemusí být schopen na zprávu odpovědět, v důsledku čehož není jasně zaručena zpětná odpověď. Posílání těchto typů zpráv obstarává prvek 33
Sender, naopak nasloucháním se v tomto případě zabývá element Listener. Jedná se o jediný typ zpráv, který je adresován agentům, nikoliv platformám, a proto jsou zprávy zařazovány do front zpráv adresovaných platforem. Každá zpráva tohoto typu musí mít nastaveno několik parametrů. Díky nim Sender rozpozná, kam zprávy posílat. Adresovaný agent zase ví, co bylo předmětem zaslané zprávy a komu má na danou zprávu odpovědět. Jednotlivé parametry těchto zpráv byly rozebrány v sekci 5.2.
6.3.6
HelloMessage
HelloMessage je řazena do skupiny synchronizačních hromadných zpráv, jejíž adresování směřuje přímo na dané platformy. Tento typ systémové zprávy je zasílán vždy pouze při vzniku nové platformy. Obsahem zprávy je seznam agentů registrovaných pod danou platformou. Dále je v ní uveden aktuální tick této platformy. Tato zpráva má tedy na starost dva důležité úkoly. Prvním úkolem je zařadit nově připojenou platformu a synchronizovat ji se všemi již běžícími platformami. To zajišťuje, že mají všechny platformy systému povědomí o nově připojených platformách. Druhým úkolem je registrovat všechny agenty, které byly v rámci zprávy zaslané, do svých lokálních Registrů. Tím je každé platformě zajištěn kompletní seznam všech agentů celého systému. V důsledku toho pak při vyhledávání daných agentů či služeb nemusí využívat jiných než lokálních Registrů. Odesíláním zpráv tohoto typu se zabývá element Broadcaster, přijímání zpráv je poskytováno prvkem Subscriber.
6.3.7
WelcomeMessage
WelcomeMessage patří mezi přímý typ synchronizačních zpráv. Tato zpráva v systému funguje čistě pouze jako informativní zpětná vazba na zprávy typu HelloMessage a není na ni očekávána žádná další odpověď. Každá platforma, která obdrží zprávu typu HelloMessage, posílá zpětnou zprávu obsahující seznam agentů a aktuální tick své platformy všem platformám, které zprávu HelloMessage zaslaly. Hlavním úkolem této zprávy je tedy zpětné poskytnutí stejných informací, které byly obsaženy i v HelloMessage. V důsledku toho dochází k oboustrannému povědomí platforem. K zasílání tohoto typu zpráv je využívána třída Sender, o naslouchání se naopak stará Listener, který směřuje zprávy přímo adresovaným platformám.
34
6.3.8
SyncMessage a ByeMessage
SyncMessage Zasíláním
a
ByeMessage
SyncMessage
patří
dochází
mezi
synchronizační
k průběžnému
hromadné
vzájemnému
zprávy.
informování
jednotlivých platforem o jejich současných stavech, čímž dochází k synchronizování systému. SyncMessage je jediným typem synchronizačních zpráv, který není zasílán jednorázově. Zasílání probíhá vždy po dokončení ticku jednotlivých platforem. O tomto stavu je nutné všechny ostatní platformy informovat. Úkolem ByeMessage je odhlášení platformy, která zasílá tuto zprávu, ze systému. Tato zpráva je zasílána jednorázově, a to vždy v případě, že se simulace nachází v posledním kroku. Obě zprávy využívají pro zasílání Broadcaster a pro naslouchání Subscriber. Na zprávy tohoto typu není očekávaná žádná další odpověď.
6.4 Asynchronní vs synchronní způsob zasílání zpráv Systém ASE je navržen tak, aby využíval asynchronního zasílání zpráv. Asynchronnost
systému
zajišťuje
oproti
synchronnímu
způsobu
urychlení
a funkčnost průběhu celé simulace. Synchronní řešení je v tomto případě velice nevhodné, a to především z důvodu, že agent v žádném případě nemůže vyčkávat na odpověď a na dokončení celé konverzace. Jednak z důvodu velkého zpomalení celé simulace, ale také proto, že se dané odpovědi nemusí nikdy dočkat. Čekání agenta by tak zapříčinilo to, že se daný agent stane po dobu neurčitou nečinný, a nebude tak moct vykonávat své další aktivity. Všechny agenty tedy mohou své odpovědi pouze očekávat a není jim zaručeno, kdy a jestli vůbec se jim dané odpovědi dostane. Asynchronní zasílání zpráv je v systému ASE realizováno pomocí front zpráv, do kterých
jsou
zprávy
zasílány,
a
ze
kterých
jsou
zároveň
i
vybírány.
Rozdíly ve způsobech realizace asynchronního zasílání zpráv v systému JADE a ASE jsou zachyceny na následujícím obrázku č. 4.
35
Obrázek 4: Asynchronní řešení zasílání zpráv v systému JADE a ASE, zpracováno na základě [5]
6.5 Interakce komunikačních prvků v systému V této kapitole budou rozebrány všechny interakce systému ASE související s komunikací agentů, ale i jednotlivých platforem. Pro přehledné znázornění je využito sekvenčních diagramů. Jelikož interakce probíhají i s objekty, jejichž význam v systému nebyl v práci prozatím vysvětlen, bude vhodné tyto jednotlivé objekty před samotným rozborem stručně přiblížit. Se zasíláním zpráv v systému ASE jsou spojeny objekty tříd ServiceLocator, SyncService, System a Configuration. ServiceLocator je služba, která je součástí každé platformy. Jeho významem v systému je shromažďování všech poskytovaných služeb. Tento prvek byl do systému zakomponován z důvodu zmenšení odpovědnosti a odlehčení jednotlivých platforem. V předchozí infrastruktuře systému měla totiž všechny služby na starost přímo platforma, čímž mohlo docházet k její přetěžování. V současné verzi tak platforma pouze
využívá
ServiceLocator,
který
jednotlivé
služby
obstarává.
Součástí ServiceLocatoru jsou například i všechny již zmíněné elementy starající se o zasílání zpráv. SyncService je službou, která shromažďuje stavy jednotlivých nodů systému, a je využívána pro synchronizaci celého systému. Třída System slouží k nastavení a uchovávání adres pro Broadcaster aj. a je součástí třídy Configuration. Ta shromažďuje konfiguraci pro spouštěné prostředí nebo reportovací systém. 36
Všechny prvky spojené s komunikačními interakcemi v systému byly vysvětleny, tudíž lze přejít k jednotlivým řešeným oblastem. Mezi tyto oblasti patří řešení interakcí způsobených při přímém zasílání zpráv. Do této množiny spadá vytváření, posílání a obdržení konverzačních zpráv, dále pak posílání zpráv typu WelcomeMessage a také naslouchání obou těchto typů zpráv. Další oblastí jsou interakce způsobené zasíláním hromadných synchronizačních zpráv pomocí Broadcasteru. Do této kategorie patří například zasílání ByeMessage, HelloMessage, SyncMessage, ale také naslouchání všech těchto typů zpráv.
6.5.1
Vytváření konverzační zprávy
Vytváření konverzační zprávy (viz sekvenční diagram č. 9) vždy iniciuje samotný agent v rámci svého chování. Agent nejprve vytvoří novou instanci třídy MessageEntity a volá metodu setSender() pro nastavení odesílatele zprávy. Instance zprávy poté volá metodu Agenta getEntity(), aby mohla konkrétního agenta za odesílatele označit. Agent pro následné nastavení příjemců potřebuje získat seznam dostupných agentů, které mu mohou dané služby poskytnout, a proto volá metodu Registrů pro zaslání těchto informací. Na základě této metody vybírá pouze limitovaný počet agentů, nikdy nejsou vybírány všechny agenty. Toto vyhledávání je postaveno, jak již bylo zmíněno, na principech omezené racionality dle Simona [46] a nekompletní informace od Hayeka [47]. Důvodem je jednak rychlejší vyhledávání, a urychlení tak výpočtů systému, ale také i přizpůsobení reálnému průběhu ekonomiky, ve které také nelze znát a využívat všechny dostupné zdroje systému. V případě, že není nalezen žádný odpovídající agent, Registry navrací hodnotu null, a zprávě tak nelze žádného příjemce nastavit. Pokud je však navrácen seznam agentů, agent volá metodu zprávy pro nastavení listu příjemců a nastaví do něho všechny získané agenty z obdrženého seznamu. Poté volá metodu zprávy pro nastavení typu vytvářené zprávy. Tato metoda využívá rozhraní MessageType, ze kterého je zprávě vybrán odpovídající performativ. Poté jsou nastaveny parametry protokol, konverzační identifikátor, deadline, ontologie a jazyk obsahu zprávy. Pro nastavení obsahu zprávy volá zpráva metodu ContentManageru setContent(). Pomocí této metody je pak na základě nastavené ontologie a jazyka zprávy nastaven i odpovídající obsah.
Poté, co jsou zprávě nastaveny všechny potřebné parametry, je zpráva
připravena k odeslání. 37
Diagram 9: Sekvenční diagram vytváření konverzačního typu zprávy, vlastní tvorba
6.5.2
Odesílání konverzační zprávy
Odesílání konverzační zprávy (viz sekvenční diagram č. 10) je iniciováno agentem, který volá svoji metodu send(). Poté agent zjišťuje referenci na svého Sendera. Tu zjistí pomocí volání metody ServiceLocatoru getSender(). Po navrácení reference může využít jeho metody send(), v rámci které Sender nejprve volá metodu MessageConverteru pro konvertování zprávy z objektu na byty a ihned po ní volá metodu frameworku ZeroMQ, pomocí které je získáván socket pro přenos zkonvertované zprávy. Po navrácení tohoto socketu Sender využívá frameworku ZeroMQ pro odeslání zprávy. 38
Diagram 10: Sekvenční diagram odesílání konverzační zprávy, vlastní tvorba
6.5.3
Přijímání konverzační zprávy
Přijímání konverzační zprávy (viz sekvenční diagram č. 11) je iniciováno agentem při volání své metody receive(), kterou má nadefinovanou v konkrétním chování. V rámci této metody je posléze na ServiceLocatoru zjišťována reference na frontu zpráv. Poté, co ServiceLocator tuto referenci navrátí, může agent volat metodu fronty zpráv searchByType(). Aby fronta mohla na tuto metodu reagovat, musí nejprve od třídy Agent zjistit referenci na konkrétního vyhledávajícího agenta. Po navrácení této reference může fronta zpráv přistupovat k metodě getID(), pomocí které přesně identifikuje agenta, který chce zprávu obdržet. K určení typu vyzvedávané zprávy využívá fronta zpráv rozhraní MessageType. Výsledkem vyhledávání určitého typu zprávy patřící konkrétnímu agentu mohou být dva případy. Buď má agent ve frontě zpráv některou zprávu odpovídající vyhledávání, v důsledku čehož ji obdrží, nebo fronta zpráv žádnou odpovídající zprávu nenalezne a je navrácena prázdná hodnota null.
39
Diagram 11: Sekvenční diagram přijímání konverzační zprávy, vlastní tvorba
6.5.4
Naslouchání přímých typů zpráv
Naslouchání přímých typů zpráv (viz sekvenční diagram č. 12) je iniciováno Listenerem, který v případě, že je aktivní a naslouchá, volá opakovaně sám nad sebou svoji metodu handleBytes(). Podle prvního bytu pak rozpozná, o jaký typ zprávy se jedná. V případě, že se jedná o konverzační typ zprávy, je volána metoda MessageConverteru
pro
zpětné
konvertování
zprávy
z bytu
na
objekt.
Listener převede navrácený objekt pomocí metody objectToMessage() na zprávu. Pokud tato zpráva není prázdná, tak Listener pomocí ServiceLocatoru zjišťuje referenci na frontu zpráv. Po navrácení této reference může využít její metody addMessage(), díky které je mu umožněno přidat zprávu do fronty zpráv. V případě, že se jedná o typ zprávy WelcomeMessage, je znovu opakován stejný průběh až po převedení na zprávu. Vzhledem k tomu, že se však jedná o systémový typ zprávy, který je určen pro platformy, tak zpráva vyvolává okamžitou reakci informované platformy. Pokud zpráva není prázdná, je provedena funkce zajišťující 40
opakovaní registrace všech agentů obsažených ve WelcomeMessage. Tato registrace probíhá tak, že si Listener nejprve zjistí referenci na Registry. Tuto referenci následně využije k volání metody register(), pomocí které probíhá registrace všech agentů. Po dokončení registrace je skrze metodu ServiceLocatoru getSyncService() umožněno využití metody služby SyncService, která slouží k aktualizaci stavu informované platformy.
Diagram 12: Sekvenční diagram naslouchání přímých typů zpráv, vlastní tvorba
41
6.5.5
Nastavení nodů
Nastavení nodů (viz sekvenční diagram č. 14) probíhá u zpráv typu ByeMessage, HelloMessage i SyncMessage. Pro nastavení nodů je zapotřebí zjištění adresy, na které naslouchá služba Subscriberu adresovaných nodů. K nastavení této adresy se jednotlivé typy zpráv dostávají nejprve využitím metody ServiceLocatoru getConfig(), následně pak metody system() obsažené v třídě Configuration. Díky získaným referencím zmíněných objektů pak zprávy mohou přistupovat k metodě Systemu umožňující zjištění adres naslouchajících Subscriberů.
6.5.6
Nastavení ticků
Nastavení ticků (viz sekvenční diagram č. 14) je vždy iniciováno Broadcasterem při volání metody setTicks(). Tato metoda je vyvolávána při nastavování zpráv typu SyncMessage a HelloMessage. Vytvořené instance zpráv si vytvářejí referenci na SyncService, pomocí které pak využívají metody této třídy pro zjištění aktuálního ticku daného nodu.
6.5.7
Získávání socketu
Získávání socketu (viz sekvenční diagram č. 13) je u zpráv typu ByeMessage, HelloMessage a SyncMessage vždy iniciováno Broadcasterem. Ten volá metodu pro získání socketu, který je určen k poslání zprávy. Pokud Broadcaster socket získá, volá metodu frameworku ZeroMQ sloužící k odeslání zprávy. V rámci tohoto zaslání je zpráva vždy konvertována z objektu na byty.
Diagram 13: Sekvenční diagram získávání socketu, vlastní tvorba
42
6.5.8
Odesílání zprávy ByeMessage
Odesílání zprávy ByeMessage je iniciováno platformou, a to pouze v takovém případě, že se jedná o poslední tick celé simulace. Platforma nejprve zavolá metodu Broadcasteru sendBye(), v rámci které je vytvořena instance zprávy ByeMessage. Broadcaster poté volá metodu této instance pro nastavení nodů, kterým má být zpráva zaslána. Poté, co jsou všechny nody nastaveny, je volána metoda pro získání socketu.
6.5.9
Odesílání zprávy SyncMessage
Odesílání zprávy SyncMessage iniciuje služba SyncService při synchronizování jednotlivých nodů systému. V případě, že je nutná synchronizace nodů, je zavolána metoda Broadcasteru sendSync(). Ta následně vytváří instanci zprávy SyncMessage. V rámci této zprávy nejprve probíhá nastavení aktuálního ticku, poté následuje nastavení nodů, které mají zprávu obdržet. Nakonec Broadcaster volá metodu pro získání socketu.
6.5.10
Odesílání zprávy HelloMessage
Odesílání zprávy HelloMessage (viz sekvenční diagram č. 14) je vždy iniciováno platformou při volání metody Broadcasteru sendHello(). Broadcaster na toto volání reaguje vytvořením nové instance zprávy typu HelloMessage. Té je nejprve nastaven aktuální tick daného nodu, a poté i všechny nody, kterým má být zpráva adresována. Nakonec je do zprávy přidán seznam všech registrovaných agentů daného nodu. Po nastavení ticků, nodů a seznamu všech agentů je volána metoda pro získání socketu.
43
Diagram 14: Sekvenční diagram odesílání zprávy HelloMessage, vlastní tvorba
6.5.11
Odesílání zprávy WelcomeMessage
Odesílání zprávy WelcomeMessage (viz sekvenční diagram č. 15) je iniciováno Subscriberem v důsledku obdržení zprávy HelloMessage. Subscriber nejprve vytváří instanci třídy WelcomeMessage, poté volá metody této zprávy, které slouží pro nastavení seznamu agentů dané platformy a nastavení adresovaného nodu. K zjištění a nastavení aktuálního ticku daného nodu využívá metody, která je poskytována službou SyncService. K odeslání zprávy pak WelcomeMessage znovu využívá ServiceLocatoru, pomocí kterého zjišťuje referenci na odpovídajícího Sendera. Navrácená
reference
Senderu
následně
umožňuje
volání
jeho
metody
sendWelcomeMesssage(), která zahajuje odeslání zprávy. Zprávu je znovu nutné s využitím MessageConvertoru zkonvertovat z objektu na byty, a následně pak získat socket pro přenos zprávy. Až teprve poté je možné zprávu prostřednictvím metod frameworku ZeroMQ odeslat.
44
Diagram 15: Sekvenční diagram posílání WelcomeMessage, vlastní tvorba
6.5.12
Naslouchání hromadným typům zpráv
Naslouchání hromadných typů zpráv (viz sekvenční diagram č. 16) je iniciováno službou Subscriber, která při aktivním stavu naslouchá a přijímá zprávy. Během tohoto naslouchání nad sebou opakovaně volá metodu handleBytes(), stejně tak jako Listener. První byte obdržené zprávy znovu rozhoduje o tom, jakým způsobem bude se zprávou nakládáno a jaká na ni proběhne reakce. V případě, že se jedná o zprávu typu HelloMessage, dochází k zpětnému konvertování zprávy z bytů na objekt, a poté převedení objektu na zprávu. V případě, že je obdržená zpráva zaslána jiným nodem, než tím, který ji přijímá, a její obsah není prázdný, je vykonáno registrování všech agentů zaslaných v této zprávě. Tato registrace probíhá opakovaně až do doby, než jsou všechny agenty zaregistrovány, a je realizována voláním metody Registrů register(). Po dokončení registrace si Subscriber zjišťuje referenci na službu SyncService, aby mohl využít jeho metody pro aktualizování stavu zaslaného nodu. 45
Tento stav je aktualizován na základě zaslané zprávy, jejímž obsahem je i aktuální tick zasílaného nodu. Poté, co dojde ke zpracování všech náležitostí HelloMessage, je iniciováno zaslání zpětné odpovědi prostřednictvím zprávy WelcomeMessage. V případě obdržení zprávy SyncMessage, dochází téměř ke stejnému průběhu jako u HelloMessage. Rozdílem však je, že SyncMessage obsahuje pouze ticky jednotlivých nodů, v důsledku čehož dochází pouze k aktualizování stavů nodů, které o sobě zaslaly informaci.
Diagram 16: Sekvenční diagram naslouchání hromadným typům zpráv, vlastní tvorba
46
6.6 Rozdíly komunikačních prvků systémů JADE a ASE V této kapitole budou rozebírány hlavní rozdíly v návrhu jednotlivých komunikačních prvků systémů JADE a ASE. Dále pak budou uvedeny důvody, proč jsou jednotlivá řešení pro systém vhodnější. Stěžejní rozdíly plynou především z faktu, že JADE je kompletně navržen dle standardů FIPA, ve kterých je navržení jednotlivých komunikačních elementů předdefinováno. I přesto jsou některé prvky navrženy způsobem, který je zbytečně složitý a dělá systém při spuštění většího počtu komunikujících agentů nepoužitelný. Tato kapitola je určena k rozboru právě takovýchto prvků. Dalším zásadním rozdílem, který do velké míry ovlivňuje návrh a implementaci jednotlivých prvků v ASE, je využití komunikačního a transportního frameworku. První rozdíl mezi oběma systémy, je řešení fronty zpráv viz obrázek č. 4 (sekce 6.4). V systému JADE má každý agent svoji vlastní frontu zpráv, ke které přistupuje. O vkládání zpráv se stará tzv. JADE run-time. V případě, že je zpráva zaslána do fronty zpráv, je agent vždy informován. Agent vybírá zprávu voláním metody receive(). Z fronty je vždy vybírána zpráva, která se ve frontě nachází na prvním místě. V systému ASE jsou fronty zpráv součástí každé platformy, nikoliv agenta. V důsledku toho jsou ve frontách shromažďovány všechny zprávy agentů patřících k daným platformám. Fronta zpráv tak obsahuje mnohonásobně větší počet zpráv, než je tomu u systému JADE. Případné přetékání front je však řešeno zavedením deadline parametru zpráv, který zprávám určuje jejich životnost. Další promazávání zpráv je prováděno na základě provedených konverzací dle konverzačního ID. Dalším rozdílem ve frontě zpráv je způsob vybírání. Při výběru zpráv z fronty je v systému ASE využívána metoda “push“, která oproti JADE metodě “first-out“ představuje náhodné vybírání zpráv. Větší počet zpráv ve frontě tak při tomto řešení nutně neznamená až tak velké zatížení, jako by tomu bylo při využití metody “firstout“, kde by se musely jednotlivé zprávy ve frontách kvůli pořadí přeskupovat. Metoda “push“ je jednodušší a rychlejší pro provádění výpočtu. Na druhou stranu může neřešení pořadí výběru zpráv vést k omezení v podobě delšího setrvání některých zpráv ve frontě.
47
Za největší problém systému JADE je považován centralizovaný způsob většiny služeb, v důsledku čehož pak dochází k přetížení. V systému ASE jsou proto tyto přetěžované prvky navrženy decentralizovaným způsobem, aby k přetěžování nedocházelo. Toto řešení si vyžádalo zakomponování několika nových služeb, které nejsou v systému JADE obsaženy. Každá platforma obsahuje službu ServiceLocator. Ta se stará a shromažďuje všechny služby daných platforem. Podobnou funkci měla v systému JADE centralizovaná služba AMS, starající se o chod jednotlivých containerů. V systému ASE jsou všechny platformy systému autonomní a rovnocenné, nevystupuje zde tedy žádný hlavní řídící prvek. V důsledku toho musely být zavedeny systémové komunikační služby zajišťující objevování platforem a jejich vzájemnou synchronizaci. Nejzásadnějším problémem systému JADE bylo centralizované řešení tzv. žlutých a bílých stránek. Žluté stránky představují seznam, do kterého jsou registrovány všechny agenty. Bílé stránky naopak seznam, ve kterém jsou registrovány všechny služby registrovaných agentů. Hlavní problém nastával v okamžiku, kdy byl spuštěn velký počet komunikujících agentů. Docházelo totiž k přetížení prvku sloužícího k vyhledávání agentů, které nabízejí vhodné služby pro umožnění vyjednávání, a vedení tak vzájemné konverzace. Na tento prvek přicházelo příliš mnoho požadavků najednou, a docházelo tak k častým timeoutům (viz sekce 7.3.6). Problém spojený s DF byl již řešen v analýze. V systému ASE jsou žluté a bílé stránky zastoupeny elementem Registry, který shromažďuje jak seznam agentů, tak i seznam jejich služeb. Registry jsou však na rozdíl od žlutých a bílých stránek řešeny decentralizovaně. V důsledku toho má každá platforma své vlastní Registry. Do těchto decentralizovaných Registrů však bylo zapotřebí přidat i agenty a služby z ostatních existujících platforem, aby zatěžování mohlo probíhat pouze lokálně v rámci jednotlivých platforem. Toto přidávání agentů a služeb je v systému ASE realizováno pomocí zasílání systémových synchronizačních zpráv (viz sekce 6.5.). Tento způsob pak řeší hlavní přetěžování systému. Dalším důležitým rozdílem, který slouží k urychlení výpočtů systému, je již párkrát zmiňované omezené vyhledávání služeb v Registrech. V systému JADE byly vyhledávány všechny odpovídající agenty, které byly vhodné ke konverzaci. Toto řešení je však velice pomalé a pro systém zatěžující. V systému ASE je proto v Registrech vyhledáváno pouze několik odpovídajících agentů. Způsob tohoto vyhledávání je zachycen v sekci 6.5.1.
48
7 Testování
Tato kapitola je věnována testování jednotlivých aspektů vyvíjené aplikace. V rámci testování proběhly testy zkoumající výkon komunikačních a transportních frameworků a zatížení proxy. Na testovacím Book-Trading modelu pak proběhly testy jednak pro délku simulace při různých počtech agentů, ale také pro optimalizaci počtu vláken, rychlost načtení agentů, synchronizování platforem na základě zasílání synchronizačních zpráv a komunikaci mezi agenty.
7.1 Test výkonu frameworků Toto testování se zabývá výkonem komunikačních a transportních frameworků. V první fázi testování jsou zaznamenány testy, které proběhly v rámci švýcarského projektu. V druhé fázi jsou pak na systému ASE testovány dva nejvhodnější frameworky, ICE a ZeroMQ.
7.1.1
Testování CMW
Pro švýcarský CMW tým směřovaly testy především na spolehlivost a rychlost komunikace. Při jejich současném využívání systému by měl nový transportní framework skrze Gigabit Ethernet síť, mezi serverem s konfigurací Intel Core 2 Duo, 1.GHz, 1GB RAM, GbE a klientem běžícím na přibližně stejném stroji zvládnout: 4000 zpráv za sekundu, požadavky request-response, nosnost = 4B, 5 zpráv za sekundu požadavky request-response, nosnost = 10 MB, publikovat 400 x 8B k 10 klientům, v době kratší než 100 ms, publikovat 30 x 8B k 10 klientům, v době kratší než 20 ms. Každý framework byl dle těchto bodů otestován. Výstupy CMW týmu jsou k dispozici na následujících dvou grafech, viz graf č. 1 a 2. Dle grafu 1 si lze povšimnou, že při komunikaci klient-server požadavku 4000 zpráv za sekundu dosáhly pouze tři frameworky. Pokud je brán v potaz pouze jazyk Java, který je v aplikaci ASE využíván, tak nejlepší možností jsou dle těchto testů frameworky ICE a ZeroMQ, které dosáhly 7000 zpráv za sekundu.
49
Graf 1: Testování frameworků dle CMW týmu, klient odesílající na C++ server, převzato z [56]
Druhý test zkoumá rychlost publikování k deseti klientům. V tomto testu jednoznačně zvítězil ZeroMQ, jehož výsledky jsou v hromadném publikování zpráv nesrovnatelně lepší než u ostatních testovaných frameworků. V tomto případě je tak nutno vyzdvihnout jeho skvělé automatické dávkování zpráv. Naopak ICE, který měl v předchozím testu s frameworkem ZeroMQ shodné výsledky, v tomto testu neobstál a jeho výsledky patřily mezi nejhorší.
Graf 2: Testování frameworků dle CMW týmu, protokol pub-sub na C++ server, převzato z [56]
50
7.1.2
Testování ASE
Testování obou frameworků probíhalo na stroji o parametrech Intel Core i5, 3 GHz, 16GB RAM. Zasílání zpráv neprobíhalo v rámci sítě, ale pouze v rámci jedné platformy na localhostu. Jak služba Sender, tak služba Listener vlastnila jedno vlákno. Test zkoumal odesílání přímých konverzačních typů zpráv, které v komunikaci probíhají mezi agenty. Bylo využito metody loop-back, dávkování 1mil. zpráv a byla sledována průchodnost a rychlost, za jakou dokáží jednotlivé frameworky zprávy zpracovat. Průchodnost představuje množství dat, které je prostřednictvím komunikace možné za danou dobu transportovat. Průchodnost je měřena v Megabytech za sekundu. Rychlost frameworku naopak zkoumá, jak rychle dokáže framework zpracovat nastavenou dávku zpráv, a je zachytávána počtem zpracovaných požadavků za sekundu. Framework
Požadavků za sekundu
Průchodnost (Mb/s)
ICE
15 000
1,6
ZeroMQ
66 666
20
Tabulka 4: Testování frameworků ICE a ZeroMQ, zpracováno na základě testovacích dat týmu ASE
Na základě tohoto testu (viz tabulka č. 4) se framework ZeroMQ jeví jako jednoznačně lepší volba pro řešení komunikačních služeb. Podle testu je více jak 4x výkonnější a přibližně 12x průchodnější než framework ICE.
7.2 Test proxy Tento test zkoumá zatěžování proxy, která se stará o přeposílání hromadných zpráv zasílaných Broadcasterem. Vzhledem k tomu, že je proxy jediným centralizovaným prvkem systému, je nutné otestovat, zda při zasílání většího počtu zpráv nebude přetěžována. Test probíhal v rámci localhostu na stroji o parametrech Intel Core i5, 3 GHz, 16GB RAM. Počet využívaných vláken se odvíjel od jader procesoru. V tomto případě byly tedy využity vlákna čtyři. Při tomto nastavení byla proxy schopna zpracovat celkem 2500 požadavků za sekundu. Je však nutné poznamenat, že samotná proxy při testu využívala pouze přibližně 5% procesoru. Zbytek procesoru připadal na běžící aplikaci. Za běžného chodu však bude pro samotnou proxy vymezen server, na kterém samostatně poběží. Díky tomu bude moci využívat 51
procesor téměř na 100%, v důsledku čehož se počet zpracovaných požadavků ještě mnohonásobně navýší. Na základě tohoto testu lze říci, že centralizované řešení pro proxy nepředstavuje žádné systémové omezení.
7.3 Testy postavené na BookTrading modelu Následujících několik testů je založeno na testovacím modelu BookTrading, který vychází z modelu, jenž se nachází v knihovnách nástroje JADE. Základním principem modelu je nakupování a prodej knih. Hlavními aktéry jsou zde agenty typu BookBuyer a BookSeller (viz diagram tříd č. 17). Agent typu BookBuyer se snaží o nákup knih, naopak agent BookSeller obstarává prodej knih. class agents Agent
Agent
BookSeller
BookBuyer
-
sold: Long = 0L resources: Integer = 10000 money: Integer = 100
-
bought: Long = 0L resources: Integer = 10000 money: Integer = 100
+ # +
BookSeller(entity :AgentEntity) setup() : void getReportValues() : Map<String, String>
+ # +
BookBuyer(entity :AgentEntity) setup() : void getReportValues() : Map<String, String>
Diagram 17: Diagram tříd agentů BookTrading modelu, zpracováno v rámci týmu ASE
Počet prodaných knih je u BookSellera zaznamenáváno pomocí atributu sold, počet koupených knih agenta BookBuyer představuje atribut bought. Oba tyto parametry jsou na začátku simulace defaultně nastaveny na nulu. Atribut resources představuje počet knih každého agenta a je nastaven na hodnotu 10 000, počet peněz je v modelu zaznamenán pomocí atributu money a má defaultní hodnotu 100. Komunikace mezi agenty probíhá následným způsobem. BookBuyer nejprve hledá prodejce knih a zasílá mu zprávu. BookSeller na zájem o prodej knihy reaguje vytvořením nabídky. BookBuyer nabídku zpracovává a odpovídá na ni. Pokud má prodejce knihu na skladě a obdrží odpověď na nabídku, knihu prodává. Ukončení konverzace je uskutečněno buď úspěšným, nebo neúspěšným uzavřením obchodu. V případě úspěšného uzavření obchodu dochází ke změně jednotlivých atributů obou agentů.
52
Pro testování bylo využito virtuálních nodů, které jsou nakonfigurovány v rámci FIM laboratoře CEPSOS a které mají k dispozici 4 GB RAM a dvoujádrový procesor.
7.3.1
Test počtu vláken
Cílem tohoto testu je optimalizování počtu vláken určených pro práci agentů, a zajištění tak co nejrychlejšího běhu simulace. V jednotlivých testech byl pro dané počty spuštěných vláken zaznamenáván čas průběhu simulace. Každý test probíhal na jednom nodu, bylo spouštěno 100 tisíc agentů a simulace byla nastavena na 5 ticků. Výstupy pro jednotlivé počty vláken jsou zachyceny v tabulce č. 5 a na grafu č. 3. Vlákna
Čas simulace (s)
2 5 10 15 30 50 100 1 000 100 000
30 31 27 31 32 34 34 41 -
Průměrná doba ticku (s) 5 5,2 4,4 5,2 5,4 5,8 5,8 7,2 -
Tabulka 5: Výstup z testování vláken, zpracováno na základě testovacích dat týmu ASE
Čas simulace (s)
Test vláken 45 40 35 30 25 20 15 10 5 0
41 30
31
2
5
32
31
34
34
27
10
15
30
50
100
1 000
100 000
Počet spuštěných vláken
Graf 3: Zobrazení počtu vláken v závislosti na čase, zpracováno na základě testovacích dat týmu ASE
53
Na základě výstupů testování bylo zjištěno, že k nejrychlejšímu dokončení simulace dojde při nastavení 10 vláken, a to v čase 27 sekund, kdy jeden tick průměrně trvá 4,4 sekundy. Při vypočítání průměrné doby byl brán v potaz čas potřebný pro nastartování 100 tisíc agentů, tedy 5 sekund. Na grafu č. 3 si lze povšimnout trendu růstu, který jasně znázorňuje, že od optimální volby čas s počtem vláken narůstá. Tento fakt je způsoben tím, že procesor musí soustředit svoji práci nejen na chod simulace, ale také na přerozdělování vláken, což negativně ovlivňuje rychlost simulace. Při běhu simulace bylo zatížení procesoru na 100%, využití paměti se pohybovalo v oblasti mezi 800-900 MB. Jediný problém testování nastal při nastavení vláken na 100 tisíc. Zde došlo během několika minut k chybě a využití paměti vystoupalo téměř na čtyřnásobnou hodnotu, cca 3,2 GB.
Pro následujících několik testů tak byla
z důvodu co nejrychlejšího průběhu simulace zvolena optimální volba počtu vláken, kterou představuje hodnota 10.
7.3.2
Test rychlosti načítání agentů
Test rychlosti načítání agentů slouží k zachycení doby, která je potřebná pro načtení různých počtů agentů. Výstupy těchto testů jsou k dispozici v následující tabulce č. 6 a grafu č. 4. Počet agentů 100 000 1 000 000 2 000 000
Rychlost načtení (s) 5 121 360
Tabulka 6: Výstup z testování rychlosti načítání agentů, zpracováno na základě testovacích dat týmu ASE
54
Test rychlosti načtení 360
400 Rychlost načtení (s)
350 300 250 200
121
150 100 50
5
0 100 000
1 000 000
2 000 000
Počet agentů
Graf 4: Rychlost načtení jednotlivých počtů agentů, zpracováno na základě testovacích dat týmu ASE
Podle výše zmíněných výstupů si lze povšimnout, že načítání různých počtů agentů není přímo úměrné času potřebného k načtení. Dodatečně byl model testován také pro 5 milionů agentů. Zde byl však využit výkonnější stroj s 16 GB RAM, i5 procesorem, 3 GHz. Při této konfiguraci proběhlo načtení všech agentů během 31 minut s celkovým využitím paměti 4 GB. Z toho plyne, že nejvhodnější počet agentů by se měl pohybovat do 1 miliónu, kdy je simulace načtena maximálně do 2 minut.
7.3.3
Test doby simulace
Úkolem testu doby simulace je zachycení průměrné doby, kterou představuje jeden tick simulace při různých počtech agentů. Testování probíhalo v rámci jednoho nodu. Výstupy tohoto testování jsou zobrazeny v tabulce č. 7 a grafu č. 5. Počet agentů 200 000 500 000 1 000 000
Čas (s) 42 128 300
Čas jednoho ticku (s) 8,4 25,6 60
Tabulka 7: Výstup z testování doby simulace, zpracováno na základě testovacích dat týmu ASE
55
Test doby simulace 350
300
Doba simulace (s)
300 250 200
128
150 100
42
50 0 200 000
500 000
1 000 000
Počet agentů
Graf 5: Závislost počtu agentů na době simulace, zpracováno na základě testovacích dat týmu ASE
Na základě grafu i získaných dat si lze znovu povšimnout, že růst doby simulace není přímo úměrný počtu spuštěných agentů. Délka simulace roste s počtem agentů exponenciálně. Při jednom milionu agentů je jeden tick vykonáván průměrně jednu minutu. Pro možnost porovnání proběhlo testování také na výkonnějším stroji s 16 GB RAM, i5 procesorem, 3 GHz, kde bylo spuštěno 5 miliónů agentů. Pouhá simulace jednoho ticku probíhala po dobu 42 minut, z čehož plyne, že takto vysoký počet je pro nedistribuovanou simulaci v rámci jednoho nodu nežádoucí. Při redistribuci na více nodů však dojde k urychlení celé simulace. Celkový počet agentů v systému bude sice stejný, avšak tím, že jednotlivé nody budou zpracovávat menší počty agentů, bude celková doba průběhu simulace urychlena. I přesto je, v závislosti na získané výstupy testů, vhodné omezit celkový počet do 1 milionu.
7.3.4
Test synchronizace systému
Tímto testem je testováno synchronizování systému. Aby mohlo být testování provedeno, bylo zapotřebí využití dvou nodů, které si budou schopny tyto zprávy mezi sebou zasílat. Na každém nodu bylo spuštěno pouze 100 agentů z důvodu urychlení simulace. Na obrázku č. 5 je vidět výstup z konzole, který celý průběh synchronizování zaznamenává.
56
Obrázek 5: Konzole s průběhem synchronizace dvou nodů, zpracováno týmem ASE v rámci testování
Na obou konzolích je zaznamenán počátek vykonávaného ticku - Executing tick. Následně každá platforma vyčkává na provedení chování všech svých agentů Waiting for agents. Poté, co agenty své chování dokončí - Agents are done, je dokončen tick dané platformy a platforma čeká na dokončení ostatních platforem systému - Tick is done – now wait for others plaforms. V tuto chvíli probíhá mezi nody výměna synchronizačních zpráv – Sending sync message a Received sync message. Po zaslání a obdržení těchto zpráv jsou oba nody vzájemně informovány o jejich připravenosti na další tick, v důsledku čehož je tick zahájen - Executing tick. Tento cyklus je opakován až do ukončení simulace. Na základě těchto testů lze označit celý průběh synchronizace za bezproblémový. 57
7.3.5
Test komunikace a reportování dat
Účelem tohoto testu bylo vyzkoušení, zda jsou jednotlivá data agentů reportována do vytvořené databáze. Na základě reportů lze pak také sledovat, jestli mezi sebou jednotlivé agenty komunikují a vykonávají svá chování. Získané výstupy ze simulace jsou zachyceny na obrázku č. 6.
Obrázek 6: Report získaných dat v Mongo databázi, zpracováno týmem ASE v rámci testování
Každý report systému obsahuje číslo daného ticku, označení nodu, identifikátor agenta, sledovaný klíčový parametr a jeho konkrétní hodnotu. Vzhledem k tomu, že jsou u agenta sledovány tři různé parametry – resources, money a sold, případně bought (podle typu agenta), jsou mu v reportu přiděleny tři položky.
58
Testování probíhalo při různých počtech agentů, aby se otestovala náročnost ukládání
dat
do
databáze.
Maximální
nastavení
bylo
1
milion
agentů.
Podle identifikátorů jednotlivých agentů (obrázek č. 6) si lze všimnout, že reportování funguje
správně
a
všechny
tři
hodnoty
jsou
opravdu
zaznamenávány.
Změny konkrétních hodnot jednotlivých parametrů z defaultního nastavení dále prokazují, že komunikace mezi agenty opravdu probíhá. Dle těchto hodnot si lze také povšimnout, že některé agenty jsou při obchodu méně aktivní, protože se jejich hodnoty změnily minimálně, nebo dokonce vůbec. Aby obchod mezi oběma agenty úspěšně proběhl, je nutné si v rámci komunikace vyměnit celkem čtyři zprávy.
7.3.6
Test zatížení v JADE
Testování modelu proběhlo i s využitím frameworku JADE. Proběhlé testy byly spíše zátěžového rázu. Účelem testování bylo především zjištění všech limitů tohoto frameworku. Pro průběh simulace bylo využito výkonného stroje s konfigurací 16 GB RAM, 8 jádrový procesor. I přesto došlo při pouhém načtení téměř 500 tisíc agentů k problému s nedostatkem paměti. Tento problém je zapříčiněn tím, že je každému agentu při jeho vytvoření přiřazeno nové vlákno vyžadující přidělení paměti. Z tohoto důvodu je tento systém nevhodný pro simulaci velkých počtů agentů. Další nedostatek, který byl testováním odhalen, je přetěžování centralizované služby DF. Při počtu 4500 komunikujících agentů tato služba nestíhala zpracovávat jednotlivé požadavky agentů. V důsledku toho docházelo k systémovým chybám a častým timeoutům. Posledním
testováním
byl
test
komunikace
dvou
distribuovaných
nodů.
Na každém nodu bylo nastaveno 5 agentů. Jednotlivé agenty mezi sebou dokázaly bez jakýchkoliv problémů komunikovat. Nedostatkem, který se však nevyskytuje pouze při distribuovanosti nodů, je nekontrolovanost celé simulace. Nástroj JADE nenabízí žádné řešení pro synchronizování platforem a průběhu simulace.
59
8 Shrnutí výsledků
Práce se zabývala rozborem a návrhem komunikační a transportní vrstvy vyvíjeného multiagentního systému ASE. Tyto vrstvy slouží k zajištění transportu všech typů zpráv, čímž je zajištěna komunikace všech úrovní systému. V první fázi jádra práce byla řešena problematika návrhu komunikace mezi agenty. Podle specifikací FIPA byl navržen koncept, ve kterém je představena základní struktura zpráv. Následně byly navrženy jednotlivé parametry, které by měly být součástí každé zasílané zprávy. Návrh probíhal tak, aby byly dodrženy požadavky týkající se výkonu a funkcionality systému. Navržením jednotlivých parametrů vzniklo pro systém ASE hned několik přínosů. Nastavení příjemců a odesílatele posloužilo k jasnému označení aktérů konverzace. Využití komunikačních aktů a interakčních protokolů zajistilo koordinaci průběhu zasílaných zpráv, konverzační identifikátor posloužil jako prvek, který umožňuje kontrolu probíhaných konverzací, zároveň také agentům přidal schopnost zapamatovat si konverzace provedené v minulosti. Deadline zprávy nastavil zprávám omezenou životnost, díky čemuž jsou odlehčovány fronty shromažďující zasílané zprávy. Ontologie a jazyk umožnily agentům vytváření komplexnějších obsahů zpráv a vzájemné porozumění při vedených konverzacích. V další části jádra proběhl návrh transportních a komunikačních služeb. Součástí tohoto návrhu byl rozbor a řešení všech typů zpráv a komunikačních prvků, včetně všech jejich interakcí, které jsou v důsledku komunikace vyvolány. Pro systém ASE byly navrženy dva hlavní typy zpráv. První typ zpráv je určen k realizaci komunikace mezi agenty, druhý typ zpráv pak slouží k zajištění potřebné synchronizace a objevování jiných platforem. Dále byly navrženy služby, jejichž úkolem je konvertování, zasílání, získávání a shromažďování zpráv. V rámci návrhu služeb byl také zvolen vhodný framework, který je využíván k realizaci jednotlivých komunikačních a transportních služeb. Pro systém ASE byl zvolen tzv. ZeroMQ, který je oproti frameworku ICE specifičtěji zaměřen na zasílání zpráv. ICE byl navíc složitější na implementaci, představoval vyšší systémové nároky a využíval
60
transportního
protokolu
UDP,
který
nebyl
vhodným
řešení
pro
zasílání
synchronizačních zpráv. V poslední částí jádra byly zpracovány jednotlivé testy systému. Testování posloužilo především k zátěžovým testům, na základě kterých byly zjištěny limity, které systém představuje. Díky testům bylo zjištěno optimální nastavení některých parametrů, jako například počet vláken nebo počet agentů. Simulace probíhala nejrychleji s využitím deseti vláken, optimální počet agentů se pohybuje kolem jednoho milionu agentů. Systém byl schopen simulovat i větší počty agentů, avšak délka simulace byla příliš dlouhá, což je pro průběh simulace nežádoucí. V rámci testování proběhly také testy, které ověřily funkčnost komunikace resp. zasílání všech typů zpráv.
61
9 Závěr a vyhodnocení
V současné verzi modelu byla vyřešena problematika komunikace agentů, zároveň byl také navržen mechanizmus zasílání zpráv, který umožňuje synchronizování a objevování jiných platforem. Vzhledem k distribuovanému a decentralizovanému návrhu celého prostředí bylo vyřešení této problematiky nezbytnou součástí práce. Funkcionalita komunikace systému byla ověřena několika testy, které proběhly v rámci laboratoře počítačových sítí CEPSOS spadající pod Fakultu informatiky a managementu Univerzity Hradec Králové. Testování probíhalo na základě jednoduchého modelu, v důsledku čehož nebyly využity všechny navržené parametry, jako například jazyk, ontologie nebo deadline zpráv. Podle získaných výsledků lze ASE označit za systém, který dokáže simulovat mnohonásobně větší počty agentů, než je tomu například u nástroje JADE, jenž byl na jednoduchém modelu také otestován. Jak velká omezení u systému ASE vzniknou, bude zjištěno až při vytvoření komplexnějšího a složitějšího ekonomického modelu, který bude zároveň aplikovat všechny zmiňované parametry. Jádro modelu bude mimo jiné inspirováno a sestavováno na základě diplomové práce Brabence, Autonomní systémy v prostředí virtuální ekonomiky [62]. Jednotlivá data, z kterých se bude v modelu vycházet, budou získávány ze statistického úřadu. Vytváření ekonomického modelu bude vést také k nutnosti tvorby konkrétních ontologií, jejichž úkolem bude definovat všechny používané pojmy v obsahu zpráv. Dalším aspektem, který bude nutno provést, je optimalizace všech parametrů, tak aby byly prvky systému co nejméně zatěžovány a zároveň aby byla umožněna simulace stále stejného počtu agentů. Jedná se především o konkrétní nastavení hodnot timeoutů systému a deadlinů zpráv. Součástí budoucího vývoje projektu může být také
testování
jiných nabízených jazyků
umožňujících
konverzaci
agentů.
Jednou z možností je například jazyk TIL. Vzhledem k tomu, že v současné verzi systému ASE není k dispozici žádné uživatelské rozhraní, pomocí kterého by mohl běžný uživatel nastavit všechny důležité parametry simulace, je potřeba vytvoření jednoduchého konfiguračního souboru. Tento soubor 62
tak bude sloužit k rychlé a jednoduché konfiguraci simulace. V konfiguraci bude možné nastavit počet jednotlivých typů agentů, počet vláken a několik dalších hodnot, které budou již přímo souviset s nastavením ekonomického modelu. Vizí projektového týmu ASE, v delším časovém horizontu, je umožnění distribuce systému po internetu a zdokonalení pojetí agenta zahrnující navržení dodatečných agentových vlastností, které budou dělat agenty inteligentnější. Jednou z vlastností může být například schopnost učit se na základě provedených chování a konverzací s jinými agenty. Aplikování této problematiky bude však velice náročné, jak z pohledu návrhu, tak systémové náročnosti, a pravděpodobně ji tak nebude možné zakomponovat do simulací požadovaných rozměrů.
63
10 Použitá literatura
[1]
KELLER, P., F. MANLIG a M. ŠIKOLA. Analytické modelování a simulace v projektování výrobních systémů. Strojírenská technologie, 1996, roč. 1, č. 1, s. 12 – 15.
[2]
DLOUHÝ, Martin. Simulace pro ekonomy. 2. upr. vyd. Praha: Oeconomica, 2005. ISBN 80-245-0973-3.
[3]
NORTH, Michael J a Charles M. MACAL. Managing business complexity: discovering strategic solutions with agent-based modeling and simulation. 2nd ed. New York: Oxford University Press, 2007. ISBN 978-019-5172-119.
[4]
LEE, Raymond S. T. a Vincenzo LOIA. Computational intelligence for agent-based systems. 2nd ed. New York: Springer, 2007. ISBN 978-354-0731-757.
[5]
BELLIFEMINE, Fabio , Giovanni CAIRE a Dominic GREENWOOD. Developing multi-agent systems with jade: discovering strategic solutions with agent-based modeling and simulation. 2nd ed. Hoboken, NJ: John Wiley, 2007. ISBN 978-0470057-476
[6]
Jade - Java Agent DEvelopment Framework [online]. In: Jade [cit. 2014-04-10]. Dostupné z:
.
[7]
Multimethod Simulation Software and Solutions [online]. In: Anylogic [cit. 201404-12]. Dostupné z:
.
[8]
WILENSKY, Uri. NetLogo Home Page[online]. In: NetLogo, © 1999-2014 [cit. 2014-04-20]. Dostupné z:< http://ccl.northwestern.edu/netlogo/>.
[9]
FLAME website. In: FLAME [online]. © 2013 [cit. 2014-04-20]. Dostupné z:
.
[10] WOOLDRIDGE, Michael J. An Introduction to MultiAgent Systems. 2nd ed. Chichester: Wiley, 2009. ISBN 978-0-470-51946-2.
64
[11] GILBERT, Nigel a Jim DORAN. Simulating Societies: Computer Simulation of Social Phenomena. 2nd ed. London: UCL Press, 1995. ISBN 978-185-7280-821. [12] DOROGOVTSEV, S. a J. MENDES. Evolution of Networks: from biological nets to the Internet and WWW. New York: Oxford University Press, 2003. ISBN 01-9851590-1. [13] MOSS, Scott J a Paul DAVIDSSON. Multi-Agent-Based Simulation. New York: Springer, 2001. ISBN 35-404-1522-X. [14] ROUMELIOTIS, Stergios I. a George A. Bekey. Distributed Multi-Robot Localization. IEEE Transactions on Robotics and Automation, October 2002, vol. 18, no. 5, s. 781-795. Dostupné také z:
. [15] NORIEGA, Pablo a Carles SIERRA. Agent mediated electronic commerce. New York: Springer, 1999. ISBN 35-406-5955-2. [16] LEE, Raymond S. T. a Vincenzo LOIA. Computational intelligence for agent-based systems. 2nd ed. New York: Springer, 2007. ISBN 978-354-0731-757. [17] VLASSIS, Nikos a Carles SIERRA. A concise introduction to multiagent systems and distributed artificial intelligence. 1st ed. San Rafael, Calif.: Morgan, 2007. ISBN 15-982-9526-8. [18] D´INVERNO, Mark a Michael LUCK. Understanding agent systems. 2nd ed. Berlin: Springer-Verlag, 2004. ISBN 35-404-0700-6. [19] DURFEE, Edmund H. a Victor R. LESSER. Negotiating Task Decomposition and Allocation Using Partial Global Planning. Artificial Intelligence. London: 1989, vol. 2, s. 229 - 243. Dostupné také z: . [20] WOOLDRIDGE, Michael J. An introduction to multiagent systems. 2nd ed. Chichester: Wiley, 2002, ISBN 04-714-9691-X.
65
[21] RUSSELL, Stuart J a Carles SIERRA. Artificial intelligence: a modern approach. 2nd ed. New Jersey: Prentice Hall, 2003. ISBN 01-379-0395-2. [22] WOOLDRIDGE, Michael J. a Nicholas R. JENNINGS. Intelligent Agents: Theory and Practice. Knowledge Engineering Review, 1995, vol. 10, no. 2, s. 115-152. [23] DEMAZEAU, ves a Jean-Pierre MULLER. Decentralized A.I. 2nd ed. New York: North Holand, 1990. ISBN 04-448-8705-9. [24] Welcome to the Foundation for Intelligent Physical Agents [online]. In: Fipa © 2014 [cit. 2014-04-28]. Dostupné z: < http://www.fipa.org/>. [25] TEAHAN, William John. Artificial Intelligence - Agents and Environments. 2010. Dostupné také z: . ISBN: 978-877681-528-8. [26] BERGENTI, Federico, Marie-Pierre GLEIZES a Franco ZAMBONELLI. Methodologies and software engineering for agent systems: the agent-oriented software engineering handbook. 2nd ed. London: Kluwer Academic, 2004. ISBN 14-020-8058-1. [27] MCARTHUR, S. D. J. a kol. Multi-Agent Systems for Power Engineering Applications. IEEE Transactions on Power Systems, November 2007, vol. 22, no. 4, s. 1-7. Dostupné také z: . [28] LEITE, Joao Alexandre. Declarative agent languages and technologies. New York: Springer, 2004. ISBN 35-402-2124-7. [29] HUHNS, Michael N. a Larry M. STEPHENS. Multiagent Systems and Societies of Agents [online]. 1999 [cit. 2014-04-18]. Dostupné také z: .
66
[30] SEARLE, John R. Speech acts: an essay in the philosophy of language. 1st ed. Cambridge: University Press, 1969. ISBN 05-210-9626-X. [31] WEISS, Edited by Gerhard. Multiagent systems: a modern approach to distributed artificial intelligence. Reprint. Cambridge, Massachusetts: The MIT Press, 2001. ISBN 978-026-2731-317. [32] BORGHOFF, Uwe M. a Johann H. SCHLICHTER. Computer supported cooperative work: introduction to distributed applications ; with 18 tables. Reprint. Berlin u.a: Springer, 2010. ISBN 978-364-2086-311. [33] BORGHOFF, Uwe M. a Johann H. SCHLICHTER. On the move to meaningful internet systems. Berlin: Springer, 2008. ISBN 978-354-0888-727. [34] AART, Chris van a Johann H. SCHLICHTER. Organizational principles for multiagent architectures. Boston: Birkhauser Verlag, 2005. ISBN 37-643-7213-3. [35] LUCK, Michael, Ronald ASHRI a Mark D'INVERNO. Agent-based software development. 2nd ed. Boston: Artech House, 2004. ISBN 15-805-3605-0. [36] COLLIS, Jaros a Divine Ndumu. The Zeus Agent Building Toolkit [online]. ZEUS Technical Manual, 1999. [cit. 2014-04-19]. Dostupné z: . [37] JACK [online]. In: AOS, © 2014 [cit. 2014-04-20]. Dostupné z: . [38] RETSINA Agent Architecture [online]. © 2006 - 2012 [cit. 2014-04-22]. Dostupné z: . [39] WEYNS, Danny a Len BASS. Architecture-based design of multi-agent systems. New York: Springer, 2010. ISBN 36-420-1064-4
67
[40] WOOLDRIDGE, Michael, Nicholas R. JENNINGS a David KINNY. The Gaia Methodology for Agent-Oriented Analysis and Design. Autonomous Agent and Multi-Agent Systems, 2000, vol. 3, no. 3, s. 285 - 312. Dostupné také z: < http://link.springer.com/>. [41] ZAMBONELLI, Franco a Andrea OMICINI. Challenges and Research Directions in Agent-Oriented Software Engineering. Autonomous Agent and Multi-Agent Systems, 2004, vol. 9, no. 3, s. 253-283. Dostupné z Springer: < http://link.springer.com/>. [42] Welcome to ZeroC, the Home of Ice. In: ZeroC [online]. © 2014 [cit. 2014-0427]. Dostupné z: < http://www.zeroc.com/>. [43] ØMQ - The Guide [online]. In: ØMQ, © 2007 - 2014 [cit. 2014-04-23]. Dostupné z: . [44] ARLOW, Jim a Ila NEUSTADT. UML 2 a unifikovaný proces vývoje aplikací. Vyd. 1. Překlad Bogdan Kiszka. Brno: Computer Press, 2007. ISBN 978-80-251-1503-9. [45] UML tools for software development and modelling - Enterprise Architect UML modeling tool [online]. In: SPARX SYSTEMS, © 2000 - 2014 [cit. 2014-04-24]. Dostupné z: . [46] SIMON, Herbert A, Massimo EGIDI a Robin MARRIS. Economics, bounded rationality, and the cognitive revolution: current research and future directions. Cheltenham, UK ; Northampton, MA: Edward Elgar, 2008. ISBN 978-184-7208965. [47] HAYEK, By Friedrich A., Massimo EGIDI a Robin MARRIS. Individualism and economic order: current research and future directions. Chicago: University of Chicago Press, 1980. ISBN 978-022-6320-939. [48] HORLAIT, Eric, Thomas MAGEDANZ a Roch GLITHO. Mobile agents for telecommunication applications. New York: Springer, 2003. ISBN 35-402-0298-6.
68
[49] Tryllian.com [online]. In: Tryllian.com, © 2013 [cit. 2014-04-25]. Dostupné z: . [50] AUSTIN, J.L., Edited by J.O. Urmson and Marina SBISÀ a Roch GLITHO. How to do things with words. 2nd ed. Cambridge, Mass: Harvard University Press, 1978. ISBN 06-744-1152-8. [51] FR DR CH, Tomáš, Ondřej KOHOUT a Michal KOŠINÁR. TIL in Knowledge-Based Multi-Agent Systems [online]. 2008 [cit. 2014-04-27]. Dostupné z: . [52] CIPRICH, Nikola. TIL-Script - Výpočetní varianta TIL. Ostrava, 2009. Diplomová práce. Technical University Ostrava, Faculty of Electrical Engineering and Computer Science, Department of informatics. Dostupné z: . [53] HOLSTER, Andrew. An Introduction to Pavel Tichy and Transparent Intensional Logic [online]. 2003 [cit. 2014-04-28]. Dostupné z: . [54] R CHLÝ, Marek. Transparentní intenzionální logika. Brno: Vysoké učení technické v Brně, Fakulta informačních technologií, Ústav informačních systémů. Dostupné z: . [55] BORDINI, Rafael H. a kol. Multi-Agent Programming: Languages, Platforms and Applications. 2d ed. New York: Springer Science Business Media, 2005. ISBN 03872-4568-5. [56] DWORAK, A. a kol. Middleware trends and market leaders 2011 [online]. France, 2011 [cit. 2014-04-29]. Dostupné z: . [57] About CERN [online]. In: CERN, © 2014 [cit. 2014-04-29]. Dostupné z: .
69
[58] „Welcome To The OMG´s CORBA Website [online]. In: OMG Homepage, © 19972014 [cit. 2014-04-30]. Dostupné z: . [59] COULOURIS, George F, Jean DOLLIMORE a Tim KINDBERG. Distributed systems: concepts and design. 4th ed. New York: Addison-Wesley, 2005. ISBN 03-2126354-5. [60] JIA, Weijia, Jean DOLLIMORE a Tim KINDBERG. Distributed network systems: from concepts to implementations. 4th ed. New York: Springer, 2005. ISBN 03872-3839-5. [61] GR GÁREK, Petr. Softwarová rozhraní systémů UNIX pro přístup k síťovým službám [online]. [cit. 2014-04-29]. Dostupné z: . [62] BRABENEC, Miroslav. Autonomní systémy v prostředí virtuální ekonomiky. Hradec Králové, 2012. Diplomová práce. Univerzita Hradec Králové, Fakulta informatiky a managementu, Katedra informačních technologií.
70
11 Přílohy Příloha č. 1
11.1 Seznam požadavků multiagentního systému ASE
Služby systému jsou řešeny decentralizovaně.
Agenty jsou schopny mezi sebou komunikovat.
Agenty mohou přijímat a odesílat zprávy.
Způsob agentní komunikace je peer-to-peer.
Agenty jsou autonomní.
Agenty mají vlastní chování, které je závislé na životním cyklu agenta.
Agenty mají vlastní stavy existence.
Každý agent může měnit svůj stav.
Každý agent si může ukládat nějaká data.
Systém odesílá metriky do databáze v systémem nastaveném čase.
Systém je schopen synchronizovat všechny agenty.
Systém pomocí synchronizace zajištuje jednotnou představu o uplynulém čase v rámci probíhající simulace.
Systém musí být schopen synchronizovat čas mezi všemi agenty.
Systém je schopen pracovat se stovkami tisíc agentů.
Systém je schopný distribuovat agenty, jejich chování i komunikaci na více počítačů.
71
12 Zadání práce
72
