diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index e7e3a5107a5aa5738b70bec14cffd11dda6446e4..2cf977b3d515ca5ed9c45c1ea8cd9f50177eddbc 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -1,22 +1,3 @@ -# -# ****************************************************************************** -# MontiCAR Modeling Family, www.se-rwth.de -# Copyright (c) 2017, Software Engineering Group at RWTH Aachen, -# All rights reserved. -# -# This project is free software; you can redistribute it and/or -# modify it under the terms of the GNU Lesser General Public -# License as published by the Free Software Foundation; either -# version 3.0 of the License, or (at your option) any later version. -# This library is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -# Lesser General Public License for more details. -# -# You should have received a copy of the GNU Lesser General Public -# License along with this project. If not, see . -# ******************************************************************************* -# image: maven:3-jdk-8 diff --git a/docs/Thesis/Formular_Eidesstattliche_Versicherung_neu.pdf b/docs/Thesis/Formular_Eidesstattliche_Versicherung_neu.pdf deleted file mode 100644 index 3dee15e9b9042bff33af54b9b976052b3f4d9030..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/Formular_Eidesstattliche_Versicherung_neu.pdf and /dev/null differ diff --git a/docs/Thesis/Formular_Logo_Verwendung.pdf b/docs/Thesis/Formular_Logo_Verwendung.pdf deleted file mode 100644 index accbb59081830fe687344a1a01eef4ec5193091a..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/Formular_Logo_Verwendung.pdf and /dev/null differ diff --git a/docs/Thesis/Masterarbeit.aux b/docs/Thesis/Masterarbeit.aux deleted file mode 100644 index 4755131fba32ce08b123faefa9c1b0715cb9df2b..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.aux +++ /dev/null @@ -1,279 +0,0 @@ -\relax -\providecommand\hyper@newdestlabel[2]{} -\providecommand\HyperFirstAtBeginDocument{\AtBeginDocument} -\HyperFirstAtBeginDocument{\ifx\hyper@anchor\@undefined -\global\let\oldcontentsline\contentsline -\gdef\contentsline#1#2#3#4{\oldcontentsline{#1}{#2}{#3}} -\global\let\oldnewlabel\newlabel -\gdef\newlabel#1#2{\newlabelxx{#1}#2} -\gdef\newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}} -\AtEndDocument{\ifx\hyper@anchor\@undefined -\let\contentsline\oldcontentsline -\let\newlabel\oldnewlabel -\fi} -\fi} -\global\let\hyper@last\relax -\gdef\HyperFirstAtBeginDocument#1{#1} -\providecommand\HyField@AuxAddToFields[1]{} -\providecommand\HyField@AuxAddToCoFields[2]{} -\citation{Caltagirone:2002:AMM:771322.771339} -\citation{Cozzi15} -\citation{DBLP:journals/corr/0001R14a} -\citation{DBLP:journals/jfr/UrmsonABBBCDDGGGHHHKKLMMPPRRSSSSSWWZBBDLNSZSTDF08} -\citation{DBLP:journals/jfr/RauskolbBLMCEFGOSWHNDHMWBBGKR08} -\citation{DBLP:journals/aes/AmbrozKP05} -\@writefile{toc}{\contentsline {chapter}{\numberline {1}Introduction}{1}{chapter.1}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\citation{DBLP:conf/vrst/NgSLL02} -\citation{DBLP:conf/infocom/2004} -\@writefile{lof}{\contentsline {figure}{\numberline {1.1}{\ignorespaces Player grouping and update multicasting\relax }}{3}{figure.caption.3}} -\providecommand*\caption@xref[2]{\@setref\relax\@undefined{#1}} -\newlabel{fig:Multicast}{{1.1}{3}{Player grouping and update multicasting\relax }{figure.caption.3}{}} -\@writefile{toc}{\contentsline {chapter}{\numberline {2}Preliminaries}{5}{chapter.2}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\@writefile{toc}{\contentsline {section}{\numberline {2.1}Massive multiplayer online gaming}{5}{section.2.1}} -\@writefile{toc}{\contentsline {section}{\numberline {2.2}Area of Interest}{6}{section.2.2}} -\newlabel{sec:aoi}{{2.2}{6}{Area of Interest}{section.2.2}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.1}{\ignorespaces Area of Interest: circular and hexagonal representation\relax }}{6}{figure.caption.4}} -\newlabel{fig:AreaOfInterest}{{2.1}{6}{Area of Interest: circular and hexagonal representation\relax }{figure.caption.4}{}} -\citation{DBLP:books/lib/TanenbaumW11} -\citation{DBLP:conf/icmcs/GautierD98} -\@writefile{toc}{\contentsline {section}{\numberline {2.3}Architectures}{7}{section.2.3}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.2}{\ignorespaces Peer-to-peer and Client/Server architectures\relax }}{7}{figure.caption.5}} -\newlabel{fig:archs}{{2.2}{7}{Peer-to-peer and Client/Server architectures\relax }{figure.caption.5}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.3.1}Peer-to-peer}{7}{subsection.2.3.1}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.3.2}Client/server}{8}{subsection.2.3.2}} -\citation{DBLP:conf/netgames/KimCCKCY05} -\citation{TaylorEtAl2007} -\@writefile{toc}{\contentsline {subsubsection}{Multi-tier architecture}{9}{section*.6}} -\@writefile{toc}{\contentsline {section}{\numberline {2.4}Distributing mechanisms}{9}{section.2.4}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.3}{\ignorespaces Three-tier architecture\relax }}{10}{figure.caption.7}} -\newlabel{fig:MultitierArch}{{2.3}{10}{Three-tier architecture\relax }{figure.caption.7}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.1}Sharding}{10}{subsection.2.4.1}} -\citation{DBLP:books/lib/TanenbaumW11} -\@writefile{lof}{\contentsline {figure}{\numberline {2.4}{\ignorespaces Sharding approach\relax }}{11}{figure.caption.8}} -\newlabel{fig:sharding}{{2.4}{11}{Sharding approach\relax }{figure.caption.8}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.2}Cloning}{11}{subsection.2.4.2}} -\citation{DBLP:journals/cn/LeeKC05} -\@writefile{lof}{\contentsline {figure}{\numberline {2.5}{\ignorespaces Cloning approach\relax }}{12}{figure.caption.9}} -\newlabel{fig:cloning}{{2.5}{12}{Cloning approach\relax }{figure.caption.9}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.3}Zoning}{12}{subsection.2.4.3}} -\newlabel{ssec:Zoning}{{2.4.3}{12}{Zoning}{subsection.2.4.3}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.6}{\ignorespaces Zoning approach\relax }}{13}{figure.caption.10}} -\newlabel{fig:zoning}{{2.6}{13}{Zoning approach\relax }{figure.caption.10}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.4}Instancing}{13}{subsection.2.4.4}} -\citation{DBLP:conf/gi/MullerG04} -\@writefile{toc}{\contentsline {section}{\numberline {2.5}Advanced distributed architectures}{14}{section.2.5}} -\newlabel{AdvancedDistributedArchitectures}{{2.5}{14}{Advanced distributed architectures}{section.2.5}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.5.1}Proxy-server architecture}{14}{subsection.2.5.1}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.7}{\ignorespaces Proxy-server architecture\relax }}{15}{figure.caption.11}} -\newlabel{fig:ProxyServer}{{2.7}{15}{Proxy-server architecture\relax }{figure.caption.11}{}} -\citation{DAfMMO-RPG} -\citation{fowler2003patterns} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.5.2}Distributed architecture combined with zoning technique}{16}{subsection.2.5.2}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.8}{\ignorespaces Distributed architecture based on zoning approach\relax }}{16}{figure.caption.12}} -\newlabel{fig:DistributedZoning}{{2.8}{16}{Distributed architecture based on zoning approach\relax }{figure.caption.12}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.9}{\ignorespaces Publish-subscribe pattern\relax }}{17}{figure.caption.13}} -\newlabel{fig:PublishSubscribe}{{2.9}{17}{Publish-subscribe pattern\relax }{figure.caption.13}{}} -\citation{gamma1995design} -\@writefile{toc}{\contentsline {section}{\numberline {2.6}Model-View-Controller pattern}{18}{section.2.6}} -\citation{walls2015spring} -\citation{DBLP:books/daglib/0067388} -\@writefile{lof}{\contentsline {figure}{\numberline {2.10}{\ignorespaces Model-View-Controller\relax }}{19}{figure.caption.14}} -\newlabel{fig:MVC}{{2.10}{19}{Model-View-Controller\relax }{figure.caption.14}{}} -\citation{DBLP:books/lib/TanenbaumW11} -\citation{fette2011websocket} -\citation{Cozzi15} -\citation{SFS} -\citation{Jetty} -\@writefile{toc}{\contentsline {chapter}{\numberline {3}Technical Requisites}{20}{chapter.3}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\@writefile{toc}{\contentsline {section}{\numberline {3.1}SmartFoxServer}{20}{section.3.1}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.1}Web Server}{20}{subsection.3.1.1}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.2}Web Services}{21}{subsection.3.1.2}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.3}Data serialization}{21}{subsection.3.1.3}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.4}Scope Management}{21}{subsection.3.1.4}} -\citation{dirksen2014three} -\@writefile{lof}{\contentsline {figure}{\numberline {3.1}{\ignorespaces SmartFoxServer architecture\relax }}{22}{figure.caption.15}} -\newlabel{fig:SFS}{{3.1}{22}{SmartFoxServer architecture\relax }{figure.caption.15}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.5}Data access and server monitoring}{22}{subsection.3.1.5}} -\@writefile{toc}{\contentsline {section}{\numberline {3.2}ThreeJS}{22}{section.3.2}} -\citation{PGSQL} -\@writefile{toc}{\contentsline {section}{\numberline {3.3}PostgreSQL database}{23}{section.3.3}} -\@writefile{toc}{\contentsline {chapter}{\numberline {4}Simulation Platform}{24}{chapter.4}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\newlabel{chap:simulationPlatform}{{4}{24}{Simulation Platform}{chapter.4}{}} -\@writefile{toc}{\contentsline {section}{\numberline {4.1}Challenges}{24}{section.4.1}} -\citation{DBLP:books/lib/TanenbaumW11} -\citation{TaylorEtAl2007} -\@writefile{toc}{\contentsline {section}{\numberline {4.2}Architecture}{25}{section.4.2}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.1}{\ignorespaces Architecture overview\relax }}{26}{figure.caption.16}} -\newlabel{fig:Overview}{{4.1}{26}{Architecture overview\relax }{figure.caption.16}{}} -\@writefile{toc}{\contentsline {section}{\numberline {4.3}Basic work-flow}{26}{section.4.3}} -\newlabel{sec:WorkFlow}{{4.3}{26}{Basic work-flow}{section.4.3}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.2}{\ignorespaces Selecting simulation scenario\relax }}{27}{figure.caption.17}} -\newlabel{fig:GuiMenu}{{4.2}{27}{Selecting simulation scenario\relax }{figure.caption.17}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.3}{\ignorespaces Notification for processed scenario simulation\relax }}{28}{figure.caption.18}} -\newlabel{fig:SimDurationGui}{{4.3}{28}{Notification for processed scenario simulation\relax }{figure.caption.18}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.3.1}Zone level}{28}{subsection.4.3.1}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.4}{\ignorespaces Visualization of simulation scenario\relax }}{29}{figure.caption.19}} -\newlabel{fig:SwitchCar}{{4.4}{29}{Visualization of simulation scenario\relax }{figure.caption.19}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.1}Framework extension by means of inheritance}{30}{lstlisting.4.1}} -\newlabel{lst:zoneInit}{{4.2}{30}{Zone initialization method}{lstlisting.4.2}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.2}Zone initialization method}{30}{lstlisting.4.2}} -\newlabel{lst:zoneRequests}{{4.3}{31}{Zone client request handling}{lstlisting.4.3}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.3}Zone client request handling}{31}{lstlisting.4.3}} -\newlabel{lst:scenarioLoad}{{4.4}{31}{Scenario loading}{lstlisting.4.4}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.4}Scenario loading}{31}{lstlisting.4.4}} -\newlabel{lst:fileUploadListener}{{4.5}{32}{Server event handling}{lstlisting.4.5}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.5}Server event handling}{32}{lstlisting.4.5}} -\newlabel{lst:zoneInternalMessaging}{{4.6}{33}{Zone internal messaging handling}{lstlisting.4.6}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.6}Zone internal messaging handling}{33}{lstlisting.4.6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.3.2}Room level}{33}{subsection.4.3.2}} -\newlabel{lst:roomInit}{{4.7}{34}{Zone internal messaging handling}{lstlisting.4.7}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.7}Zone internal messaging handling}{34}{lstlisting.4.7}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.5}{\ignorespaces SmartFox extension hot deployment\relax }}{35}{figure.caption.20}} -\newlabel{fig:sfsExtensionDeployment}{{4.5}{35}{SmartFox extension hot deployment\relax }{figure.caption.20}{}} -\newlabel{lst:userJoin}{{4.8}{36}{User join event handling}{lstlisting.4.8}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.8}User join event handling}{36}{lstlisting.4.8}} -\newlabel{lst:nextFrame}{{4.9}{37}{Room client request handling}{lstlisting.4.9}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.9}Room client request handling}{37}{lstlisting.4.9}} -\newlabel{lst:userLeave}{{4.10}{37}{User leave event handling}{lstlisting.4.10}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.10}User leave event handling}{37}{lstlisting.4.10}} -\newlabel{lst:roomDestroy}{{4.11}{38}{Releasing room resources upon destruction}{lstlisting.4.11}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.11}Releasing room resources upon destruction}{38}{lstlisting.4.11}} -\@writefile{toc}{\contentsline {section}{\numberline {4.4}Virtual World}{38}{section.4.4}} -\newlabel{sec:VirtualWorld}{{4.4}{38}{Virtual World}{section.4.4}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.6}{\ignorespaces Database entity relationship diagram\relax }}{39}{figure.caption.21}} -\newlabel{fig:ERD}{{4.6}{39}{Database entity relationship diagram\relax }{figure.caption.21}{}} -\citation{DBLP:conf/netgames/FiedlerWW02} -\citation{DBLP:reference/cg/Fortune04} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.4.1}Zoning approach}{40}{subsection.4.4.1}} -\newlabel{ssec:ZoningApproach}{{4.4.1}{40}{Zoning approach}{subsection.4.4.1}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.7}{\ignorespaces World map split into sectors\relax }}{41}{figure.caption.22}} -\newlabel{fig:SquareShapeSectors}{{4.7}{41}{World map split into sectors\relax }{figure.caption.22}{}} -\citation{DBLP:conf/ijcai/DresnerS07} -\citation{DBLP:journals/tits/GlaserVMGN10} -\citation{puntambekar2009data} -\@writefile{toc}{\contentsline {section}{\numberline {4.5}Path Finder}{42}{section.4.5}} -\newlabel{sec:PathFinder}{{4.5}{42}{Path Finder}{section.4.5}{}} -\citation{DBLP:books/daglib/0021734} -\newlabel{lst:entryNodes}{{4.12}{43}{Entry node table structure}{lstlisting.4.12}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.12}Entry node table structure}{43}{lstlisting.4.12}} -\newlabel{lst:paths}{{4.13}{44}{Path table structure}{lstlisting.4.13}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.13}Path table structure}{44}{lstlisting.4.13}} -\citation{DBLP:books/daglib/0002204} -\@writefile{lof}{\contentsline {figure}{\numberline {4.8}{\ignorespaces Path-finding procedure\relax }}{45}{figure.caption.23}} -\newlabel{fig:PathFinding}{{4.8}{45}{Path-finding procedure\relax }{figure.caption.23}{}} -\@writefile{toc}{\contentsline {section}{\numberline {4.6}Database optimization}{45}{section.4.6}} -\newlabel{lst:dbEntryNodes}{{4.14}{46}{Entry nodes batch insert transaction with shared connection}{lstlisting.4.14}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.14}Entry nodes batch insert transaction with shared connection}{46}{lstlisting.4.14}} -\@writefile{toc}{\contentsline {section}{\numberline {4.7}Web Communication}{47}{section.4.7}} -\newlabel{sec:WebCommunication}{{4.7}{47}{Web Communication}{section.4.7}{}} -\newlabel{lst:serverAdapterConnection}{{4.15}{47}{Server adapter connection establishing}{lstlisting.4.15}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.15}Server adapter connection establishing}{47}{lstlisting.4.15}} -\newlabel{lst:serverAdapterRequest}{{4.16}{48}{Server adapter sending extension request}{lstlisting.4.16}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.16}Server adapter sending extension request}{48}{lstlisting.4.16}} -\newlabel{lst:serverAdapterAPI}{{4.17}{48}{Server adapter extension requests public API}{lstlisting.4.17}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.17}Server adapter extension requests public API}{48}{lstlisting.4.17}} -\citation{STOMP} -\newlabel{lst:webService}{{4.18}{49}{WebService pulic API}{lstlisting.4.18}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.18}WebService pulic API}{49}{lstlisting.4.18}} -\@writefile{toc}{\contentsline {section}{\numberline {4.8}Simulation}{50}{section.4.8}} -\newlabel{sec:Simulation}{{4.8}{50}{Simulation}{section.4.8}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.8.1}Simulation Controller}{51}{subsection.4.8.1}} -\newlabel{lst:simCtrl}{{4.19}{51}{Simulation controller storing frame data in mediator}{lstlisting.4.19}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.19}Simulation controller storing frame data in mediator}{51}{lstlisting.4.19}} -\citation{gamma1995design} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.8.2}Mediator}{52}{subsection.4.8.2}} -\newlabel{lst:simBuff}{{4.20}{52}{Simulation buffer}{lstlisting.4.20}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.20}Simulation buffer}{52}{lstlisting.4.20}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.8.3}Scenarios}{53}{subsection.4.8.3}} -\newlabel{ssec:Scenarios}{{4.8.3}{53}{Scenarios}{subsection.4.8.3}{}} -\newlabel{lst:scenDB}{{4.21}{53}{Scenario table}{lstlisting.4.21}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.21}Scenario table}{53}{lstlisting.4.21}} -\newlabel{lst:trackDB}{{4.22}{53}{Track table}{lstlisting.4.22}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.22}Track table}{53}{lstlisting.4.22}} -\newlabel{lst:trackSec}{{4.23}{54}{Track section table}{lstlisting.4.23}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.23}Track section table}{54}{lstlisting.4.23}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.9}{\ignorespaces Scenario listing and uploading\relax }}{55}{figure.caption.24}} -\newlabel{fig:scenSeq}{{4.9}{55}{Scenario listing and uploading\relax }{figure.caption.24}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.8.4}Synchronization and Visualization}{56}{subsection.4.8.4}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.10}{\ignorespaces Simulation and visualization\relax }}{56}{figure.caption.25}} -\newlabel{fig:simVis}{{4.10}{56}{Simulation and visualization\relax }{figure.caption.25}{}} -\newlabel{lst:dmHandlers}{{4.24}{57}{DataModel handler registering}{lstlisting.4.24}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.24}DataModel handler registering}{57}{lstlisting.4.24}} -\newlabel{lst:dmHandlePromises}{{4.25}{58}{DataModel handlers execution}{lstlisting.4.25}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.25}DataModel handlers execution}{58}{lstlisting.4.25}} -\newlabel{lst:dmInit}{{4.26}{58}{DataModel after handler execution}{lstlisting.4.26}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.26}DataModel after handler execution}{58}{lstlisting.4.26}} -\citation{gamma1995design} -\newlabel{lst:dmVisCache}{{4.27}{59}{DataModel visualization and caching mechanism}{lstlisting.4.27}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.27}DataModel visualization and caching mechanism}{59}{lstlisting.4.27}} -\@writefile{toc}{\contentsline {section}{\numberline {4.9}Configuration}{60}{section.4.9}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.11}{\ignorespaces Zone configuration\relax }}{60}{figure.caption.26}} -\newlabel{fig:zoneConfig}{{4.11}{60}{Zone configuration\relax }{figure.caption.26}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.12}{\ignorespaces Web server configuration\relax }}{61}{figure.caption.27}} -\newlabel{fig:webServerConfig}{{4.12}{61}{Web server configuration\relax }{figure.caption.27}{}} -\@writefile{toc}{\contentsline {section}{\numberline {4.10}Security}{61}{section.4.10}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.13}{\ignorespaces Client authentication process\relax }}{62}{figure.caption.28}} -\newlabel{fig:Authentication}{{4.13}{62}{Client authentication process\relax }{figure.caption.28}{}} -\@writefile{toc}{\contentsline {chapter}{\numberline {5}Evaluation}{63}{chapter.5}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\newlabel{chap:evaluation}{{5}{63}{Evaluation}{chapter.5}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {5.1}{\ignorespaces Server resource usage at login phase\relax }}{64}{figure.caption.29}} -\newlabel{fig:performance1}{{5.1}{64}{Server resource usage at login phase\relax }{figure.caption.29}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {5.2}{\ignorespaces Server resource usage at simulation phase\relax }}{65}{figure.caption.30}} -\newlabel{fig:performance2}{{5.2}{65}{Server resource usage at simulation phase\relax }{figure.caption.30}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {5.3}{\ignorespaces Server messaging traffic\relax }}{65}{figure.caption.31}} -\newlabel{fig:traffic}{{5.3}{65}{Server messaging traffic\relax }{figure.caption.31}{}} -\@writefile{toc}{\contentsline {chapter}{\numberline {6}Future Work}{66}{chapter.6}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\@writefile{toc}{\contentsline {section}{\numberline {6.1}Single simulation per vehicle}{66}{section.6.1}} -\citation{BKRW17a} -\@writefile{toc}{\contentsline {section}{\numberline {6.2}Online model development, test and deployment}{67}{section.6.2}} -\@writefile{toc}{\contentsline {chapter}{\numberline {7}Conclusion}{69}{chapter.7}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\bibstyle{alpha} -\bibdata{src/bib/Literatur} -\@writefile{toc}{\contentsline {chapter}{Bibliography}{70}{chapter.7}} -\bibcite{DBLP:journals/aes/AmbrozKP05}{AKP05} -\bibcite{DAfMMO-RPG}{AT05} -\bibcite{BKRW17a}{BKRW17} -\bibcite{DBLP:journals/corr/0001R14a}{BR14} -\bibcite{Caltagirone:2002:AMM:771322.771339}{CKSW02} -\bibcite{Cozzi15}{Coz15} -\bibcite{DBLP:conf/infocom/2004}{DBL04} -\bibcite{DBLP:books/daglib/0067388}{Dij82} -\bibcite{dirksen2014three}{Dir14} -\bibcite{DBLP:conf/ijcai/DresnerS07}{DS07} -\bibcite{Jetty}{Ecl} -\bibcite{fette2011websocket}{FM11} -\bibcite{DBLP:reference/cg/Fortune04}{For04} -\bibcite{fowler2003patterns}{Fow03} -\bibcite{DBLP:conf/netgames/FiedlerWW02}{FWW02} -\bibcite{gamma1995design}{Gam95} -\bibcite{DBLP:conf/icmcs/GautierD98}{GD98} -\bibcite{SFS}{got} -\bibcite{DBLP:journals/tits/GlaserVMGN10}{GVM{$^{+}$}10} -\bibcite{DBLP:books/daglib/0021734}{HPS09} -\bibcite{DBLP:conf/netgames/KimCCKCY05}{KCC{$^{+}$}05} -\bibcite{DBLP:journals/cn/LeeKC05}{LKC05} -\bibcite{DBLP:conf/gi/MullerG04}{MG04} -\bibcite{DBLP:conf/vrst/NgSLL02}{NSLL02} -\bibcite{PGSQL}{Pos} -\bibcite{puntambekar2009data}{Pun09} -\bibcite{DBLP:journals/jfr/RauskolbBLMCEFGOSWHNDHMWBBGKR08}{RBL{$^{+}$}08} -\bibcite{DBLP:books/daglib/0002204}{Ree00} -\bibcite{STOMP}{sto} -\bibcite{TaylorEtAl2007}{TMD07} -\bibcite{DBLP:books/lib/TanenbaumW11}{TW11} -\bibcite{DBLP:journals/jfr/UrmsonABBBCDDGGGHHHKKLMMPPRRSSSSSWWZBBDLNSZSTDF08}{UAB{$^{+}$}08} -\bibcite{walls2015spring}{Wal15} diff --git a/docs/Thesis/Masterarbeit.bbl b/docs/Thesis/Masterarbeit.bbl deleted file mode 100644 index 1d6ea9e99fcf131fbbb290d44625c30ddd8f4888..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.bbl +++ /dev/null @@ -1,203 +0,0 @@ -\newcommand{\etalchar}[1]{$^{#1}$} -\begin{thebibliography}{BKRW17} - -\bibitem[AKP05]{DBLP:journals/aes/AmbrozKP05} -Miha Ambroz, S.~Krasna, and Ivan Prebil. -\newblock 3d road traffic situation simulation system. -\newblock {\em Advances in Engineering Software}, 36(2):77--86, 2005. - -\bibitem[AT05]{DAfMMO-RPG} -Marios Assiotis and Velin Tzanov. -\newblock A distributed architecture for massive multiplayer online - role-playing games. -\newblock May 2005. - -\bibitem[BKRW17]{BKRW17a} -Arvid Butting, Oliver Kautz, Bernhard Rumpe, and Andreas Wortmann. -\newblock {Architectural Programming with MontiArcAutomaton}. -\newblock In {\em In 12th International Conference on Software Engineering - Advances (ICSEA 2017)}, pages 213--218. IARIA XPS Press, May 2017. - -\bibitem[BR14]{DBLP:journals/corr/0001R14a} -Christian Berger and Bernhard Rumpe. -\newblock Engineering autonomous driving software. -\newblock {\em CoRR}, abs/1409.6579, 2014. - -\bibitem[CKSW02]{Caltagirone:2002:AMM:771322.771339} -Sergio Caltagirone, Matthew Keys, Bryan Schlief, and Mary~Jane Willshire. -\newblock Architecture for a massively multiplayer online role playing game - engine. -\newblock {\em J. Comput. Sci. Coll.}, 18(2):105--116, December 2002. - -\bibitem[Coz15]{Cozzi15} -Patrick Cozzi. -\newblock {\em {W}eb{GL} {I}nsights}. -\newblock CRC Press, July 2015. -\newblock \url{http://www.webglinsights.com/}. - -\bibitem[DBL04]{DBLP:conf/infocom/2004} -{\em Proceedings {IEEE} {INFOCOM} 2004, The 23rd Annual Joint Conference of the - {IEEE} Computer and Communications Societies, Hong Kong, China, March 7-11, - 2004}. {IEEE}, 2004. - -\bibitem[Dij82]{DBLP:books/daglib/0067388} -Edsger~W. Dijkstra. -\newblock {\em Selected Writings on Computing: {A} Personal Perspective}. -\newblock Texts and Monographs in Computer Science. Springer, 1982. - -\bibitem[Dir14]{dirksen2014three} -J.~Dirksen. -\newblock {\em Three.js Essentials}. -\newblock Community experience distilled. Packt Publishing, 2014. - -\bibitem[DS07]{DBLP:conf/ijcai/DresnerS07} -Kurt~M. Dresner and Peter Stone. -\newblock Sharing the road: Autonomous vehicles meet human drivers. -\newblock In {\em {IJCAI} 2007, Proceedings of the 20th International Joint - Conference on Artificial Intelligence, Hyderabad, India, January 6-12, 2007}, - pages 1263--1268, 2007. - -\bibitem[Ecl]{Jetty} -Eclipse. -\newblock {\em Jetty Web-server}. - -\bibitem[FM11]{fette2011websocket} -I.~Fette and A.~Melnikov. -\newblock The websocket protocol. -\newblock RFC 6455, RFC Editor, December 2011. -\newblock \url{http://www.rfc-editor.org/rfc/rfc6455.txt}. - -\bibitem[For04]{DBLP:reference/cg/Fortune04} -Steven Fortune. -\newblock Voronoi diagrams and delaunay triangulations. -\newblock In {\em Handbook of Discrete and Computational Geometry, Second - Edition.}, pages 513--528. 2004. - -\bibitem[Fow03]{fowler2003patterns} -Martin Fowler. -\newblock {\em Patterns of enterprise application architecture}. -\newblock Addison-Wesley, Boston, 2003. - -\bibitem[FWW02]{DBLP:conf/netgames/FiedlerWW02} -Stefan~A. Fiedler, Michael Wallner, and Michael Weber. -\newblock A communication architecture for massive multiplayer games. -\newblock In {\em Proceedings of the 1st Workshop on Network and System Support - for Games, {NETGAMES} 2002, Braunschweig, Germany, April 16-17, 2002, 2003}, - pages 14--22, 2002. - -\bibitem[Gam95]{gamma1995design} -Erich Gamma. -\newblock {\em Design patterns : elements of reusable object-oriented - software}. -\newblock Addison-Wesley, Reading, Mass, 1995. - -\bibitem[GD98]{DBLP:conf/icmcs/GautierD98} -Laurent Gautier and Christophe Diot. -\newblock Design and evaluation of mimaze, a multi-player game on the internet. -\newblock In {\em {IEEE} International Conference on Multimedia Computing and - Systems, {ICMCS} 1998, Austin, Texas, USA, June 28 - July 1, 1998}, pages - 233--236, 1998. - -\bibitem[got]{SFS} -gotoAndPlay(). -\newblock {\em SmartFox Server 2X}. - -\bibitem[GVM{\etalchar{+}}10]{DBLP:journals/tits/GlaserVMGN10} -Sebastien Glaser, Benoit Vanholme, Sa{\"{\i}}d Mammar, Dominique Gruyer, and - Lydie Nouveliere. -\newblock Maneuver-based trajectory planning for highly autonomous vehicles on - real road with traffic and driver interaction. -\newblock {\em {IEEE} Trans. Intelligent Transportation Systems}, - 11(3):589--606, 2010. - -\bibitem[HPS09]{DBLP:books/daglib/0021734} -George~T. Heineman, Gary Pollice, and Stanley~M. Selkow. -\newblock {\em Algorithms in a nutshell - a desktop quick reference}. -\newblock O'Reilly, 2009. - -\bibitem[KCC{\etalchar{+}}05]{DBLP:conf/netgames/KimCCKCY05} -Jaecheol Kim, Jaeyoung Choi, Dukhyun Chang, Taekyoung Kwon, Yanghee Choi, and - Eungsu Yuk. -\newblock Traffic characteristics of a massively multi-player online role - playing game. -\newblock In {\em Proceedings of the 4th Workshop on Network and System Support - for Games, {NETGAMES} 2005, Hawthorne, New York, USA, October 10-11, 2005}, - pages 1--8, 2005. - -\bibitem[LKC05]{DBLP:journals/cn/LeeKC05} -Kang{-}Won Lee, Bong{-}Jun Ko, and Seraphin~B. Calo. -\newblock Adaptive server selection for large scale interactive online games. -\newblock {\em Computer Networks}, 49(1):84--102, 2005. - -\bibitem[MG04]{DBLP:conf/gi/MullerG04} -Jens M{\"{u}}ller and Sergei Gorlatch. -\newblock A scalable architecture for multiplayer computer games. -\newblock In {\em {INFORMATIK} 2004 - Informatik verbindet, Band 1, - Beitr{\"{a}}ge der 34. Jahrestagung der Gesellschaft f{\"{u}}r Informatik - e.V. (GI), Ulm, 20.-24. September 2004}, pages 154--158, 2004. - -\bibitem[NSLL02]{DBLP:conf/vrst/NgSLL02} -Beatrice Ng, Antonio Si, Rynson W.~H. Lau, and Frederick W.~B. Li. -\newblock A multi-server architecture for distributed virtual walkthrough. -\newblock In {\em Proceedings of the {ACM} Symposium on Virtual Reality - Software and Technology, {VRST} 2002, Hong Kong, China, November 11-13, - 2002}, pages 163--170, 2002. - -\bibitem[Pos]{PGSQL} -PostgreSQL. -\newblock {\em PostgreSQL}. - -\bibitem[Pun09]{puntambekar2009data} -A.A. Puntambekar. -\newblock {\em Data Structures And Algorithms}. -\newblock Technical Publications, 2009. - -\bibitem[RBL{\etalchar{+}}08]{DBLP:journals/jfr/RauskolbBLMCEFGOSWHNDHMWBBGKR08} -Fred~W. Rauskolb, Kai Berger, Christian Lipski, Marcus~A. Magnor, Karsten - Cornelsen, Jan Effertz, Thomas Form, Fabian Graefe, Sebastian Ohl, Walter - Schumacher, J{\"{o}}rn{-}Marten Wille, Peter Hecker, Tobias Nothdurft, - Michael Doering, Kai Homeier, Johannes Morgenroth, Lars~C. Wolf, Christian - Basarke, Christian Berger, Tim G{\"{u}}lke, Felix Klose, and Bernhard Rumpe. -\newblock Caroline: An autonomously driving vehicle for urban environments. -\newblock {\em J. Field Robotics}, 25(9):674--724, 2008. - -\bibitem[Ree00]{DBLP:books/daglib/0002204} -George Reese. -\newblock {\em Database programming with {JDBC} and Java {(2.} ed.)}. -\newblock O'Reilly, 2000. - -\bibitem[sto]{STOMP} -stomp. -\newblock {\em Simple (or Streaming) Text Orientated Messaging Protocol}. - -\bibitem[TMD07]{TaylorEtAl2007} -Richard~N. Taylor, Nenad Medvidovic, and Eric~M. Dashofy. -\newblock {\em Software Architecture: Foundations, Theory and Practice}. -\newblock Addison-Wesley, 2007. - -\bibitem[TW11]{DBLP:books/lib/TanenbaumW11} -Andrew~S. Tanenbaum and David Wetherall. -\newblock {\em Computer networks, 5th Edition}. -\newblock Pearson, 2011. - -\bibitem[UAB{\etalchar{+}}08]{DBLP:journals/jfr/UrmsonABBBCDDGGGHHHKKLMMPPRRSSSSSWWZBBDLNSZSTDF08} -Chris Urmson, Joshua Anhalt, Drew Bagnell, Christopher~R. Baker, Robert - Bittner, M.~N. Clark, John~M. Dolan, Dave Duggins, Tugrul Galatali, - Christopher Geyer, Michele Gittleman, Sam Harbaugh, Martial Hebert, Thomas~M. - Howard, Sascha Kolski, Alonzo Kelly, Maxim Likhachev, Matthew McNaughton, - Nick Miller, Kevin~M. Peterson, Brian Pilnick, Raj Rajkumar, Paul~E. Rybski, - Bryan Salesky, Young{-}Woo Seo, Sanjiv Singh, Jarrod~M. Snider, Anthony - Stentz, William Whittaker, Ziv Wolkowicki, Jason Ziglar, Hong Bae, Thomas - Brown, Daniel Demitrish, Bakhtiar Litkouhi, Jim Nickolaou, Varsha Sadekar, - Wende Zhang, Joshua Struble, Michael Taylor, Michael Darms, and Dave - Ferguson. -\newblock Autonomous driving in urban environments: Boss and the urban - challenge. -\newblock {\em J. Field Robotics}, 25(8):425--466, 2008. - -\bibitem[Wal15]{walls2015spring} -Craig Walls. -\newblock {\em Spring in action}. -\newblock Manning Publications, Shelter Island, N.Y, 2015. - -\end{thebibliography} diff --git a/docs/Thesis/Masterarbeit.blg b/docs/Thesis/Masterarbeit.blg deleted file mode 100644 index 43b2ec9ccd430953de30d6056c0f1b682d6e1636..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.blg +++ /dev/null @@ -1,50 +0,0 @@ -This is BibTeX, Version 0.99d (TeX Live 2016/Debian) -Capacity: max_strings=100000, hash_size=100000, hash_prime=85009 -The top-level auxiliary file: ./Masterarbeit.aux -The style file: alpha.bst -Database file #1: src/bib/Literatur.bib -Warning--to sort, need editor, organization, or key in DBLP:conf/infocom/2004 -Warning--empty booktitle in DAfMMO-RPG -Warning--empty publisher in DBLP:reference/cg/Fortune04 -You've used 33 entries, - 2543 wiz_defined-function locations, - 756 strings with 11529 characters, -and the built_in function-call counts, 14387 in all, are: -= -- 1362 -> -- 843 -< -- 18 -+ -- 308 -- -- 303 -* -- 1075 -:= -- 2359 -add.period$ -- 100 -call.type$ -- 33 -change.case$ -- 245 -chr.to.int$ -- 33 -cite$ -- 37 -duplicate$ -- 562 -empty$ -- 982 -format.name$ -- 336 -if$ -- 2922 -int.to.chr$ -- 1 -int.to.str$ -- 0 -missing$ -- 38 -newline$ -- 165 -num.names$ -- 84 -pop$ -- 300 -preamble$ -- 1 -purify$ -- 294 -quote$ -- 0 -skip$ -- 442 -stack$ -- 0 -substring$ -- 626 -swap$ -- 108 -text.length$ -- 18 -text.prefix$ -- 13 -top$ -- 0 -type$ -- 218 -warning$ -- 3 -while$ -- 111 -width$ -- 38 -write$ -- 409 -(There were 3 warnings) diff --git a/docs/Thesis/Masterarbeit.blx b/docs/Thesis/Masterarbeit.blx deleted file mode 100644 index f529072c3a26c347ccef327c32b96c83608e16ef..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.blx +++ /dev/null @@ -1,246 +0,0 @@ -\relax -\providecommand\hyper@newdestlabel[2]{} -\providecommand\HyperFirstAtBeginDocument{\AtBeginDocument} -\HyperFirstAtBeginDocument{\ifx\hyper@anchor\@undefined -\global\let\oldcontentsline\contentsline -\gdef\contentsline#1#2#3#4{\oldcontentsline{#1}{#2}{#3}} -\global\let\oldnewlabel\newlabel -\gdef\newlabel#1#2{\newlabelxx{#1}#2} -\gdef\newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}} -\AtEndDocument{\ifx\hyper@anchor\@undefined -\let\contentsline\oldcontentsline -\let\newlabel\oldnewlabel -\fi} -\fi} -\global\let\hyper@last\relax -\gdef\HyperFirstAtBeginDocument#1{#1} -\providecommand\HyField@AuxAddToFields[1]{} -\providecommand\HyField@AuxAddToCoFields[2]{} -\citation{Caltagirone:2002:AMM:771322.771339} -\citation{Cozzi15} -\citation{DBLP:journals/corr/0001R14a} -\citation{DBLP:journals/jfr/UrmsonABBBCDDGGGHHHKKLMMPPRRSSSSSWWZBBDLNSZSTDF08} -\citation{DBLP:journals/jfr/RauskolbBLMCEFGOSWHNDHMWBBGKR08} -\citation{DBLP:journals/aes/AmbrozKP05} -\@writefile{toc}{\contentsline {chapter}{\numberline {1}Introduction}{1}{chapter.1}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\citation{DBLP:conf/vrst/NgSLL02} -\citation{DBLP:conf/infocom/2004} -\@writefile{lof}{\contentsline {figure}{\numberline {1.1}{\ignorespaces Player grouping and update multicasting\relax }}{3}{figure.caption.3}} -\providecommand*\caption@xref[2]{\@setref\relax\@undefined{#1}} -\newlabel{fig:Multicast}{{1.1}{3}{Player grouping and update multicasting\relax }{figure.caption.3}{}} -\@writefile{toc}{\contentsline {chapter}{\numberline {2}Preliminaries}{5}{chapter.2}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\@writefile{toc}{\contentsline {section}{\numberline {2.1}Massive multiplayer online gaming}{5}{section.2.1}} -\@writefile{toc}{\contentsline {section}{\numberline {2.2}Area of Interest}{6}{section.2.2}} -\newlabel{sec:aoi}{{2.2}{6}{Area of Interest}{section.2.2}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.1}{\ignorespaces Area of Interest: circular and hexagonal representation\relax }}{6}{figure.caption.4}} -\newlabel{fig:AreaOfInterest}{{2.1}{6}{Area of Interest: circular and hexagonal representation\relax }{figure.caption.4}{}} -\citation{DBLP:books/lib/TanenbaumW11} -\citation{DBLP:conf/icmcs/GautierD98} -\@writefile{toc}{\contentsline {section}{\numberline {2.3}Architectures}{7}{section.2.3}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.2}{\ignorespaces Peer-to-peer and Client/Server architectures\relax }}{7}{figure.caption.5}} -\newlabel{fig:archs}{{2.2}{7}{Peer-to-peer and Client/Server architectures\relax }{figure.caption.5}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.3.1}Peer-to-peer}{7}{subsection.2.3.1}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.3.2}Client/server}{8}{subsection.2.3.2}} -\citation{DBLP:conf/netgames/KimCCKCY05} -\citation{TaylorEtAl2007} -\@writefile{toc}{\contentsline {subsubsection}{Multi-tier architecture}{9}{section*.6}} -\@writefile{toc}{\contentsline {section}{\numberline {2.4}Distributing mechanisms}{9}{section.2.4}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.3}{\ignorespaces Three-tier architecture\relax }}{10}{figure.caption.7}} -\newlabel{fig:MultitierArch}{{2.3}{10}{Three-tier architecture\relax }{figure.caption.7}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.1}Sharding}{10}{subsection.2.4.1}} -\citation{DBLP:books/lib/TanenbaumW11} -\@writefile{lof}{\contentsline {figure}{\numberline {2.4}{\ignorespaces Sharding approach\relax }}{11}{figure.caption.8}} -\newlabel{fig:sharding}{{2.4}{11}{Sharding approach\relax }{figure.caption.8}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.2}Cloning}{11}{subsection.2.4.2}} -\citation{DBLP:journals/cn/LeeKC05} -\@writefile{lof}{\contentsline {figure}{\numberline {2.5}{\ignorespaces Cloning approach\relax }}{12}{figure.caption.9}} -\newlabel{fig:cloning}{{2.5}{12}{Cloning approach\relax }{figure.caption.9}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.3}Zoning}{12}{subsection.2.4.3}} -\newlabel{ssec:Zoning}{{2.4.3}{12}{Zoning}{subsection.2.4.3}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.6}{\ignorespaces Zoning approach\relax }}{13}{figure.caption.10}} -\newlabel{fig:zoning}{{2.6}{13}{Zoning approach\relax }{figure.caption.10}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.4}Instancing}{13}{subsection.2.4.4}} -\citation{DBLP:conf/gi/MullerG04} -\@writefile{toc}{\contentsline {section}{\numberline {2.5}Advanced distributed architectures}{14}{section.2.5}} -\newlabel{AdvancedDistributedArchitectures}{{2.5}{14}{Advanced distributed architectures}{section.2.5}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.5.1}Proxy-server architecture}{14}{subsection.2.5.1}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.7}{\ignorespaces Proxy-server architecture\relax }}{15}{figure.caption.11}} -\newlabel{fig:ProxyServer}{{2.7}{15}{Proxy-server architecture\relax }{figure.caption.11}{}} -\citation{DAfMMO-RPG} -\citation{fowler2003patterns} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.5.2}Distributed architecture combined with zoning technique}{16}{subsection.2.5.2}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.8}{\ignorespaces Distributed architecture based on zoning approach\relax }}{16}{figure.caption.12}} -\newlabel{fig:DistributedZoning}{{2.8}{16}{Distributed architecture based on zoning approach\relax }{figure.caption.12}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {2.9}{\ignorespaces Publish-subscribe pattern\relax }}{17}{figure.caption.13}} -\newlabel{fig:PublishSubscribe}{{2.9}{17}{Publish-subscribe pattern\relax }{figure.caption.13}{}} -\citation{gamma1995design} -\@writefile{toc}{\contentsline {section}{\numberline {2.6}Model-View-Controller pattern}{18}{section.2.6}} -\citation{walls2015spring} -\citation{DBLP:books/daglib/0067388} -\@writefile{lof}{\contentsline {figure}{\numberline {2.10}{\ignorespaces Model-View-Controller\relax }}{19}{figure.caption.14}} -\newlabel{fig:MVC}{{2.10}{19}{Model-View-Controller\relax }{figure.caption.14}{}} -\citation{DBLP:books/lib/TanenbaumW11} -\citation{fette2011websocket} -\citation{Cozzi15} -\citation{SFS} -\citation{Jetty} -\@writefile{toc}{\contentsline {chapter}{\numberline {3}Technical Requisites}{20}{chapter.3}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\@writefile{toc}{\contentsline {section}{\numberline {3.1}SmartFoxServer}{20}{section.3.1}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.1}Web Server}{20}{subsection.3.1.1}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.2}Web Services}{21}{subsection.3.1.2}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.3}Data serialization}{21}{subsection.3.1.3}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.4}Scope Management}{21}{subsection.3.1.4}} -\citation{dirksen2014three} -\@writefile{lof}{\contentsline {figure}{\numberline {3.1}{\ignorespaces SmartFoxServer architecture\relax }}{22}{figure.caption.15}} -\newlabel{fig:SFS}{{3.1}{22}{SmartFoxServer architecture\relax }{figure.caption.15}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1.5}Data access and server monitoring}{22}{subsection.3.1.5}} -\@writefile{toc}{\contentsline {section}{\numberline {3.2}ThreeJS}{22}{section.3.2}} -\citation{PGSQL} -\@writefile{toc}{\contentsline {section}{\numberline {3.3}PostgreSQL database}{23}{section.3.3}} -\@writefile{toc}{\contentsline {chapter}{\numberline {4}Simulation Platform}{24}{chapter.4}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\newlabel{chap:simulationPlatform}{{4}{24}{Simulation Platform}{chapter.4}{}} -\@writefile{toc}{\contentsline {section}{\numberline {4.1}Challenges}{24}{section.4.1}} -\citation{DBLP:books/lib/TanenbaumW11} -\citation{TaylorEtAl2007} -\@writefile{toc}{\contentsline {section}{\numberline {4.2}Architecture}{25}{section.4.2}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.1}{\ignorespaces Architecture overview\relax }}{26}{figure.caption.16}} -\newlabel{fig:Overview}{{4.1}{26}{Architecture overview\relax }{figure.caption.16}{}} -\@writefile{toc}{\contentsline {section}{\numberline {4.3}Basic work-flow}{26}{section.4.3}} -\newlabel{sec:WorkFlow}{{4.3}{26}{Basic work-flow}{section.4.3}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.2}{\ignorespaces Selecting simulation scenario\relax }}{27}{figure.caption.17}} -\newlabel{fig:GuiMenu}{{4.2}{27}{Selecting simulation scenario\relax }{figure.caption.17}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.3}{\ignorespaces Notification for processed scenario simulation\relax }}{28}{figure.caption.18}} -\newlabel{fig:SimDurationGui}{{4.3}{28}{Notification for processed scenario simulation\relax }{figure.caption.18}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.3.1}Zone level}{28}{subsection.4.3.1}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.4}{\ignorespaces Visualization of simulation scenario\relax }}{29}{figure.caption.19}} -\newlabel{fig:SwitchCar}{{4.4}{29}{Visualization of simulation scenario\relax }{figure.caption.19}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.1}Framework extension by means of inheritance}{30}{lstlisting.4.1}} -\newlabel{lst:zoneInit}{{4.2}{30}{Zone initialization method}{lstlisting.4.2}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.2}Zone initialization method}{30}{lstlisting.4.2}} -\newlabel{lst:zoneRequests}{{4.3}{31}{Zone client request handling}{lstlisting.4.3}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.3}Zone client request handling}{31}{lstlisting.4.3}} -\newlabel{lst:scenarioLoad}{{4.4}{31}{Scenario loading}{lstlisting.4.4}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.4}Scenario loading}{31}{lstlisting.4.4}} -\newlabel{lst:fileUploadListener}{{4.5}{32}{Server event handling}{lstlisting.4.5}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.5}Server event handling}{32}{lstlisting.4.5}} -\newlabel{lst:zoneInternalMessaging}{{4.6}{33}{Zone internal messaging handling}{lstlisting.4.6}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.6}Zone internal messaging handling}{33}{lstlisting.4.6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.3.2}Room level}{33}{subsection.4.3.2}} -\newlabel{lst:roomInit}{{4.7}{34}{Zone internal messaging handling}{lstlisting.4.7}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.7}Zone internal messaging handling}{34}{lstlisting.4.7}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.5}{\ignorespaces SmartFox extension hot deployment\relax }}{35}{figure.caption.20}} -\newlabel{fig:sfsExtensionDeployment}{{4.5}{35}{SmartFox extension hot deployment\relax }{figure.caption.20}{}} -\newlabel{lst:userJoin}{{4.8}{36}{User join event handling}{lstlisting.4.8}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.8}User join event handling}{36}{lstlisting.4.8}} -\newlabel{lst:nextFrame}{{4.9}{37}{Room client request handling}{lstlisting.4.9}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.9}Room client request handling}{37}{lstlisting.4.9}} -\newlabel{lst:userLeave}{{4.10}{37}{User leave event handling}{lstlisting.4.10}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.10}User leave event handling}{37}{lstlisting.4.10}} -\newlabel{lst:roomDestroy}{{4.11}{38}{Releasing room resources upon destruction}{lstlisting.4.11}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.11}Releasing room resources upon destruction}{38}{lstlisting.4.11}} -\@writefile{toc}{\contentsline {section}{\numberline {4.4}Virtual World}{38}{section.4.4}} -\newlabel{sec:VirtualWorld}{{4.4}{38}{Virtual World}{section.4.4}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.6}{\ignorespaces Database entity relationship diagram\relax }}{39}{figure.caption.21}} -\newlabel{fig:ERD}{{4.6}{39}{Database entity relationship diagram\relax }{figure.caption.21}{}} -\citation{DBLP:conf/netgames/FiedlerWW02} -\citation{DBLP:reference/cg/Fortune04} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.4.1}Zoning approach}{40}{subsection.4.4.1}} -\newlabel{ssec:ZoningApproach}{{4.4.1}{40}{Zoning approach}{subsection.4.4.1}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.7}{\ignorespaces World map split into sectors\relax }}{41}{figure.caption.22}} -\newlabel{fig:SquareShapeSectors}{{4.7}{41}{World map split into sectors\relax }{figure.caption.22}{}} -\citation{DBLP:conf/ijcai/DresnerS07} -\citation{DBLP:journals/tits/GlaserVMGN10} -\citation{puntambekar2009data} -\@writefile{toc}{\contentsline {section}{\numberline {4.5}Path Finder}{42}{section.4.5}} -\newlabel{sec:PathFinder}{{4.5}{42}{Path Finder}{section.4.5}{}} -\citation{DBLP:books/daglib/0021734} -\newlabel{lst:entryNodes}{{4.12}{43}{Entry node table structure}{lstlisting.4.12}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.12}Entry node table structure}{43}{lstlisting.4.12}} -\newlabel{lst:paths}{{4.13}{44}{Path table structure}{lstlisting.4.13}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.13}Path table structure}{44}{lstlisting.4.13}} -\citation{DBLP:books/daglib/0002204} -\@writefile{lof}{\contentsline {figure}{\numberline {4.8}{\ignorespaces Path-finding procedure\relax }}{45}{figure.caption.23}} -\newlabel{fig:PathFinding}{{4.8}{45}{Path-finding procedure\relax }{figure.caption.23}{}} -\@writefile{toc}{\contentsline {section}{\numberline {4.6}Database optimization}{45}{section.4.6}} -\newlabel{lst:dbEntryNodes}{{4.14}{46}{Entry nodes batch insert transaction with shared connection}{lstlisting.4.14}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.14}Entry nodes batch insert transaction with shared connection}{46}{lstlisting.4.14}} -\@writefile{toc}{\contentsline {section}{\numberline {4.7}Web Communication}{47}{section.4.7}} -\newlabel{sec:WebCommunication}{{4.7}{47}{Web Communication}{section.4.7}{}} -\newlabel{lst:serverAdapterConnection}{{4.15}{47}{Server adapter connection establishing}{lstlisting.4.15}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.15}Server adapter connection establishing}{47}{lstlisting.4.15}} -\newlabel{lst:serverAdapterRequest}{{4.16}{48}{Server adapter sending extension request}{lstlisting.4.16}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.16}Server adapter sending extension request}{48}{lstlisting.4.16}} -\newlabel{lst:serverAdapterAPI}{{4.17}{48}{Server adapter extension requests public API}{lstlisting.4.17}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.17}Server adapter extension requests public API}{48}{lstlisting.4.17}} -\citation{STOMP} -\newlabel{lst:webService}{{4.18}{49}{WebService pulic API}{lstlisting.4.18}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.18}WebService pulic API}{49}{lstlisting.4.18}} -\@writefile{toc}{\contentsline {section}{\numberline {4.8}Simulation}{50}{section.4.8}} -\newlabel{sec:Simulation}{{4.8}{50}{Simulation}{section.4.8}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.8.1}Simulation Controller}{51}{subsection.4.8.1}} -\newlabel{lst:simCtrl}{{4.19}{51}{Simulation controller storing frame data in mediator}{lstlisting.4.19}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.19}Simulation controller storing frame data in mediator}{51}{lstlisting.4.19}} -\citation{gamma1995design} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.8.2}Mediator}{52}{subsection.4.8.2}} -\newlabel{lst:simBuff}{{4.20}{52}{Simulation buffer}{lstlisting.4.20}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.20}Simulation buffer}{52}{lstlisting.4.20}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.8.3}Scenarios}{53}{subsection.4.8.3}} -\newlabel{ssec:Scenarios}{{4.8.3}{53}{Scenarios}{subsection.4.8.3}{}} -\newlabel{lst:scenDB}{{4.21}{53}{Scenario table}{lstlisting.4.21}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.21}Scenario table}{53}{lstlisting.4.21}} -\newlabel{lst:trackDB}{{4.22}{53}{Track table}{lstlisting.4.22}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.22}Track table}{53}{lstlisting.4.22}} -\newlabel{lst:trackSec}{{4.23}{54}{Track section table}{lstlisting.4.23}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.23}Track section table}{54}{lstlisting.4.23}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.9}{\ignorespaces Scenario listing and uploading\relax }}{55}{figure.caption.24}} -\newlabel{fig:scenSeq}{{4.9}{55}{Scenario listing and uploading\relax }{figure.caption.24}{}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.8.4}Synchronization and Visualization}{56}{subsection.4.8.4}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.10}{\ignorespaces Simulation and visualization\relax }}{56}{figure.caption.25}} -\newlabel{fig:simVis}{{4.10}{56}{Simulation and visualization\relax }{figure.caption.25}{}} -\newlabel{lst:dmHandlers}{{4.24}{57}{DataModel handler registering}{lstlisting.4.24}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.24}DataModel handler registering}{57}{lstlisting.4.24}} -\newlabel{lst:dmHandlePromises}{{4.25}{58}{DataModel handlers execution}{lstlisting.4.25}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.25}DataModel handlers execution}{58}{lstlisting.4.25}} -\newlabel{lst:dmInit}{{4.26}{58}{DataModel after handler execution}{lstlisting.4.26}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.26}DataModel after handler execution}{58}{lstlisting.4.26}} -\citation{gamma1995design} -\newlabel{lst:dmVisCache}{{4.27}{59}{DataModel visualization and caching mechanism}{lstlisting.4.27}{}} -\@writefile{lol}{\contentsline {lstlisting}{\numberline {4.27}DataModel visualization and caching mechanism}{59}{lstlisting.4.27}} -\@writefile{toc}{\contentsline {section}{\numberline {4.9}Configuration}{60}{section.4.9}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.11}{\ignorespaces Zone configuration\relax }}{60}{figure.caption.26}} -\newlabel{fig:zoneConfig}{{4.11}{60}{Zone configuration\relax }{figure.caption.26}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.12}{\ignorespaces Web server configuration\relax }}{61}{figure.caption.27}} -\newlabel{fig:webServerConfig}{{4.12}{61}{Web server configuration\relax }{figure.caption.27}{}} -\@writefile{toc}{\contentsline {section}{\numberline {4.10}Security}{61}{section.4.10}} -\@writefile{lof}{\contentsline {figure}{\numberline {4.13}{\ignorespaces Client authentication process\relax }}{62}{figure.caption.28}} -\newlabel{fig:Authentication}{{4.13}{62}{Client authentication process\relax }{figure.caption.28}{}} -\@writefile{toc}{\contentsline {chapter}{\numberline {5}Evaluation}{63}{chapter.5}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\newlabel{chap:evaluation}{{5}{63}{Evaluation}{chapter.5}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {5.1}{\ignorespaces Server resource usage at login phase\relax }}{64}{figure.caption.29}} -\newlabel{fig:performance1}{{5.1}{64}{Server resource usage at login phase\relax }{figure.caption.29}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {5.2}{\ignorespaces Server resource usage at simulation phase\relax }}{65}{figure.caption.30}} -\newlabel{fig:performance2}{{5.2}{65}{Server resource usage at simulation phase\relax }{figure.caption.30}{}} -\@writefile{lof}{\contentsline {figure}{\numberline {5.3}{\ignorespaces Server messaging traffic\relax }}{65}{figure.caption.31}} -\newlabel{fig:traffic}{{5.3}{65}{Server messaging traffic\relax }{figure.caption.31}{}} -\@writefile{toc}{\contentsline {chapter}{\numberline {6}Future Work}{66}{chapter.6}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\@writefile{toc}{\contentsline {section}{\numberline {6.1}Single simulation per vehicle}{66}{section.6.1}} -\citation{BKRW17a} -\@writefile{toc}{\contentsline {section}{\numberline {6.2}Online model development, test and deployment}{67}{section.6.2}} -\@writefile{toc}{\contentsline {chapter}{\numberline {7}Conclusion}{69}{chapter.7}} -\@writefile{lof}{\addvspace {10\p@ }} -\@writefile{lot}{\addvspace {10\p@ }} -\bibstyle{alpha} -\bibdata{src/bib/Literatur} -\@writefile{toc}{\contentsline {chapter}{Bibliography}{70}{chapter.7}} diff --git a/docs/Thesis/Masterarbeit.log b/docs/Thesis/Masterarbeit.log deleted file mode 100644 index 0fd70c6a5956946ab56d5559d4c225c4229fc42b..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.log +++ /dev/null @@ -1,1436 +0,0 @@ -This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2017.5.16) 5 MAR 2018 11:27 -entering extended mode - restricted \write18 enabled. - %&-line parsing enabled. -**./Masterarbeit -(./Masterarbeit.tex -LaTeX2e <2016/03/31> patch level 3 -Babel <3.9r> and hyphenation patterns for 83 language(s) loaded. -(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls -Document Class: report 2014/09/29 v1.4h Standard LaTeX document class -(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo -File: size11.clo 2014/09/29 v1.4h Standard LaTeX file (size option) -) -\c@part=\count79 -\c@chapter=\count80 -\c@section=\count81 -\c@subsection=\count82 -\c@subsubsection=\count83 -\c@paragraph=\count84 -\c@subparagraph=\count85 -\c@figure=\count86 -\c@table=\count87 -\abovecaptionskip=\skip41 -\belowcaptionskip=\skip42 -\bibindent=\dimen102 -) -(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty -Package: graphicx 2014/10/28 v1.0g Enhanced LaTeX Graphics (DPC,SPQR) - -(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty -Package: keyval 2014/10/28 v1.15 key=value parser (DPC) -\KV@toks@=\toks14 -) -(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty -Package: graphics 2016/07/10 v1.0t Standard LaTeX Graphics (DPC,SPQR) - -(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty -Package: trig 2016/01/03 v1.10 sin cos tan (DPC) -) -(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg -File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration -) -Package graphics Info: Driver file: pdftex.def on input line 99. - -(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def -File: pdftex.def 2016/07/10 v0.06j Graphics/color for pdfTeX - -(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty -Package: infwarerr 2016/05/16 v1.4 Providing info/warning/error messages (HO) -) -(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty -Package: ltxcmds 2016/05/16 v1.23 LaTeX kernel commands for general use (HO) -) -\Gread@gobject=\count88 -)) -\Gin@req@height=\dimen103 -\Gin@req@width=\dimen104 -) -(/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty -Package: inputenc 2015/03/17 v1.2c Input encoding file -\inpenc@prehook=\toks15 -\inpenc@posthook=\toks16 - -(/usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def -File: utf8x.def 2004/10/17 UCS: Input encoding UTF-8 -)) -(/usr/share/texlive/texmf-dist/tex/latex/ucs/ucs.sty -Package: ucs 2013/05/11 v2.2 UCS: Unicode input support - -(/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uni-global.def -File: uni-global.def 2013/05/13 UCS: Unicode global data -) -\uc@secondtry=\count89 -\uc@combtoks=\toks17 -\uc@combtoksb=\toks18 -\uc@temptokena=\toks19 -) -(/usr/share/texlive/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty -Package: fancyvrb 2008/02/07 - -Style option: `fancyvrb' v2.7a, with DG/SPQR fixes, and firstline=lastline fix -<2008/02/07> (tvz) -\FV@CodeLineNo=\count90 -\FV@InFile=\read1 -\FV@TabBox=\box26 -\c@FancyVerbLine=\count91 -\FV@StepNumber=\count92 -\FV@OutFile=\write3 -) (/usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty -Package: courier 2005/04/12 PSNFSS-v9.2a (WaS) -) (/usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty -Package: helvet 2005/04/12 PSNFSS-v9.2a (WaS) -) -(/usr/share/texlive/texmf-dist/tex/latex/pgf/frontendlayer/tikz.sty -(/usr/share/texlive/texmf-dist/tex/latex/pgf/basiclayer/pgf.sty -(/usr/share/texlive/texmf-dist/tex/latex/pgf/utilities/pgfrcs.sty -(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-common.tex -\pgfutil@everybye=\toks20 -\pgfutil@tempdima=\dimen105 -\pgfutil@tempdimb=\dimen106 - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-common-lists.t -ex)) (/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-latex.def -\pgfutil@abb=\box27 -(/usr/share/texlive/texmf-dist/tex/latex/ms/everyshi.sty -Package: everyshi 2001/05/15 v3.00 EveryShipout Package (MS) -)) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfrcs.code.tex -Package: pgfrcs 2015/08/07 v3.0.1a (rcs-revision 1.31) -)) -Package: pgf 2015/08/07 v3.0.1a (rcs-revision 1.15) - -(/usr/share/texlive/texmf-dist/tex/latex/pgf/basiclayer/pgfcore.sty -(/usr/share/texlive/texmf-dist/tex/latex/pgf/systemlayer/pgfsys.sty -(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsys.code.tex -Package: pgfsys 2014/07/09 v3.0.1a (rcs-revision 1.48) - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex -\pgfkeys@pathtoks=\toks21 -\pgfkeys@temptoks=\toks22 - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeysfiltered.code.t -ex -\pgfkeys@tmptoks=\toks23 -)) -\pgf@x=\dimen107 -\pgf@y=\dimen108 -\pgf@xa=\dimen109 -\pgf@ya=\dimen110 -\pgf@xb=\dimen111 -\pgf@yb=\dimen112 -\pgf@xc=\dimen113 -\pgf@yc=\dimen114 -\w@pgf@writea=\write4 -\r@pgf@reada=\read2 -\c@pgf@counta=\count93 -\c@pgf@countb=\count94 -\c@pgf@countc=\count95 -\c@pgf@countd=\count96 -\t@pgf@toka=\toks24 -\t@pgf@tokb=\toks25 -\t@pgf@tokc=\toks26 - (/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgf.cfg -File: pgf.cfg 2008/05/14 (rcs-revision 1.7) -) -Driver file for pgf: pgfsys-pdftex.def - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-pdftex.def -File: pgfsys-pdftex.def 2014/10/11 (rcs-revision 1.35) - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-common-pdf.de -f -File: pgfsys-common-pdf.def 2013/10/10 (rcs-revision 1.13) -))) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsyssoftpath.code. -tex -File: pgfsyssoftpath.code.tex 2013/09/09 (rcs-revision 1.9) -\pgfsyssoftpath@smallbuffer@items=\count97 -\pgfsyssoftpath@bigbuffer@items=\count98 -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsysprotocol.code. -tex -File: pgfsysprotocol.code.tex 2006/10/16 (rcs-revision 1.4) -)) (/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty -Package: xcolor 2016/05/11 v2.12 LaTeX color extensions (UK) - -(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg -File: color.cfg 2016/01/02 v1.6 sample color configuration -) -Package xcolor Info: Driver file: pdftex.def on input line 225. -Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1348. -Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1352. -Package xcolor Info: Model `RGB' extended on input line 1364. -Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1366. -Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1367. -Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1368. -Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1369. -Package xcolor Info: Model `Gray' substituted by `gray' on input line 1370. -Package xcolor Info: Model `wave' substituted by `hsb' on input line 1371. -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcore.code.tex -Package: pgfcore 2010/04/11 v3.0.1a (rcs-revision 1.7) - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmath.code.tex -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathcalc.code.tex -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathutil.code.tex) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathparser.code.tex -\pgfmath@dimen=\dimen115 -\pgfmath@count=\count99 -\pgfmath@box=\box28 -\pgfmath@toks=\toks27 -\pgfmath@stack@operand=\toks28 -\pgfmath@stack@operation=\toks29 -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.code.tex -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.basic.code -.tex) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.trigonomet -ric.code.tex) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.random.cod -e.tex) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.comparison -.code.tex) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.base.code. -tex) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.round.code -.tex) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.misc.code. -tex) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.integerari -thmetics.code.tex))) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfloat.code.tex -\c@pgfmathroundto@lastzeros=\count100 -)) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepoints.code.te -x -File: pgfcorepoints.code.tex 2013/10/07 (rcs-revision 1.27) -\pgf@picminx=\dimen116 -\pgf@picmaxx=\dimen117 -\pgf@picminy=\dimen118 -\pgf@picmaxy=\dimen119 -\pgf@pathminx=\dimen120 -\pgf@pathmaxx=\dimen121 -\pgf@pathminy=\dimen122 -\pgf@pathmaxy=\dimen123 -\pgf@xx=\dimen124 -\pgf@xy=\dimen125 -\pgf@yx=\dimen126 -\pgf@yy=\dimen127 -\pgf@zx=\dimen128 -\pgf@zy=\dimen129 -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepathconstruct. -code.tex -File: pgfcorepathconstruct.code.tex 2013/10/07 (rcs-revision 1.29) -\pgf@path@lastx=\dimen130 -\pgf@path@lasty=\dimen131 -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepathusage.code -.tex -File: pgfcorepathusage.code.tex 2014/11/02 (rcs-revision 1.24) -\pgf@shorten@end@additional=\dimen132 -\pgf@shorten@start@additional=\dimen133 -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorescopes.code.te -x -File: pgfcorescopes.code.tex 2015/05/08 (rcs-revision 1.46) -\pgfpic=\box29 -\pgf@hbox=\box30 -\pgf@layerbox@main=\box31 -\pgf@picture@serial@count=\count101 -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoregraphicstate.c -ode.tex -File: pgfcoregraphicstate.code.tex 2014/11/02 (rcs-revision 1.12) -\pgflinewidth=\dimen134 -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoretransformation -s.code.tex -File: pgfcoretransformations.code.tex 2015/08/07 (rcs-revision 1.20) -\pgf@pt@x=\dimen135 -\pgf@pt@y=\dimen136 -\pgf@pt@temp=\dimen137 -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorequick.code.tex -File: pgfcorequick.code.tex 2008/10/09 (rcs-revision 1.3) -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreobjects.code.t -ex -File: pgfcoreobjects.code.tex 2006/10/11 (rcs-revision 1.2) -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepathprocessing -.code.tex -File: pgfcorepathprocessing.code.tex 2013/09/09 (rcs-revision 1.9) -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorearrows.code.te -x -File: pgfcorearrows.code.tex 2015/05/14 (rcs-revision 1.43) -\pgfarrowsep=\dimen138 -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreshade.code.tex -File: pgfcoreshade.code.tex 2013/07/15 (rcs-revision 1.15) -\pgf@max=\dimen139 -\pgf@sys@shading@range@num=\count102 -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreimage.code.tex -File: pgfcoreimage.code.tex 2013/07/15 (rcs-revision 1.18) - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreexternal.code. -tex -File: pgfcoreexternal.code.tex 2014/07/09 (rcs-revision 1.21) -\pgfexternal@startupbox=\box32 -)) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorelayers.code.te -x -File: pgfcorelayers.code.tex 2013/07/18 (rcs-revision 1.7) -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoretransparency.c -ode.tex -File: pgfcoretransparency.code.tex 2013/09/30 (rcs-revision 1.5) -) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepatterns.code. -tex -File: pgfcorepatterns.code.tex 2013/11/07 (rcs-revision 1.5) -))) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/modules/pgfmoduleshapes.code.tex -File: pgfmoduleshapes.code.tex 2014/03/21 (rcs-revision 1.35) -\pgfnodeparttextbox=\box33 -) (/usr/share/texlive/texmf-dist/tex/generic/pgf/modules/pgfmoduleplot.code.tex -File: pgfmoduleplot.code.tex 2015/08/03 (rcs-revision 1.13) -) -(/usr/share/texlive/texmf-dist/tex/latex/pgf/compatibility/pgfcomp-version-0-65 -.sty -Package: pgfcomp-version-0-65 2007/07/03 v3.0.1a (rcs-revision 1.7) -\pgf@nodesepstart=\dimen140 -\pgf@nodesepend=\dimen141 -) -(/usr/share/texlive/texmf-dist/tex/latex/pgf/compatibility/pgfcomp-version-1-18 -.sty -Package: pgfcomp-version-1-18 2007/07/23 v3.0.1a (rcs-revision 1.1) -)) (/usr/share/texlive/texmf-dist/tex/latex/pgf/utilities/pgffor.sty -(/usr/share/texlive/texmf-dist/tex/latex/pgf/utilities/pgfkeys.sty -(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex)) -(/usr/share/texlive/texmf-dist/tex/latex/pgf/math/pgfmath.sty -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmath.code.tex)) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgffor.code.tex -Package: pgffor 2013/12/13 v3.0.1a (rcs-revision 1.25) - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmath.code.tex) -\pgffor@iter=\dimen142 -\pgffor@skip=\dimen143 -\pgffor@stack=\toks30 -\pgffor@toks=\toks31 -)) -(/usr/share/texlive/texmf-dist/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex -Package: tikz 2015/08/07 v3.0.1a (rcs-revision 1.151) - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/libraries/pgflibraryplothandlers -.code.tex -File: pgflibraryplothandlers.code.tex 2013/08/31 v3.0.1a (rcs-revision 1.20) -\pgf@plot@mark@count=\count103 -\pgfplotmarksize=\dimen144 -) -\tikz@lastx=\dimen145 -\tikz@lasty=\dimen146 -\tikz@lastxsaved=\dimen147 -\tikz@lastysaved=\dimen148 -\tikzleveldistance=\dimen149 -\tikzsiblingdistance=\dimen150 -\tikz@figbox=\box34 -\tikz@figbox@bg=\box35 -\tikz@tempbox=\box36 -\tikz@tempbox@bg=\box37 -\tikztreelevel=\count104 -\tikznumberofchildren=\count105 -\tikznumberofcurrentchild=\count106 -\tikz@fig@count=\count107 - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/modules/pgfmodulematrix.code.tex -File: pgfmodulematrix.code.tex 2013/09/17 (rcs-revision 1.8) -\pgfmatrixcurrentrow=\count108 -\pgfmatrixcurrentcolumn=\count109 -\pgf@matrix@numberofcolumns=\count110 -) -\tikz@expandcount=\count111 - -(/usr/share/texlive/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tik -zlibrarytopaths.code.tex -File: tikzlibrarytopaths.code.tex 2008/06/17 v3.0.1a (rcs-revision 1.2) -))) -(/usr/share/texlive/texmf-dist/tex/latex/pdfpages/pdfpages.sty -Package: pdfpages 2016/04/19 v0.5f Insert pages of external PDF documents (AM) - -(/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty -Package: ifthen 2014/09/29 v1.1c Standard LaTeX ifthen package (DPC) -) -(/usr/share/texlive/texmf-dist/tex/latex/tools/calc.sty -Package: calc 2014/10/28 v4.3 Infix arithmetic (KKT,FJ) -\calc@Acount=\count112 -\calc@Bcount=\count113 -\calc@Adimen=\dimen151 -\calc@Bdimen=\dimen152 -\calc@Askip=\skip43 -\calc@Bskip=\skip44 -LaTeX Info: Redefining \setlength on input line 80. -LaTeX Info: Redefining \addtolength on input line 81. -\calc@Ccount=\count114 -\calc@Cskip=\skip45 -) -(/usr/share/texlive/texmf-dist/tex/latex/eso-pic/eso-pic.sty -Package: eso-pic 2015/07/21 v2.0g eso-pic (RN) - -(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/atbegshi.sty -Package: atbegshi 2016/06/09 v1.18 At begin shipout hook (HO) - -(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty -Package: ifpdf 2016/05/14 v3.1 Provides the ifpdf switch -))) -\AM@pagewidth=\dimen153 -\AM@pageheight=\dimen154 - -(/usr/share/texlive/texmf-dist/tex/latex/pdfpages/pppdftex.def -File: pppdftex.def 2016/04/19 v0.5f Pdfpages driver for pdfTeX (AM) -) -\AM@pagebox=\box38 -\AM@global@opts=\toks32 -\AM@toc@title=\toks33 -\c@AM@survey=\count115 -\AM@templatesizebox=\box39 -) -(/usr/share/texlive/texmf-dist/tex/latex/changepage/changepage.sty -Package: changepage 2009/10/20 v1.0c check page and change page layout -\c@cp@cntr=\count116 -\cp@tempcnt=\count117 -) -(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty -Package: hyperref 2016/06/24 v6.83q Hypertext links for LaTeX - -(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty -Package: hobsub-hyperref 2016/05/16 v1.14 Bundle oberdiek, subset hyperref (HO) - - -(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty -Package: hobsub-generic 2016/05/16 v1.14 Bundle oberdiek, subset generic (HO) -Package: hobsub 2016/05/16 v1.14 Construct package bundles (HO) -Package hobsub Info: Skipping package `infwarerr' (already loaded). -Package hobsub Info: Skipping package `ltxcmds' (already loaded). -Package: ifluatex 2016/05/16 v1.4 Provides the ifluatex switch (HO) -Package ifluatex Info: LuaTeX not detected. -Package: ifvtex 2016/05/16 v1.6 Detect VTeX and its facilities (HO) -Package ifvtex Info: VTeX not detected. -Package: intcalc 2016/05/16 v1.2 Expandable calculations with integers (HO) -Package hobsub Info: Skipping package `ifpdf' (already loaded). -Package: etexcmds 2016/05/16 v1.6 Avoid name clashes with e-TeX commands (HO) -Package etexcmds Info: Could not find \expanded. -(etexcmds) That can mean that you are not using pdfTeX 1.50 or -(etexcmds) that some package has redefined \expanded. -(etexcmds) In the latter case, load this package earlier. -Package: kvsetkeys 2016/05/16 v1.17 Key value parser (HO) -Package: kvdefinekeys 2016/05/16 v1.4 Define keys (HO) -Package: pdftexcmds 2016/05/21 v0.22 Utility functions of pdfTeX for LuaTeX (HO -) -Package pdftexcmds Info: LuaTeX not detected. -Package pdftexcmds Info: \pdf@primitive is available. -Package pdftexcmds Info: \pdf@ifprimitive is available. -Package pdftexcmds Info: \pdfdraftmode found. -Package: pdfescape 2016/05/16 v1.14 Implements pdfTeX's escape features (HO) -Package: bigintcalc 2016/05/16 v1.4 Expandable calculations on big integers (HO -) -Package: bitset 2016/05/16 v1.2 Handle bit-vector datatype (HO) -Package: uniquecounter 2016/05/16 v1.3 Provide unlimited unique counter (HO) -) -Package hobsub Info: Skipping package `hobsub' (already loaded). -Package: letltxmacro 2016/05/16 v1.5 Let assignment for LaTeX macros (HO) -Package: hopatch 2016/05/16 v1.3 Wrapper for package hooks (HO) -Package: xcolor-patch 2016/05/16 xcolor patch -Package: atveryend 2016/05/16 v1.9 Hooks at the very end of document (HO) -Package atveryend Info: \enddocument detected (standard20110627). -Package hobsub Info: Skipping package `atbegshi' (already loaded). -Package: refcount 2016/05/16 v3.5 Data extraction from label references (HO) -Package: hycolor 2016/05/16 v1.8 Color options for hyperref/bookmark (HO) -) -(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty -Package: ifxetex 2010/09/12 v0.6 Provides ifxetex conditional -) -(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/auxhook.sty -Package: auxhook 2016/05/16 v1.4 Hooks for auxiliary files (HO) -) -(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty -Package: kvoptions 2016/05/16 v3.12 Key value format for package options (HO) -) -\@linkdim=\dimen155 -\Hy@linkcounter=\count118 -\Hy@pagecounter=\count119 - -(/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def -File: pd1enc.def 2016/06/24 v6.83q Hyperref: PDFDocEncoding definition (HO) -) -\Hy@SavedSpaceFactor=\count120 - -(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/hyperref.cfg -File: hyperref.cfg 2002/06/06 v1.2 hyperref configuration of TeXLive -) -Package hyperref Info: Hyper figures OFF on input line 4486. -Package hyperref Info: Link nesting OFF on input line 4491. -Package hyperref Info: Hyper index ON on input line 4494. -Package hyperref Info: Plain pages OFF on input line 4501. -Package hyperref Info: Backreferencing OFF on input line 4506. -Package hyperref Info: Implicit mode ON; LaTeX internals redefined. -Package hyperref Info: Bookmarks ON on input line 4735. -\c@Hy@tempcnt=\count121 - -(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty -\Urlmuskip=\muskip10 -Package: url 2013/09/16 ver 3.4 Verb mode for urls, etc. -) -LaTeX Info: Redefining \url on input line 5088. -\XeTeXLinkMargin=\dimen156 -\Fld@menulength=\count122 -\Field@Width=\dimen157 -\Fld@charsize=\dimen158 -Package hyperref Info: Hyper figures OFF on input line 6342. -Package hyperref Info: Link nesting OFF on input line 6347. -Package hyperref Info: Hyper index ON on input line 6350. -Package hyperref Info: backreferencing OFF on input line 6357. -Package hyperref Info: Link coloring OFF on input line 6362. -Package hyperref Info: Link coloring with OCG OFF on input line 6367. -Package hyperref Info: PDF/A mode OFF on input line 6372. -LaTeX Info: Redefining \ref on input line 6412. -LaTeX Info: Redefining \pageref on input line 6416. -\Hy@abspage=\count123 -\c@Item=\count124 -\c@Hfootnote=\count125 -) - -Package hyperref Message: Driver (autodetected): hpdftex. - -(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def -File: hpdftex.def 2016/06/24 v6.83q Hyperref driver for pdfTeX -\Fld@listcount=\count126 -\c@bookmark@seq@number=\count127 - -(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty -Package: rerunfilecheck 2016/05/16 v1.8 Rerun checks for auxiliary files (HO) -Package uniquecounter Info: New unique counter `rerunfilecheck' on input line 2 -82. -) -\Hy@SectionHShift=\skip46 -) -(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty -Package: caption 2016/02/21 v3.3-144 Customizing captions (AR) - -(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty -Package: caption3 2016/05/22 v1.7-166 caption3 kernel (AR) -Package caption3 Info: TeX engine: e-TeX on input line 67. -\captionmargin=\dimen159 -\captionmargin@=\dimen160 -\captionwidth=\dimen161 -\caption@tempdima=\dimen162 -\caption@indent=\dimen163 -\caption@parindent=\dimen164 -\caption@hangindent=\dimen165 -) -\c@ContinuedFloat=\count128 -Package caption Info: hyperref package is loaded. -) -(/usr/share/texlive/texmf-dist/tex/latex/booktabs/booktabs.sty -Package: booktabs 2016/04/27 v1.618033 publication quality tables -\heavyrulewidth=\dimen166 -\lightrulewidth=\dimen167 -\cmidrulewidth=\dimen168 -\belowrulesep=\dimen169 -\belowbottomsep=\dimen170 -\aboverulesep=\dimen171 -\abovetopsep=\dimen172 -\cmidrulesep=\dimen173 -\cmidrulekern=\dimen174 -\defaultaddspace=\dimen175 -\@cmidla=\count129 -\@cmidlb=\count130 -\@aboverulesep=\dimen176 -\@belowrulesep=\dimen177 -\@thisruleclass=\count131 -\@lastruleclass=\count132 -\@thisrulewidth=\dimen178 -) -(/usr/share/texlive/texmf-dist/tex/latex/tools/multicol.sty -Package: multicol 2016/04/07 v1.8p multicolumn formatting (FMi) -\c@tracingmulticols=\count133 -\mult@box=\box40 -\multicol@leftmargin=\dimen179 -\c@unbalance=\count134 -\c@collectmore=\count135 -\doublecol@number=\count136 -\multicoltolerance=\count137 -\multicolpretolerance=\count138 -\full@width=\dimen180 -\page@free=\dimen181 -\premulticols=\dimen182 -\postmulticols=\dimen183 -\multicolsep=\skip47 -\multicolbaselineskip=\skip48 -\partial@page=\box41 -\last@line=\box42 -\maxbalancingoverflow=\dimen184 -\mult@rightbox=\box43 -\mult@grightbox=\box44 -\mult@gfirstbox=\box45 -\mult@firstbox=\box46 -\@tempa=\box47 -\@tempa=\box48 -\@tempa=\box49 -\@tempa=\box50 -\@tempa=\box51 -\@tempa=\box52 -\@tempa=\box53 -\@tempa=\box54 -\@tempa=\box55 -\@tempa=\box56 -\@tempa=\box57 -\@tempa=\box58 -\@tempa=\box59 -\@tempa=\box60 -\@tempa=\box61 -\@tempa=\box62 -\@tempa=\box63 -\c@columnbadness=\count139 -\c@finalcolumnbadness=\count140 -\last@try=\dimen185 -\multicolovershoot=\dimen186 -\multicolundershoot=\dimen187 -\mult@nat@firstbox=\box64 -\colbreak@box=\box65 -\mc@col@check@num=\count141 -) -(/usr/share/texlive/texmf-dist/tex/latex/multirow/multirow.sty -\bigstrutjot=\dimen188 -) -(/usr/share/texlive/texmf-dist/tex/latex/multirow/bigstrut.sty) -(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty -Package: amsmath 2016/06/28 v2.15d AMS math features -\@mathmargin=\skip49 - -For additional information on amsmath, use the `?' option. -(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty -Package: amstext 2000/06/29 v2.01 AMS text - -(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty -File: amsgen.sty 1999/11/30 v2.0 generic functions -\@emptytoks=\toks34 -\ex@=\dimen189 -)) -(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty -Package: amsbsy 1999/11/29 v1.2d Bold Symbols -\pmbraise@=\dimen190 -) -(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty -Package: amsopn 2016/03/08 v2.02 operator names -) -\inf@bad=\count142 -LaTeX Info: Redefining \frac on input line 199. -\uproot@=\count143 -\leftroot@=\count144 -LaTeX Info: Redefining \overline on input line 297. -\classnum@=\count145 -\DOTSCASE@=\count146 -LaTeX Info: Redefining \ldots on input line 394. -LaTeX Info: Redefining \dots on input line 397. -LaTeX Info: Redefining \cdots on input line 518. -\Mathstrutbox@=\box66 -\strutbox@=\box67 -\big@size=\dimen191 -LaTeX Font Info: Redeclaring font encoding OML on input line 634. -LaTeX Font Info: Redeclaring font encoding OMS on input line 635. -\macc@depth=\count147 -\c@MaxMatrixCols=\count148 -\dotsspace@=\muskip11 -\c@parentequation=\count149 -\dspbrk@lvl=\count150 -\tag@help=\toks35 -\row@=\count151 -\column@=\count152 -\maxfields@=\count153 -\andhelp@=\toks36 -\eqnshift@=\dimen192 -\alignsep@=\dimen193 -\tagshift@=\dimen194 -\tagwidth@=\dimen195 -\totwidth@=\dimen196 -\lineht@=\dimen197 -\@envbody=\toks37 -\multlinegap=\skip50 -\multlinetaggap=\skip51 -\mathdisplay@stack=\toks38 -LaTeX Info: Redefining \[ on input line 2739. -LaTeX Info: Redefining \] on input line 2740. -) -(/usr/share/texlive/texmf-dist/tex/latex/tools/bm.sty -Package: bm 2016/07/07 v1.2b Bold Symbol Support (DPC/FMi) -\symboldoperators=\mathgroup4 -\symboldletters=\mathgroup5 -\symboldsymbols=\mathgroup6 -LaTeX Font Info: Redeclaring math alphabet \mathbf on input line 142. -LaTeX Info: Redefining \bm on input line 208. -) -(/usr/share/texlive/texmf-dist/tex/latex/enumitem/enumitem.sty -Package: enumitem 2011/09/28 v3.5.2 Customized lists -\labelindent=\skip52 -\enit@outerparindent=\dimen198 -\enit@toks=\toks39 -\enit@inbox=\box68 -\enitdp@description=\count154 -) -(/usr/share/texlive/texmf-dist/tex/latex/amscls/amsthm.sty -Package: amsthm 2015/03/04 v2.20.2 -\thm@style=\toks40 -\thm@bodyfont=\toks41 -\thm@headfont=\toks42 -\thm@notefont=\toks43 -\thm@headpunct=\toks44 -\thm@preskip=\skip53 -\thm@postskip=\skip54 -\thm@headsep=\skip55 -\dth@everypar=\toks45 -) -\c@definition=\count155 -\MBox=\box69 - -(/usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty -\lst@mode=\count156 -\lst@gtempboxa=\box70 -\lst@token=\toks46 -\lst@length=\count157 -\lst@currlwidth=\dimen199 -\lst@column=\count158 -\lst@pos=\count159 -\lst@lostspace=\dimen256 -\lst@width=\dimen257 -\lst@newlines=\count160 -\lst@lineno=\count161 -\lst@maxwidth=\dimen258 - -(/usr/share/texlive/texmf-dist/tex/latex/listings/lstmisc.sty -File: lstmisc.sty 2015/06/04 1.6 (Carsten Heinz) -\c@lstnumber=\count162 -\lst@skipnumbers=\count163 -\lst@framebox=\box71 -) -(/usr/share/texlive/texmf-dist/tex/latex/listings/listings.cfg -File: listings.cfg 2015/06/04 1.6 listings configuration -)) -Package: listings 2015/06/04 1.6 (Carsten Heinz) - -(./Masterarbeit.aux) -\openout1 = `Masterarbeit.aux'. - -LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 86. -LaTeX Font Info: ... okay on input line 86. -LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 86. -LaTeX Font Info: ... okay on input line 86. -LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 86. -LaTeX Font Info: ... okay on input line 86. -LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 86. -LaTeX Font Info: ... okay on input line 86. -LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 86. -LaTeX Font Info: ... okay on input line 86. -LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 86. -LaTeX Font Info: ... okay on input line 86. -LaTeX Font Info: Checking defaults for PD1/pdf/m/n on input line 86. -LaTeX Font Info: ... okay on input line 86. - -(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii -[Loading MPS to PDF converter (version 2006.09.02).] -\scratchcounter=\count164 -\scratchdimen=\dimen259 -\scratchbox=\box72 -\nofMPsegments=\count165 -\nofMParguments=\count166 -\everyMPshowfont=\toks47 -\MPscratchCnt=\count167 -\MPscratchDim=\dimen260 -\MPnumerator=\count168 -\makeMPintoPDFobject=\count169 -\everyMPtoPDFconversion=\toks48 -) (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty -Package: epstopdf-base 2016/05/15 v2.6 Base part for package epstopdf - -(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty -Package: grfext 2016/05/16 v1.2 Manage graphics extensions (HO) -) -Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4 -38. -Package grfext Info: Graphics extension search list: -(grfext) [.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPE -G,.JBIG2,.JB2,.eps] -(grfext) \AppendGraphicsExtensions on input line 456. - -(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg -File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv -e -)) -(/usr/share/texlive/texmf-dist/tex/latex/ucs/ucsencs.def -File: ucsencs.def 2011/01/21 Fixes to fontencodings LGR, T3 -) -ABD: EveryShipout initializing macros -\AtBeginShipoutBox=\box73 - -(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/pdflscape.sty -Package: pdflscape 2016/05/14 v0.11 Display of landscape pages in PDF (HO) - -(/usr/share/texlive/texmf-dist/tex/latex/graphics/lscape.sty -Package: lscape 2000/10/22 v3.01 Landscape Pages (DPC) -) -Package pdflscape Info: Auto-detected driver: pdftex on input line 81. -) -Package hyperref Info: Link coloring OFF on input line 86. - -(/usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty -Package: nameref 2016/05/21 v2.44 Cross-referencing by name of section - -(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/gettitlestring.sty -Package: gettitlestring 2016/05/16 v1.5 Cleanup title references (HO) -) -\c@section@level=\count170 -) -LaTeX Info: Redefining \ref on input line 86. -LaTeX Info: Redefining \pageref on input line 86. -LaTeX Info: Redefining \nameref on input line 86. - -(./Masterarbeit.out) (./Masterarbeit.out) -\@outlinefile=\write5 -\openout5 = `Masterarbeit.out'. - -Package caption Info: Begin \AtBeginDocument code. -Package caption Info: listings package is loaded. -Package caption Info: End \AtBeginDocument code. -\c@lstlisting=\count171 - (./src/tex/cover_en.tex - -File: src/pic/logo.jpg Graphic file (type jpg) - -Package pdftex.def Info: src/pic/logo.jpg used on input line 16. -(pdftex.def) Requested size: 336.0068pt x 85.35826pt. -LaTeX Font Info: Try loading font information for OT1+phv on input line 34. - -(/usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1phv.fd -File: ot1phv.fd 2001/06/04 scalable font definitions for OT1/phv. -) -LaTeX Font Info: Font shape `OT1/phv/bx/n' in size <17.28> not available -(Font) Font shape `OT1/phv/b/n' tried instead on input line 39. -LaTeX Font Info: Font shape `OT1/phv/bx/n' in size <14.4> not available -(Font) Font shape `OT1/phv/b/n' tried instead on input line 45. - [1 - -{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./src/pic/logo.jpg>]) - -File: Formular_Eidesstattliche_Versicherung_neu.pdf Graphic file (type pdf) - -Package pdftex.def Info: Formular_Eidesstattliche_Versicherung_neu.pdf used on -input line 97. -(pdftex.def) Requested size: 597.45058pt x 845.15544pt. -File: Formular_Eidesstattliche_Versicherung_neu.pdf Graphic file (type pdf) - - -Package pdftex.def Info: Formular_Eidesstattliche_Versicherung_neu.pdf used on -input line 97. -(pdftex.def) Requested size: 597.45058pt x 845.15544pt. - - -File: Formular_Eidesstattliche_Versicherung_neu.pdf Graphic file (type pdf) - -Package pdftex.def Info: Formular_Eidesstattliche_Versicherung_neu.pdf, page1 u -sed on input line 97. -(pdftex.def) Requested size: 597.45058pt x 845.15544pt. -File: Formular_Eidesstattliche_Versicherung_neu.pdf Graphic file (type pdf) - - -Package pdftex.def Info: Formular_Eidesstattliche_Versicherung_neu.pdf, page1 u -sed on input line 97. -(pdftex.def) Requested size: 597.47792pt x 845.19412pt. -File: Formular_Eidesstattliche_Versicherung_neu.pdf Graphic file (type pdf) - - -Package pdftex.def Info: Formular_Eidesstattliche_Versicherung_neu.pdf, page1 u -sed on input line 97. -(pdftex.def) Requested size: 597.47792pt x 845.19412pt. -File: Formular_Eidesstattliche_Versicherung_neu.pdf Graphic file (type pdf) - - -Package pdftex.def Info: Formular_Eidesstattliche_Versicherung_neu.pdf, page1 u -sed on input line 97. -(pdftex.def) Requested size: 597.47792pt x 845.19412pt. -File: Formular_Eidesstattliche_Versicherung_neu.pdf Graphic file (type pdf) - - -Package pdftex.def Info: Formular_Eidesstattliche_Versicherung_neu.pdf, page1 u -sed on input line 97. -(pdftex.def) Requested size: 597.47792pt x 845.19412pt. -pdfTeX warning (ext4): destination with the same identifier (name{page.i}) has -been already used, duplicate ignored - - \relax -l.97 ...ular_Eidesstattliche_Versicherung_neu.pdf} - [1 - - <./Formular_Eidesstattliche_Versicherung_neu.pdf>] (./src/tex/abstract.tex [2 - -]) (./Masterarbeit.toc -[3 - -]) -\tf@toc=\write6 -\openout6 = `Masterarbeit.toc'. - - [4] (./src/tex/introduction.tex -Chapter 1. -[1 - - -] [2] -File: gen/P2PMulticast.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/P2PMulticast.pdf used on input line 23. -(pdftex.def) Requested size: 384.10959pt x 222.54431pt. -LaTeX Font Info: Try loading font information for OMS+cmr on input line 37. - -(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd -File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions -) -LaTeX Font Info: Font shape `OMS/cmr/m/n' in size <10.95> not available -(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 37. - [3 <./gen/P2PMulticast.pdf, page is rotated 90 degrees>]) (./src/tex/theoretic -alBackground.tex -[4] -Chapter 2. -[5 - -] -File: gen/AreaOfInterest.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/AreaOfInterest.pdf used on input line 32. -(pdftex.def) Requested size: 426.79134pt x 207.55309pt. - [6 <./gen/AreaOfInterest.pdf, page is rotated 90 degrees>] - -pdfTeX warning: pdflatex (file ./gen/Architectures.pdf): PDF inclusion: found P -DF version <1.7>, but at most version <1.6> allowed - -File: gen/Architectures.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/Architectures.pdf used on input line 46. -(pdftex.def) Requested size: 426.79134pt x 171.36455pt. - [7 <./gen/Architectures.pdf>] [8] - -File: gen/ThreeTierArch.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/ThreeTierArch.pdf used on input line 82. -(pdftex.def) Requested size: 426.79134pt x 286.67989pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[9] -File: gen/Sharding.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/Sharding.pdf used on input line 98. -(pdftex.def) Requested size: 426.79134pt x 293.2212pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[10 <./gen/ThreeTierArch.pdf, page is rotated 90 degrees>] - -File: gen/Cloning.pdf Graphic file (type pdf) - -Package pdftex.def Info: gen/Cloning.pdf used on input line 114. -(pdftex.def) Requested size: 426.79134pt x 267.10147pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[11 <./gen/Sharding.pdf, page is rotated 90 degrees>] - -File: gen/Zoning.pdf Graphic file (type pdf) - -Package pdftex.def Info: gen/Zoning.pdf used on input line 132. -(pdftex.def) Requested size: 426.79134pt x 310.53117pt. - [12 <./gen/Cloning.pdf, page is rotated 90 degrees>] [13 <./gen/Zoning.pdf, pa -ge is rotated 90 degrees>] -File: gen/ProxyServer.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/ProxyServer.pdf used on input line 167. -(pdftex.def) Requested size: 426.79134pt x 296.69022pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[14] [15 <./gen/ProxyServer.pdf, page is rotated 90 degrees>] - -File: gen/DistributedZoning.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/DistributedZoning.pdf used on input line 200. -(pdftex.def) Requested size: 426.79134pt x 248.31032pt. - [16 <./gen/DistributedZoning.pdf, page is rotated 90 degrees>] -File: gen/PublishSubscribe.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/PublishSubscribe.pdf used on input line 208. -(pdftex.def) Requested size: 426.79134pt x 234.736pt. - [17 <./gen/PublishSubscribe.pdf, page is rotated 90 degrees>] -File: gen/MVC.pdf Graphic file (type pdf) - -Package pdftex.def Info: gen/MVC.pdf used on input line 241. -(pdftex.def) Requested size: 213.39566pt x 187.56967pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[18]) (./src/tex/technicalRequisites.tex [19 <./gen/MVC.pdf, page is rotated 90 - degrees>] -Chapter 3. -[20 - -] - -File: src/pic/imgs/sfs-room-architecture.png Graphic file (type png) - - -Package pdftex.def Info: src/pic/imgs/sfs-room-architecture.png used on input l -ine 36. -(pdftex.def) Requested size: 213.39566pt x 262.60814pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[21] [22 <./src/pic/imgs/sfs-room-architecture.png>]) -(./src/tex/simulationPlatform.tex [23] -Chapter 4. -[24 - -] -File: gen/Overview.pdf Graphic file (type pdf) - -Package pdftex.def Info: gen/Overview.pdf used on input line 36. -(pdftex.def) Requested size: 426.79134pt x 344.54457pt. - -[25] [26 <./gen/Overview.pdf, page is rotated 90 degrees>] - -File: src/pic/imgs/screenshots/scenario-menu.png Graphic file (type png) - -Package pdftex.def Info: src/pic/imgs/screenshots/scenario-menu.png used on inp -ut line 51. -(pdftex.def) Requested size: 426.79134pt x 279.62625pt. - - -File: src/pic/imgs/screenshots/play-scenario.png Graphic file (type png) - -Package pdftex.def Info: src/pic/imgs/screenshots/play-scenario.png used on inp -ut line 59. -(pdftex.def) Requested size: 426.79134pt x 440.94102pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - - -File: src/pic/imgs/screenshots/SwitchCar.png Graphic file (type png) - - -Package pdftex.def Info: src/pic/imgs/screenshots/SwitchCar.png used on input l -ine 67. -(pdftex.def) Requested size: 426.79134pt x 216.78658pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[27 <./src/pic/imgs/screenshots/scenario-menu.png (PNG copy)>] [28 <./src/pic/i -mgs/screenshots/play-scenario.png (PNG copy)>] [29 <./src/pic/imgs/screenshots/ -SwitchCar.png (PNG copy)>] -(/usr/share/texlive/texmf-dist/tex/latex/listings/lstlang1.sty -File: lstlang1.sty 2015/06/04 1.6 listings language file -) -Underfull \hbox (badness 10000) in paragraph at lines 98--100 - - [] - -Package hyperref Info: bookmark level for unknown lstlisting defaults to 0 on i -nput line 100. -LaTeX Font Info: Try loading font information for OT1+pcr on input line 100. - -(/usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1pcr.fd -File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr. -) -LaTeX Font Info: Font shape `OT1/pcr/bx/n' in size <10> not available -(Font) Font shape `OT1/pcr/b/n' tried instead on input line 101. - -Underfull \hbox (badness 10000) in paragraph at lines 106--108 - - [] - -LaTeX Font Info: Font shape `OT1/pcr/m/it' in size <10> not available -(Font) Font shape `OT1/pcr/m/sl' tried instead on input line 111. -[30] -Underfull \hbox (badness 10000) in paragraph at lines 139--141 - - [] - - -Underfull \hbox (badness 10000) in paragraph at lines 154--156 - - [] - -[31] -Underfull \hbox (badness 10000) in paragraph at lines 201--203 - - [] - - -Underfull \hbox (badness 10000) in paragraph at lines 218--220 - - [] - -[32] -Overfull \hbox (8.21294pt too wide) in paragraph at lines 240--241 -[][][][][][][][][][][][][][][][][][][][][] - [] - -[33] -Underfull \hbox (badness 10000) in paragraph at lines 269--271 - - [] - - -Overfull \hbox (2.21288pt too wide) in paragraph at lines 282--283 -[][][][][][][][][][][][][][][][][][][][] - [] - -[34] -File: src/pic/imgs/sfs-class-loaders.png Graphic file (type png) - - -Package pdftex.def Info: src/pic/imgs/sfs-class-loaders.png used on input line -296. -(pdftex.def) Requested size: 426.79134pt x 197.04071pt. - -Underfull \hbox (badness 10000) in paragraph at lines 301--303 - - [] - -[35 <./src/pic/imgs/sfs-class-loaders.png>] -Overfull \hbox (8.21294pt too wide) in paragraph at lines 340--341 -[][][][][][][][][][][][][][][][][][][][][][][][][] - [] - -[36] -Underfull \hbox (badness 10000) in paragraph at lines 352--354 - - [] - - -Overfull \hbox (2.21288pt too wide) in paragraph at lines 365--366 -[][][][][][][][][][][][][][][][][][][][][][] - [] - - -Underfull \hbox (badness 10000) in paragraph at lines 381--383 - - [] - -[37] -Underfull \hbox (badness 10000) in paragraph at lines 407--409 - - [] - -[38] -File: gen/ERD.pdf Graphic file (type pdf) - -Package pdftex.def Info: gen/ERD.pdf used on input line 438. -(pdftex.def) Requested size: 426.79134pt x 269.6884pt. - -[39 <./gen/ERD.pdf>] -File: gen/MapSplitting.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/MapSplitting.pdf used on input line 463. -(pdftex.def) Requested size: 426.79134pt x 330.4177pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[40] [41 <./gen/MapSplitting.pdf, page is rotated 90 degrees>] [42] -(/usr/share/texlive/texmf-dist/tex/latex/listings/lstlang1.sty -File: lstlang1.sty 2015/06/04 1.6 listings language file -) -Underfull \hbox (badness 10000) in paragraph at lines 497--499 - - [] - - -Overfull \hbox (2.21288pt too wide) in paragraph at lines 503--504 -[][][][][][][][][][][][][][][][][][][] - [] - - -Underfull \hbox (badness 10000) in paragraph at lines 507--509 - - [] - -[43] -File: gen/PathFinder.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/PathFinder.pdf used on input line 540. -(pdftex.def) Requested size: 426.79134pt x 248.6914pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[44] [45 <./gen/PathFinder.pdf, page is rotated 90 degrees>] -Underfull \hbox (badness 10000) in paragraph at lines 559--561 - - [] - -[46] -Underfull \hbox (badness 10000) in paragraph at lines 612--614 - - [] - -[47] -Underfull \hbox (badness 10000) in paragraph at lines 635--637 - - [] - - -Underfull \hbox (badness 10000) in paragraph at lines 647--649 - - [] - -[48] -Underfull \hbox (badness 10000) in paragraph at lines 672--674 - - [] - -[49] [50] -Underfull \hbox (badness 10000) in paragraph at lines 753--755 - - [] - - -Overfull \hbox (2.21288pt too wide) in paragraph at lines 767--768 -[][][][][][][][][][][][][][][][][][][][][][][][] - [] - -[51] -Underfull \hbox (badness 10000) in paragraph at lines 787--789 - - [] - -[52] -Underfull \hbox (badness 10000) in paragraph at lines 810--812 - - [] - - -Underfull \hbox (badness 10000) in paragraph at lines 824--826 - - [] - -[53] -Underfull \hbox (badness 10000) in paragraph at lines 838--840 - - [] - - -Overfull \hbox (2.21288pt too wide) in paragraph at lines 848--849 -[][][][][][][][][][][][][][][][] - [] - - -File: gen/ScenarioList.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/ScenarioList.pdf used on input line 864. -(pdftex.def) Requested size: 426.79134pt x 483.07997pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[54] [55 <./gen/ScenarioList.pdf>] - -File: gen/Simulation.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/Simulation.pdf used on input line 877. -(pdftex.def) Requested size: 426.79134pt x 393.75795pt. - [56 - - <./gen/Simulation.pdf>] -Underfull \hbox (badness 10000) in paragraph at lines 884--886 - - [] - - -Overfull \hbox (2.21288pt too wide) in paragraph at lines 900--901 -[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] - [] - - -Underfull \hbox (badness 10000) in paragraph at lines 912--914 - - [] - -[57] -Underfull \hbox (badness 10000) in paragraph at lines 939--941 - - [] - - -Underfull \hbox (badness 10000) in paragraph at lines 956--958 - - [] - -[58] [59] - -File: src/pic/imgs/screenshots/ZoneConfiguration.png Graphic file (type png) - -Package pdftex.def Info: src/pic/imgs/screenshots/ZoneConfiguration.png used on - input line 994. -(pdftex.def) Requested size: 426.79134pt x 211.83679pt. - - -File: src/pic/imgs/screenshots/WebServerConfig.png Graphic file (type png) - -Package pdftex.def Info: src/pic/imgs/screenshots/WebServerConfig.png used on i -nput line 1003. -(pdftex.def) Requested size: 426.79134pt x 211.39175pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[60 <./src/pic/imgs/screenshots/ZoneConfiguration.png (PNG copy)>] - -File: gen/Authentication.pdf Graphic file (type pdf) - - -Package pdftex.def Info: gen/Authentication.pdf used on input line 1016. -(pdftex.def) Requested size: 426.79134pt x 304.38435pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -) [61 <./src/pic/imgs/screenshots/WebServerConfig.png (PNG copy)>] -(./src/tex/evaluation.tex [62 <./gen/Authentication.pdf>] -Chapter 5. - - -File: src/pic/imgs/screenshots/Performance-1.png Graphic file (type png) - -Package pdftex.def Info: src/pic/imgs/screenshots/Performance-1.png used on inp -ut line 11. -(pdftex.def) Requested size: 426.79134pt x 211.84294pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - - - -File: src/pic/imgs/screenshots/Performance-2.png Graphic file (type png) - -Package pdftex.def Info: src/pic/imgs/screenshots/Performance-2.png used on inp -ut line 19. -(pdftex.def) Requested size: 426.79134pt x 211.84294pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -[63 - -] - -File: src/pic/imgs/screenshots/Messaging.png Graphic file (type png) - - -Package pdftex.def Info: src/pic/imgs/screenshots/Messaging.png used on input l -ine 29. -(pdftex.def) Requested size: 426.79134pt x 211.84294pt. - - -LaTeX Warning: `h' float specifier changed to `ht'. - -) (./src/tex/futureWork.tex [64 <./src/pic/imgs/screenshots/Performance-1.png ( -PNG copy)>] [65 <./src/pic/imgs/screenshots/Performance-2.png (PNG copy)> <./sr -c/pic/imgs/screenshots/Messaging.png (PNG copy)>] -Chapter 6. -[66 - -] [67]) (./src/tex/conclusion.tex [68] -Chapter 7. -[69 - -]) (./Masterarbeit.bbl [70] [71 - -] [72]) [73] -Package atveryend Info: Empty hook `BeforeClearDocument' on input line 130. -Package atveryend Info: Empty hook `AfterLastShipout' on input line 130. - (./Masterarbeit.aux) -Package atveryend Info: Executing hook `AtVeryEndDocument' on input line 130. -Package atveryend Info: Executing hook `AtEndAfterFileList' on input line 130. -Package rerunfilecheck Info: File `Masterarbeit.out' has not changed. -(rerunfilecheck) Checksum: 4848136C56E8B2F1EA1CD483F4988D79;3177. -Package atveryend Info: Empty hook `AtVeryVeryEnd' on input line 130. - ) -Here is how much of TeX's memory you used: - 22026 strings out of 493013 - 395114 string characters out of 6135682 - 496983 words of memory out of 5000000 - 24326 multiletter control sequences out of 15000+600000 - 25346 words of font info for 72 fonts, out of 8000000 for 9000 - 1141 hyphenation exceptions out of 8191 - 55i,18n,54p,1530b,1879s stack positions out of 5000i,500n,10000p,200000b,80000s -{/usr/share/texlive/texmf-dist/fonts/enc/dvips/base/8r.enc}< -/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmti10.pfb> -Output written on Masterarbeit.pdf (78 pages, 3379524 bytes). -PDF statistics: - 1904 PDF objects out of 2073 (max. 8388607) - 1645 compressed objects within 17 object streams - 782 named destinations out of 1000 (max. 500000) - 570 words of extra memory for PDF output out of 10000 (max. 10000000) - diff --git a/docs/Thesis/Masterarbeit.out b/docs/Thesis/Masterarbeit.out deleted file mode 100755 index 8dd7d15f2847f0fe3fa8da5bfa41562d3c2ca267..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.out +++ /dev/null @@ -1,49 +0,0 @@ -\BOOKMARK [0][-]{chapter.1}{Introduction}{}% 1 -\BOOKMARK [0][-]{chapter.2}{Preliminaries}{}% 2 -\BOOKMARK [1][-]{section.2.1}{Massive multiplayer online gaming}{chapter.2}% 3 -\BOOKMARK [1][-]{section.2.2}{Area of Interest}{chapter.2}% 4 -\BOOKMARK [1][-]{section.2.3}{Architectures}{chapter.2}% 5 -\BOOKMARK [2][-]{subsection.2.3.1}{Peer-to-peer}{section.2.3}% 6 -\BOOKMARK [2][-]{subsection.2.3.2}{Client/server}{section.2.3}% 7 -\BOOKMARK [1][-]{section.2.4}{Distributing mechanisms}{chapter.2}% 8 -\BOOKMARK [2][-]{subsection.2.4.1}{Sharding}{section.2.4}% 9 -\BOOKMARK [2][-]{subsection.2.4.2}{Cloning}{section.2.4}% 10 -\BOOKMARK [2][-]{subsection.2.4.3}{Zoning}{section.2.4}% 11 -\BOOKMARK [2][-]{subsection.2.4.4}{Instancing}{section.2.4}% 12 -\BOOKMARK [1][-]{section.2.5}{Advanced distributed architectures}{chapter.2}% 13 -\BOOKMARK [2][-]{subsection.2.5.1}{Proxy-server architecture}{section.2.5}% 14 -\BOOKMARK [2][-]{subsection.2.5.2}{Distributed architecture combined with zoning technique}{section.2.5}% 15 -\BOOKMARK [1][-]{section.2.6}{Model-View-Controller pattern}{chapter.2}% 16 -\BOOKMARK [0][-]{chapter.3}{Technical Requisites}{}% 17 -\BOOKMARK [1][-]{section.3.1}{SmartFoxServer}{chapter.3}% 18 -\BOOKMARK [2][-]{subsection.3.1.1}{Web Server}{section.3.1}% 19 -\BOOKMARK [2][-]{subsection.3.1.2}{Web Services}{section.3.1}% 20 -\BOOKMARK [2][-]{subsection.3.1.3}{Data serialization}{section.3.1}% 21 -\BOOKMARK [2][-]{subsection.3.1.4}{Scope Management}{section.3.1}% 22 -\BOOKMARK [2][-]{subsection.3.1.5}{Data access and server monitoring}{section.3.1}% 23 -\BOOKMARK [1][-]{section.3.2}{ThreeJS}{chapter.3}% 24 -\BOOKMARK [1][-]{section.3.3}{PostgreSQL database}{chapter.3}% 25 -\BOOKMARK [0][-]{chapter.4}{Simulation Platform}{}% 26 -\BOOKMARK [1][-]{section.4.1}{Challenges}{chapter.4}% 27 -\BOOKMARK [1][-]{section.4.2}{Architecture}{chapter.4}% 28 -\BOOKMARK [1][-]{section.4.3}{Basic work-flow}{chapter.4}% 29 -\BOOKMARK [2][-]{subsection.4.3.1}{Zone level}{section.4.3}% 30 -\BOOKMARK [2][-]{subsection.4.3.2}{Room level}{section.4.3}% 31 -\BOOKMARK [1][-]{section.4.4}{Virtual World}{chapter.4}% 32 -\BOOKMARK [2][-]{subsection.4.4.1}{Zoning approach}{section.4.4}% 33 -\BOOKMARK [1][-]{section.4.5}{Path Finder}{chapter.4}% 34 -\BOOKMARK [1][-]{section.4.6}{Database optimization}{chapter.4}% 35 -\BOOKMARK [1][-]{section.4.7}{Web Communication}{chapter.4}% 36 -\BOOKMARK [1][-]{section.4.8}{Simulation}{chapter.4}% 37 -\BOOKMARK [2][-]{subsection.4.8.1}{Simulation Controller}{section.4.8}% 38 -\BOOKMARK [2][-]{subsection.4.8.2}{Mediator}{section.4.8}% 39 -\BOOKMARK [2][-]{subsection.4.8.3}{Scenarios}{section.4.8}% 40 -\BOOKMARK [2][-]{subsection.4.8.4}{Synchronization and Visualization}{section.4.8}% 41 -\BOOKMARK [1][-]{section.4.9}{Configuration}{chapter.4}% 42 -\BOOKMARK [1][-]{section.4.10}{Security}{chapter.4}% 43 -\BOOKMARK [0][-]{chapter.5}{Evaluation}{}% 44 -\BOOKMARK [0][-]{chapter.6}{Future Work}{}% 45 -\BOOKMARK [1][-]{section.6.1}{Single simulation per vehicle}{chapter.6}% 46 -\BOOKMARK [1][-]{section.6.2}{Online model development, test and deployment}{chapter.6}% 47 -\BOOKMARK [0][-]{chapter.7}{Conclusion}{}% 48 -\BOOKMARK [0][-]{chapter.7}{Bibliography}{}% 49 diff --git a/docs/Thesis/Masterarbeit.out.mine b/docs/Thesis/Masterarbeit.out.mine deleted file mode 100755 index 8338e290f9d15c93cbc29610d1b216c8de59027a..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.out.mine +++ /dev/null @@ -1,15 +0,0 @@ -\BOOKMARK [0][-]{chapter.1}{Einleitung}{}% 1 -\BOOKMARK [1][-]{section.1.1}{Eins - Eins}{chapter.1}% 2 -\BOOKMARK [2][-]{subsection.1.1.1}{Eins - Eins - Eins}{section.1.1}% 3 -\BOOKMARK [0][-]{chapter.2}{Z3 theorem solver}{}% 4 -\BOOKMARK [1][-]{section.2.1}{Z3 basics}{chapter.2}% 5 -\BOOKMARK [0][-]{chapter.3}{Elimination of internal variables of automatons that including non-linear parts}{}% 6 -\BOOKMARK [1][-]{section.3.1}{Exemplified workflow of matching internal variables }{chapter.3}% 7 -\BOOKMARK [2][-]{subsection.3.1.1}{Automatons for comparison}{section.3.1}% 8 -\BOOKMARK [2][-]{subsection.3.1.2}{First step of the procedure. Detecting non-linear equations.}{section.3.1}% 9 -\BOOKMARK [2][-]{subsection.3.1.3}{Second step of the procedure. Calculation of non linear coefficients.}{section.3.1}% 10 -\BOOKMARK [2][-]{subsection.3.1.4}{Unfolding and simulation}{section.3.1}% 11 -\BOOKMARK [0][-]{chapter.4}{Code Listings}{}% 12 -\BOOKMARK [0][-]{chapter.5}{Zusammenfassung und Ausblick}{}% 13 -\BOOKMARK [0][-]{figure.caption.11}{Literaturverzeichnis}{}% 14 -\BOOKMARK [0][-]{appendix.A}{z.B. Programmdokumentation}{}% 15 diff --git a/docs/Thesis/Masterarbeit.out.r40 b/docs/Thesis/Masterarbeit.out.r40 deleted file mode 100755 index 4dddbef19e79f4af1d7b80d2330ebf033281005f..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.out.r40 +++ /dev/null @@ -1,41 +0,0 @@ -\BOOKMARK [0][-]{chapter.1}{Introduction}{}% 1 -\BOOKMARK [0][-]{chapter.2}{Related Work}{}% 2 -\BOOKMARK [0][-]{chapter.3}{Theoretical Background}{}% 3 -\BOOKMARK [1][-]{section.3.1}{Input/Output Extended Finite Automaton\(I/O-EFA\)}{chapter.3}% 4 -\BOOKMARK [1][-]{section.3.2}{Input/Output Transition System}{chapter.3}% 5 -\BOOKMARK [1][-]{section.3.3}{Simulation relation}{chapter.3}% 6 -\BOOKMARK [0][-]{chapter.4}{Using Isabelle prove assistant for compatibility check}{}% 7 -\BOOKMARK [1][-]{section.4.1}{Simulink components}{chapter.4}% 8 -\BOOKMARK [1][-]{section.4.2}{Application of Isabelle}{chapter.4}% 9 -\BOOKMARK [1][-]{section.4.3}{Global variables test using Isabelle theorem prover}{chapter.4}% 10 -\BOOKMARK [0][-]{chapter.5}{Elimination of internal variables of I/O-EFA automatons that including non-linear parts}{}% 11 -\BOOKMARK [1][-]{section.5.1}{Z3 Solver basics}{chapter.5}% 12 -\BOOKMARK [1][-]{section.5.2}{Exemplified workflow of matching internal variables of I/O-EFAs containing non-linear dependencies}{chapter.5}% 13 -\BOOKMARK [2][-]{subsection.5.2.1}{Previous approach}{section.5.2}% 14 -\BOOKMARK [2][-]{subsection.5.2.2}{Automatons for comparison}{section.5.2}% 15 -\BOOKMARK [2][-]{subsection.5.2.3}{First step of the procedure. Detecting non-linear equations.}{section.5.2}% 16 -\BOOKMARK [2][-]{subsection.5.2.4}{Second step of the procedure. Calculation of linear coefficients.}{section.5.2}% 17 -\BOOKMARK [2][-]{subsection.5.2.5}{Unfolding and simulation}{section.5.2}% 18 -\BOOKMARK [0][-]{chapter.6}{Index tree optimization for transition filtering}{}% 19 -\BOOKMARK [1][-]{section.6.1}{Previous approach of transition filtering optimization}{chapter.6}% 20 -\BOOKMARK [1][-]{section.6.2}{Building of index tree}{chapter.6}% 21 -\BOOKMARK [1][-]{section.6.3}{Evaluation}{chapter.6}% 22 -\BOOKMARK [0][-]{chapter.7}{Clone detection and transformation to I/O-FEA of control flow graphs}{}% 23 -\BOOKMARK [1][-]{section.7.1}{Approach with control flow graphs trees}{chapter.7}% 24 -\BOOKMARK [1][-]{section.7.2}{Applied approach for substitution, clone detection and separation on output port basis}{chapter.7}% 25 -\BOOKMARK [2][-]{subsection.7.2.1}{Substitution}{section.7.2}% 26 -\BOOKMARK [2][-]{subsection.7.2.2}{Clone detection}{section.7.2}% 27 -\BOOKMARK [2][-]{subsection.7.2.3}{Separation on output port basis}{section.7.2}% 28 -\BOOKMARK [1][-]{section.7.3}{Improvements}{chapter.7}% 29 -\BOOKMARK [0][-]{chapter.8}{Disjunctive Normal Form Optimization}{}% 30 -\BOOKMARK [1][-]{section.8.1}{1st Step: Guard to Guard Normal Form \(GNF\) Transformation}{chapter.8}% 31 -\BOOKMARK [1][-]{section.8.2}{2nd Step: Guard-NF to Guard Disjunctive Normal Form \(GDNF\) Transformation}{chapter.8}% 32 -\BOOKMARK [2][-]{subsection.8.2.1}{3rd Step: Guard-DNF to Hash-Guard Disjunctive Normal Form \(HGDNF\) Transformation}{section.8.2}% 33 -\BOOKMARK [2][-]{subsection.8.2.2}{4th Step: HGDNF to Optimized HGDNF Transformation}{section.8.2}% 34 -\BOOKMARK [0][-]{chapter.9}{Code Listings}{}% 35 -\BOOKMARK [1][-]{section.9.1}{Isabelle listing}{chapter.9}% 36 -\BOOKMARK [1][-]{section.9.2}{Z3 listings}{chapter.9}% 37 -\BOOKMARK [1][-]{section.9.3}{Java listings}{chapter.9}% 38 -\BOOKMARK [0][-]{chapter.10}{Zusammenfassung und Ausblick}{}% 39 -\BOOKMARK [0][-]{figure.caption.23}{Literaturverzeichnis}{}% 40 -\BOOKMARK [0][-]{appendix.A}{z.B. Programmdokumentation}{}% 41 diff --git a/docs/Thesis/Masterarbeit.out.r41 b/docs/Thesis/Masterarbeit.out.r41 deleted file mode 100755 index 3c7c7dea8d9f42d31536a9f087edb72b696e26ef..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.out.r41 +++ /dev/null @@ -1,42 +0,0 @@ -\BOOKMARK [0][-]{chapter.1}{Introduction}{}% 1 -\BOOKMARK [0][-]{chapter.2}{Motivation}{}% 2 -\BOOKMARK [0][-]{chapter.3}{Related Work}{}% 3 -\BOOKMARK [0][-]{chapter.4}{Theoretical Background}{}% 4 -\BOOKMARK [1][-]{section.4.1}{Input/Output Extended Finite Automaton\(I/O-EFA\)}{chapter.4}% 5 -\BOOKMARK [1][-]{section.4.2}{Input/Output Transition System}{chapter.4}% 6 -\BOOKMARK [1][-]{section.4.3}{Simulation relation}{chapter.4}% 7 -\BOOKMARK [0][-]{chapter.5}{Using Isabelle prove assistant for compatibility check}{}% 8 -\BOOKMARK [1][-]{section.5.1}{Simulink components}{chapter.5}% 9 -\BOOKMARK [1][-]{section.5.2}{Application of Isabelle}{chapter.5}% 10 -\BOOKMARK [1][-]{section.5.3}{Global variables test using Isabelle theorem prover}{chapter.5}% 11 -\BOOKMARK [0][-]{chapter.6}{Elimination of internal variables of I/O-EFA automatons that including non-linear parts}{}% 12 -\BOOKMARK [1][-]{section.6.1}{Z3 Solver basics}{chapter.6}% 13 -\BOOKMARK [1][-]{section.6.2}{Exemplified workflow of matching internal variables of I/O-EFAs containing non-linear dependencies}{chapter.6}% 14 -\BOOKMARK [2][-]{subsection.6.2.1}{Previous approach}{section.6.2}% 15 -\BOOKMARK [2][-]{subsection.6.2.2}{Automatons for comparison}{section.6.2}% 16 -\BOOKMARK [2][-]{subsection.6.2.3}{First step of the procedure. Detecting non-linear equations.}{section.6.2}% 17 -\BOOKMARK [2][-]{subsection.6.2.4}{Second step of the procedure. Calculation of linear coefficients.}{section.6.2}% 18 -\BOOKMARK [2][-]{subsection.6.2.5}{Unfolding and simulation}{section.6.2}% 19 -\BOOKMARK [0][-]{chapter.7}{Index tree optimization for transition filtering}{}% 20 -\BOOKMARK [1][-]{section.7.1}{Previous approach of transition filtering optimization}{chapter.7}% 21 -\BOOKMARK [1][-]{section.7.2}{Building of index tree}{chapter.7}% 22 -\BOOKMARK [1][-]{section.7.3}{Evaluation}{chapter.7}% 23 -\BOOKMARK [0][-]{chapter.8}{Clone detection and transformation to I/O-FEA of control flow graphs}{}% 24 -\BOOKMARK [1][-]{section.8.1}{Approach with control flow graphs trees}{chapter.8}% 25 -\BOOKMARK [1][-]{section.8.2}{Applied approach for substitution, clone detection and separation on output port basis}{chapter.8}% 26 -\BOOKMARK [2][-]{subsection.8.2.1}{Substitution}{section.8.2}% 27 -\BOOKMARK [2][-]{subsection.8.2.2}{Clone detection}{section.8.2}% 28 -\BOOKMARK [2][-]{subsection.8.2.3}{Separation on output port basis}{section.8.2}% 29 -\BOOKMARK [1][-]{section.8.3}{Improvements}{chapter.8}% 30 -\BOOKMARK [0][-]{chapter.9}{Disjunctive Normal Form Optimization}{}% 31 -\BOOKMARK [1][-]{section.9.1}{1st Step: Guard to Guard Normal Form \(GNF\) Transformation}{chapter.9}% 32 -\BOOKMARK [1][-]{section.9.2}{2nd Step: Guard-NF to Guard Disjunctive Normal Form \(GDNF\) Transformation}{chapter.9}% 33 -\BOOKMARK [2][-]{subsection.9.2.1}{3rd Step: Guard-DNF to Hash-Guard Disjunctive Normal Form \(HGDNF\) Transformation}{section.9.2}% 34 -\BOOKMARK [2][-]{subsection.9.2.2}{4th Step: HGDNF to Optimized HGDNF Transformation}{section.9.2}% 35 -\BOOKMARK [0][-]{chapter.10}{Code Listings}{}% 36 -\BOOKMARK [1][-]{section.10.1}{Isabelle listing}{chapter.10}% 37 -\BOOKMARK [1][-]{section.10.2}{Z3 listings}{chapter.10}% 38 -\BOOKMARK [1][-]{section.10.3}{Java listings}{chapter.10}% 39 -\BOOKMARK [0][-]{chapter.11}{Zusammenfassung und Ausblick}{}% 40 -\BOOKMARK [0][-]{figure.caption.25}{Literaturverzeichnis}{}% 41 -\BOOKMARK [0][-]{appendix.A}{z.B. Programmdokumentation}{}% 42 diff --git a/docs/Thesis/Masterarbeit.pdf b/docs/Thesis/Masterarbeit.pdf deleted file mode 100644 index cb0a74073d926634466f2feb0d0321ac91604b9e..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/Masterarbeit.pdf and /dev/null differ diff --git a/docs/Thesis/Masterarbeit.tex b/docs/Thesis/Masterarbeit.tex deleted file mode 100755 index 89cc4f44c08f6c1a342a0ea969d2000e13af8f44..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.tex +++ /dev/null @@ -1,130 +0,0 @@ -\documentclass[a4paper,11pt,oneside,openright]{report} - -\usepackage{graphicx} -%\usepackage{ngerman} -\usepackage[utf8x]{inputenc} -\usepackage{fancyvrb} -\usepackage{courier} -\usepackage{helvet} -\usepackage{tikz} -\usepackage{xcolor} -\usepackage{pdfpages} -\usepackage[strict]{changepage} -\usepackage{hyperref} -\usepackage{caption} -\usepackage{booktabs, multicol, multirow, bigstrut} -\usepackage{amsmath} -\usepackage{bm} -\usepackage{booktabs, multicol, multirow, bigstrut} -\usepackage{enumitem} - -\usepackage{amsthm} -\theoremstyle{definition} -\newtheorem{definition}{Definition}[section] - -\usepackage{helvet} - -\newsavebox\MBox -\newcommand\Cline[2][red]{{\sbox\MBox{$#2$}% - \rlap{\usebox\MBox}\color{#1}\rule[-1.2\dp\MBox]{\wd\MBox}{0.5pt}}} - - - -\pdfoptionpdfminorversion=6 - -% \definecolor{se_dark_blue}{RGB}{0,103,166} % powerpoint -\definecolor{se_dark_blue}{RGB}{0,96,178} % website -% \definecolor{se_light_blue}{RGB}{119,158,201} % powerpoint -\definecolor{se_light_blue}{RGB}{129,160,225} % website - - -%% setup listings -\usepackage{listings} -\lstset{ - numbers=left, - numberstyle=\tiny, - numbersep=5pt, - xleftmargin=11pt, - xrightmargin=4pt, - frame=single, - aboveskip=0pt, - belowskip=-6pt, - sensitive=true, - float=!t, - breaklines=false, - captionpos=b, - tabsize=2, - showstringspaces=false, - basicstyle=\small\ttfamily, - morecomment=[l]{//}, - morecomment=[s][\itshape]{/**}{*/} -} - -%% defines the listings laguage named 'MontiArc' derived from the language 'Java' -%% adding the below listed keywords. See -%% ftp://ftp.tex.ac.uk/tex-archive/macros/latex/contrib/listings/listings.pdf -%% for listings documentation -\lstdefinelanguage{MontiArc}[]{Java}{ - morekeywords={component, port, in, out, inv, package, import, connect, autoconnect} -} - -% Seite einrichten -\setlength{\voffset}{-1in} -\setlength{\hoffset}{-1in} - -\setlength{\topmargin}{2.5cm} -\setlength{\headheight}{0cm} -\setlength{\headsep}{0cm} -\setlength{\oddsidemargin}{3,3cm} % innen ein wenig mehr Rand für die Klebebindung -\setlength{\evensidemargin}{2,7cm} % dafür außen ein wenig weniger -\setlength{\textwidth}{15cm} -\setlength{\textheight}{23,5cm} -\setlength{\parindent}{0cm} - -\newcommand{\emptyLine}{{\LARGE ~\\}} - -\begin{document} - -% Einrücken von Absätzen verhindern und 1.5 Zeilen Absatzabstand -\setlength{\parindent}{0pt} -\setlength{\parskip}{1.5ex plus0.5ex minus0.5ex} - -\input{src/tex/cover_en} % English cover - -\clearpage - -% Erklaerung -\includepdf[pages={1},offset=2.5cm -2.5cm]{Formular_Eidesstattliche_Versicherung_neu.pdf} - -\clearpage - -\input{src/tex/abstract} - -\tableofcontents - -\clearpage - -% Ab erstem Kapitel Seiten arabisch zählen -\setcounter{page}{1} -\pagenumbering{arabic} - -\input{src/tex/introduction} -\input{src/tex/theoreticalBackground} -\input{src/tex/technicalRequisites} -\input{src/tex/simulationPlatform} - -\input{src/tex/evaluation} -\input{src/tex/futureWork} -\input{src/tex/conclusion} - -%\input{src/tex/literature.tex} - -\bibliographystyle{alpha} -\addcontentsline{toc}{chapter}{Bibliography} -\bibliography{src/bib/Literatur} - -% Begin Anhang -%\appendix -%\input{src/tex/appendix_docu} - -\end{document} diff --git a/docs/Thesis/Masterarbeit.toc b/docs/Thesis/Masterarbeit.toc deleted file mode 100644 index c4239222b8b41931b9c54a3e23f8f8fa99592736..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.toc +++ /dev/null @@ -1,50 +0,0 @@ -\contentsline {chapter}{\numberline {1}Introduction}{1}{chapter.1} -\contentsline {chapter}{\numberline {2}Preliminaries}{5}{chapter.2} -\contentsline {section}{\numberline {2.1}Massive multiplayer online gaming}{5}{section.2.1} -\contentsline {section}{\numberline {2.2}Area of Interest}{6}{section.2.2} -\contentsline {section}{\numberline {2.3}Architectures}{7}{section.2.3} -\contentsline {subsection}{\numberline {2.3.1}Peer-to-peer}{7}{subsection.2.3.1} -\contentsline {subsection}{\numberline {2.3.2}Client/server}{8}{subsection.2.3.2} -\contentsline {subsubsection}{Multi-tier architecture}{9}{section*.6} -\contentsline {section}{\numberline {2.4}Distributing mechanisms}{9}{section.2.4} -\contentsline {subsection}{\numberline {2.4.1}Sharding}{10}{subsection.2.4.1} -\contentsline {subsection}{\numberline {2.4.2}Cloning}{11}{subsection.2.4.2} -\contentsline {subsection}{\numberline {2.4.3}Zoning}{12}{subsection.2.4.3} -\contentsline {subsection}{\numberline {2.4.4}Instancing}{13}{subsection.2.4.4} -\contentsline {section}{\numberline {2.5}Advanced distributed architectures}{14}{section.2.5} -\contentsline {subsection}{\numberline {2.5.1}Proxy-server architecture}{14}{subsection.2.5.1} -\contentsline {subsection}{\numberline {2.5.2}Distributed architecture combined with zoning technique}{16}{subsection.2.5.2} -\contentsline {section}{\numberline {2.6}Model-View-Controller pattern}{18}{section.2.6} -\contentsline {chapter}{\numberline {3}Technical Requisites}{20}{chapter.3} -\contentsline {section}{\numberline {3.1}SmartFoxServer}{20}{section.3.1} -\contentsline {subsection}{\numberline {3.1.1}Web Server}{20}{subsection.3.1.1} -\contentsline {subsection}{\numberline {3.1.2}Web Services}{21}{subsection.3.1.2} -\contentsline {subsection}{\numberline {3.1.3}Data serialization}{21}{subsection.3.1.3} -\contentsline {subsection}{\numberline {3.1.4}Scope Management}{21}{subsection.3.1.4} -\contentsline {subsection}{\numberline {3.1.5}Data access and server monitoring}{22}{subsection.3.1.5} -\contentsline {section}{\numberline {3.2}ThreeJS}{22}{section.3.2} -\contentsline {section}{\numberline {3.3}PostgreSQL database}{23}{section.3.3} -\contentsline {chapter}{\numberline {4}Simulation Platform}{24}{chapter.4} -\contentsline {section}{\numberline {4.1}Challenges}{24}{section.4.1} -\contentsline {section}{\numberline {4.2}Architecture}{25}{section.4.2} -\contentsline {section}{\numberline {4.3}Basic work-flow}{26}{section.4.3} -\contentsline {subsection}{\numberline {4.3.1}Zone level}{28}{subsection.4.3.1} -\contentsline {subsection}{\numberline {4.3.2}Room level}{33}{subsection.4.3.2} -\contentsline {section}{\numberline {4.4}Virtual World}{38}{section.4.4} -\contentsline {subsection}{\numberline {4.4.1}Zoning approach}{40}{subsection.4.4.1} -\contentsline {section}{\numberline {4.5}Path Finder}{42}{section.4.5} -\contentsline {section}{\numberline {4.6}Database optimization}{45}{section.4.6} -\contentsline {section}{\numberline {4.7}Web Communication}{47}{section.4.7} -\contentsline {section}{\numberline {4.8}Simulation}{50}{section.4.8} -\contentsline {subsection}{\numberline {4.8.1}Simulation Controller}{51}{subsection.4.8.1} -\contentsline {subsection}{\numberline {4.8.2}Mediator}{52}{subsection.4.8.2} -\contentsline {subsection}{\numberline {4.8.3}Scenarios}{53}{subsection.4.8.3} -\contentsline {subsection}{\numberline {4.8.4}Synchronization and Visualization}{56}{subsection.4.8.4} -\contentsline {section}{\numberline {4.9}Configuration}{60}{section.4.9} -\contentsline {section}{\numberline {4.10}Security}{61}{section.4.10} -\contentsline {chapter}{\numberline {5}Evaluation}{63}{chapter.5} -\contentsline {chapter}{\numberline {6}Future Work}{66}{chapter.6} -\contentsline {section}{\numberline {6.1}Single simulation per vehicle}{66}{section.6.1} -\contentsline {section}{\numberline {6.2}Online model development, test and deployment}{67}{section.6.2} -\contentsline {chapter}{\numberline {7}Conclusion}{69}{chapter.7} -\contentsline {chapter}{Bibliography}{70}{chapter.7} diff --git a/docs/Thesis/Masterarbeit.toc.mine b/docs/Thesis/Masterarbeit.toc.mine deleted file mode 100755 index 3fd752a3806a3f622aec01485278995f8e1eb68e..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.toc.mine +++ /dev/null @@ -1,15 +0,0 @@ -\contentsline {chapter}{\numberline {1}Einleitung}{1}{chapter.1} -\contentsline {section}{\numberline {1.1}Eins - Eins}{1}{section.1.1} -\contentsline {subsection}{\numberline {1.1.1}Eins - Eins - Eins}{1}{subsection.1.1.1} -\contentsline {chapter}{\numberline {2}Z3 theorem solver}{3}{chapter.2} -\contentsline {section}{\numberline {2.1}Z3 basics}{3}{section.2.1} -\contentsline {chapter}{\numberline {3}Elimination of internal variables of automatons that including non-linear parts}{5}{chapter.3} -\contentsline {section}{\numberline {3.1}Exemplified workflow of matching internal variables }{5}{section.3.1} -\contentsline {subsection}{\numberline {3.1.1}Automatons for comparison}{5}{subsection.3.1.1} -\contentsline {subsection}{\numberline {3.1.2}First step of the procedure. Detecting non-linear equations.}{5}{subsection.3.1.2} -\contentsline {subsection}{\numberline {3.1.3}Second step of the procedure. Calculation of non linear coefficients.}{7}{subsection.3.1.3} -\contentsline {subsection}{\numberline {3.1.4}Unfolding and simulation}{7}{subsection.3.1.4} -\contentsline {chapter}{\numberline {4}Code Listings}{9}{chapter.4} -\contentsline {chapter}{\numberline {5}Zusammenfassung und Ausblick}{11}{chapter.5} -\contentsline {chapter}{Literaturverzeichnis}{13}{figure.caption.11} -\contentsline {chapter}{\numberline {A}z.\,B. Programmdokumentation}{15}{appendix.A} diff --git a/docs/Thesis/Masterarbeit.toc.r40 b/docs/Thesis/Masterarbeit.toc.r40 deleted file mode 100755 index 8d0612122f49b87633b13f6bdf4dedaecb9589a1..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.toc.r40 +++ /dev/null @@ -1,41 +0,0 @@ -\contentsline {chapter}{\numberline {1}Introduction}{1}{chapter.1} -\contentsline {chapter}{\numberline {2}Related Work}{3}{chapter.2} -\contentsline {chapter}{\numberline {3}Theoretical Background}{6}{chapter.3} -\contentsline {section}{\numberline {3.1}Input/Output Extended Finite Automaton(I/O-EFA)}{6}{section.3.1} -\contentsline {section}{\numberline {3.2}Input/Output Transition System}{6}{section.3.2} -\contentsline {section}{\numberline {3.3}Simulation relation}{6}{section.3.3} -\contentsline {chapter}{\numberline {4}Using Isabelle prove assistant for compatibility check}{7}{chapter.4} -\contentsline {section}{\numberline {4.1}Simulink components}{7}{section.4.1} -\contentsline {section}{\numberline {4.2}Application of Isabelle}{9}{section.4.2} -\contentsline {section}{\numberline {4.3}Global variables test using Isabelle theorem prover}{10}{section.4.3} -\contentsline {chapter}{\numberline {5}Elimination of internal variables of I/O-EFA automatons that including non-linear parts}{12}{chapter.5} -\contentsline {section}{\numberline {5.1}Z3 Solver basics}{12}{section.5.1} -\contentsline {section}{\numberline {5.2}Exemplified workflow of matching internal variables of I/O-EFAs containing non-linear dependencies}{14}{section.5.2} -\contentsline {subsection}{\numberline {5.2.1}Previous approach}{14}{subsection.5.2.1} -\contentsline {subsection}{\numberline {5.2.2}Automatons for comparison}{15}{subsection.5.2.2} -\contentsline {subsection}{\numberline {5.2.3}First step of the procedure. Detecting non-linear equations.}{15}{subsection.5.2.3} -\contentsline {subsection}{\numberline {5.2.4}Second step of the procedure. Calculation of linear coefficients.}{17}{subsection.5.2.4} -\contentsline {subsection}{\numberline {5.2.5}Unfolding and simulation}{17}{subsection.5.2.5} -\contentsline {chapter}{\numberline {6}Index tree optimization for transition filtering}{20}{chapter.6} -\contentsline {section}{\numberline {6.1}Previous approach of transition filtering optimization}{20}{section.6.1} -\contentsline {section}{\numberline {6.2}Building of index tree}{21}{section.6.2} -\contentsline {section}{\numberline {6.3}Evaluation}{23}{section.6.3} -\contentsline {chapter}{\numberline {7}Clone detection and transformation to I/O-FEA of control flow graphs}{26}{chapter.7} -\contentsline {section}{\numberline {7.1}Approach with control flow graphs trees}{26}{section.7.1} -\contentsline {section}{\numberline {7.2}Applied approach for substitution, clone detection and separation on output port basis}{29}{section.7.2} -\contentsline {subsection}{\numberline {7.2.1}Substitution}{29}{subsection.7.2.1} -\contentsline {subsection}{\numberline {7.2.2}Clone detection}{30}{subsection.7.2.2} -\contentsline {subsection}{\numberline {7.2.3}Separation on output port basis}{31}{subsection.7.2.3} -\contentsline {section}{\numberline {7.3}Improvements}{32}{section.7.3} -\contentsline {chapter}{\numberline {8}Disjunctive Normal Form Optimization}{33}{chapter.8} -\contentsline {section}{\numberline {8.1}1st Step: Guard to Guard Normal Form (GNF) Transformation}{33}{section.8.1} -\contentsline {section}{\numberline {8.2}2nd Step: Guard-NF to Guard Disjunctive Normal Form (GDNF) Transformation}{34}{section.8.2} -\contentsline {subsection}{\numberline {8.2.1}3rd Step: Guard-DNF to Hash-Guard Disjunctive Normal Form (HGDNF) Transformation}{34}{subsection.8.2.1} -\contentsline {subsection}{\numberline {8.2.2}4th Step: HGDNF to Optimized HGDNF Transformation}{36}{subsection.8.2.2} -\contentsline {chapter}{\numberline {9}Code Listings}{37}{chapter.9} -\contentsline {section}{\numberline {9.1}Isabelle listing}{37}{section.9.1} -\contentsline {section}{\numberline {9.2}Z3 listings}{38}{section.9.2} -\contentsline {section}{\numberline {9.3}Java listings}{42}{section.9.3} -\contentsline {chapter}{\numberline {10}Zusammenfassung und Ausblick}{44}{chapter.10} -\contentsline {chapter}{Literaturverzeichnis}{45}{figure.caption.23} -\contentsline {chapter}{\numberline {A}z.\tmspace +\thinmuskip {.1667em}B. Programmdokumentation}{49}{appendix.A} diff --git a/docs/Thesis/Masterarbeit.toc.r41 b/docs/Thesis/Masterarbeit.toc.r41 deleted file mode 100755 index 5e49a6093ed03a87f2d51e3b5df73aaacefa8dfc..0000000000000000000000000000000000000000 --- a/docs/Thesis/Masterarbeit.toc.r41 +++ /dev/null @@ -1,42 +0,0 @@ -\contentsline {chapter}{\numberline {1}Introduction}{1}{chapter.1} -\contentsline {chapter}{\numberline {2}Motivation}{3}{chapter.2} -\contentsline {chapter}{\numberline {3}Related Work}{7}{chapter.3} -\contentsline {chapter}{\numberline {4}Theoretical Background}{10}{chapter.4} -\contentsline {section}{\numberline {4.1}Input/Output Extended Finite Automaton(I/O-EFA)}{10}{section.4.1} -\contentsline {section}{\numberline {4.2}Input/Output Transition System}{10}{section.4.2} -\contentsline {section}{\numberline {4.3}Simulation relation}{10}{section.4.3} -\contentsline {chapter}{\numberline {5}Using Isabelle prove assistant for compatibility check}{11}{chapter.5} -\contentsline {section}{\numberline {5.1}Simulink components}{11}{section.5.1} -\contentsline {section}{\numberline {5.2}Application of Isabelle}{13}{section.5.2} -\contentsline {section}{\numberline {5.3}Global variables test using Isabelle theorem prover}{14}{section.5.3} -\contentsline {chapter}{\numberline {6}Elimination of internal variables of I/O-EFA automatons that including non-linear parts}{16}{chapter.6} -\contentsline {section}{\numberline {6.1}Z3 Solver basics}{16}{section.6.1} -\contentsline {section}{\numberline {6.2}Exemplified workflow of matching internal variables of I/O-EFAs containing non-linear dependencies}{18}{section.6.2} -\contentsline {subsection}{\numberline {6.2.1}Previous approach}{18}{subsection.6.2.1} -\contentsline {subsection}{\numberline {6.2.2}Automatons for comparison}{19}{subsection.6.2.2} -\contentsline {subsection}{\numberline {6.2.3}First step of the procedure. Detecting non-linear equations.}{19}{subsection.6.2.3} -\contentsline {subsection}{\numberline {6.2.4}Second step of the procedure. Calculation of linear coefficients.}{21}{subsection.6.2.4} -\contentsline {subsection}{\numberline {6.2.5}Unfolding and simulation}{21}{subsection.6.2.5} -\contentsline {chapter}{\numberline {7}Index tree optimization for transition filtering}{24}{chapter.7} -\contentsline {section}{\numberline {7.1}Previous approach of transition filtering optimization}{24}{section.7.1} -\contentsline {section}{\numberline {7.2}Building of index tree}{25}{section.7.2} -\contentsline {section}{\numberline {7.3}Evaluation}{27}{section.7.3} -\contentsline {chapter}{\numberline {8}Clone detection and transformation to I/O-FEA of control flow graphs}{30}{chapter.8} -\contentsline {section}{\numberline {8.1}Approach with control flow graphs trees}{30}{section.8.1} -\contentsline {section}{\numberline {8.2}Applied approach for substitution, clone detection and separation on output port basis}{33}{section.8.2} -\contentsline {subsection}{\numberline {8.2.1}Substitution}{33}{subsection.8.2.1} -\contentsline {subsection}{\numberline {8.2.2}Clone detection}{34}{subsection.8.2.2} -\contentsline {subsection}{\numberline {8.2.3}Separation on output port basis}{35}{subsection.8.2.3} -\contentsline {section}{\numberline {8.3}Improvements}{36}{section.8.3} -\contentsline {chapter}{\numberline {9}Disjunctive Normal Form Optimization}{37}{chapter.9} -\contentsline {section}{\numberline {9.1}1st Step: Guard to Guard Normal Form (GNF) Transformation}{37}{section.9.1} -\contentsline {section}{\numberline {9.2}2nd Step: Guard-NF to Guard Disjunctive Normal Form (GDNF) Transformation}{38}{section.9.2} -\contentsline {subsection}{\numberline {9.2.1}3rd Step: Guard-DNF to Hash-Guard Disjunctive Normal Form (HGDNF) Transformation}{38}{subsection.9.2.1} -\contentsline {subsection}{\numberline {9.2.2}4th Step: HGDNF to Optimized HGDNF Transformation}{40}{subsection.9.2.2} -\contentsline {chapter}{\numberline {10}Code Listings}{41}{chapter.10} -\contentsline {section}{\numberline {10.1}Isabelle listing}{41}{section.10.1} -\contentsline {section}{\numberline {10.2}Z3 listings}{42}{section.10.2} -\contentsline {section}{\numberline {10.3}Java listings}{46}{section.10.3} -\contentsline {chapter}{\numberline {11}Zusammenfassung und Ausblick}{48}{chapter.11} -\contentsline {chapter}{Literaturverzeichnis}{49}{figure.caption.25} -\contentsline {chapter}{\numberline {A}z.\tmspace +\thinmuskip {.1667em}B. Programmdokumentation}{53}{appendix.A} diff --git a/docs/Thesis/Statutory_Declaration_in_Lieu_of_an_Oath.pdf b/docs/Thesis/Statutory_Declaration_in_Lieu_of_an_Oath.pdf deleted file mode 100644 index 08f4ad1bc97ea0adec3324785e0abd18e16aac9d..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/Statutory_Declaration_in_Lieu_of_an_Oath.pdf and /dev/null differ diff --git a/docs/Thesis/commands/biblatex b/docs/Thesis/commands/biblatex deleted file mode 100755 index 3928c0cfc40291d6b3f9e4d906707ba4f11cdd4f..0000000000000000000000000000000000000000 --- a/docs/Thesis/commands/biblatex +++ /dev/null @@ -1,115 +0,0 @@ -#!/bin/bash -# biblatex runs latex and bibtex as often as necessary, -# It detects citation problems and in this case reruns bibtex. -# It detects label-changes and reruns latex (up to 3 times), -# However, if labels are defined twice, it always runs latex three times. -# -# REMARK: a slightly changed bibliography does not cause a bibtex call -# because this is not detected. -# -# BUG: (from latex:) A changed (sub..) section name is not recognised and -# therefore the last run incorporating the changed table of contents (toc) -# not executed. -# - -if [ $# -eq 1 ] -then - datei=`dirname $1`/`basename $1 .tex` - latex=latex -elif [ $# -eq 2 ] -then - datei=`dirname $2`/`basename $2 .tex` - latex=$1 -else - echo 'usage: $0 [latex-command] latex-file[.tex]' - exit 1 -fi - -temp=$datei.blx - -echo $0: $latex $datei \(pass 1 is always performed\) -$latex $datei -error=$? -if [ $error -ne 0 ] -then exit $error -fi - - # part 1: expand of all .aux files in $temp - grep '\\@input{' $datei.aux \ - | sed -e 's/\\@input{//g' -e 's/}//g' > $temp.2 - echo $0: Expanding .aux-files: $datei.aux `cat $temp.2` - cat $datei.aux `cat $temp.2` > $temp - rm $temp.2 - -# is there a bibliography entry? (else skip 2-5) -grep '\\bibdata{' $temp >/dev/null -if [ $? -eq 0 ] -then - - # part 2: actual and desired citations in $temp.4 and $temp.5 - grep '\\citation{' $temp \ - | sed -e 's/\\citation{//g' -e 's/}//g' \ - | sort -u > $temp.4 - grep '\\bibcite{' $temp \ - | sed -e 's/\\bibcite{//g' -e 's/}.*$//g' \ - | sort -u > $temp.5 - - echo $0: Required citations: `cat $temp.4 | wc -l` - echo $0: Given citations: `cat $temp.5 | wc -l` - diff $temp.4 $temp.5 >/dev/null - diffs=$? - rm $temp.4 $temp.5 - - # part 3: check are there citation problems? - grep 'Citation .* undefined' $datei.log >/dev/null - citations=$? - - # part 4: is a bib-file newer than the bbl-file? - grep '\\bibdata{' $temp \ - | sed -e 's/\\bibdata{//g' -e 's/}/.bib/g' -e 's/,/.bib\ -/g' > $temp.2 - bibfilenew=0 - for i in `cat $temp.2` - do - if [ $i -nt $datei.bbl ] - then - bibfilenew=1 - fi - done - rm $temp.2 - - # part 5: execute bibtex - if [ $citations -eq 0 -o $diffs -ne 0 -o $bibfilenew -eq 0 ] - then - echo $0: bibtex $datei \(citation problems and bibliography entries\) - bibtex $datei - error=$? - if [ $error -ne 0 ] - then exit $error - fi - - echo $0: $latex $datei \(because of citation problems\) - $latex $datei - error=$? - if [ $error -ne 0 ] - then exit $error - fi - fi - -fi - -# part 6: three times repeat, to get cross-references right -for i in 1 2 3 -do - grep 'Rerun to get cross-references right' $datei.log >/dev/null - if [ $? -eq 0 ] - then - echo $0: $latex $datei \(to get cross-references right, pass $i\) - $latex $datei - error=$? - if [ $error -ne 0 ] - then exit $error - fi - fi -done - diff --git a/docs/Thesis/commands/cygwinMake.bat b/docs/Thesis/commands/cygwinMake.bat deleted file mode 100755 index 130daca95b25f2e3a08a6a6d1fce6938900fd6b3..0000000000000000000000000000000000000000 --- a/docs/Thesis/commands/cygwinMake.bat +++ /dev/null @@ -1 +0,0 @@ -%1 --login -i -c 'make --directory="%2" %3' \ No newline at end of file diff --git a/docs/Thesis/commands/ppt2eps/ostp-client-ppt2eps-2.3.4.jar b/docs/Thesis/commands/ppt2eps/ostp-client-ppt2eps-2.3.4.jar deleted file mode 100755 index 02d5e020593c980cead8b8ee16925245f845201b..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/commands/ppt2eps/ostp-client-ppt2eps-2.3.4.jar and /dev/null differ diff --git a/docs/Thesis/gen/Architectures.pdf b/docs/Thesis/gen/Architectures.pdf deleted file mode 100644 index a97cb94ccf553153544238373ec67388715f805d..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/Architectures.pdf and /dev/null differ diff --git a/docs/Thesis/gen/AreaOfInterest.pdf b/docs/Thesis/gen/AreaOfInterest.pdf deleted file mode 100644 index 8ba3f60355b77687ea824097969ee77ca6b2ffe2..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/AreaOfInterest.pdf and /dev/null differ diff --git a/docs/Thesis/gen/Authentication.pdf b/docs/Thesis/gen/Authentication.pdf deleted file mode 100644 index 9ca0fcd2a2533ff01edf2c8f2a01b81c62ff661d..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/Authentication.pdf and /dev/null differ diff --git a/docs/Thesis/gen/Cloning.pdf b/docs/Thesis/gen/Cloning.pdf deleted file mode 100644 index 60385237389f2e010eceff893216ccd12a57d227..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/Cloning.pdf and /dev/null differ diff --git a/docs/Thesis/gen/DistributedZoning.pdf b/docs/Thesis/gen/DistributedZoning.pdf deleted file mode 100644 index 6f8118be31c64675b7c68ea6deea5cb6b050d88e..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/DistributedZoning.pdf and /dev/null differ diff --git a/docs/Thesis/gen/ERD.pdf b/docs/Thesis/gen/ERD.pdf deleted file mode 100644 index b98adcb774ebc1134ce2dd3a5c8d4ea7ad623934..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/ERD.pdf and /dev/null differ diff --git a/docs/Thesis/gen/MVC.pdf b/docs/Thesis/gen/MVC.pdf deleted file mode 100644 index 246a2b8eaa86add8b424d809c9146a3eb417d50f..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/MVC.pdf and /dev/null differ diff --git a/docs/Thesis/gen/MapSplitting.pdf b/docs/Thesis/gen/MapSplitting.pdf deleted file mode 100644 index 58ec69809633ae6b07292ac027293f5ac8743ff5..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/MapSplitting.pdf and /dev/null differ diff --git a/docs/Thesis/gen/Overview.pdf b/docs/Thesis/gen/Overview.pdf deleted file mode 100644 index 3cf3dfb42a94394acd95bf440de1e52a0c7f4a61..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/Overview.pdf and /dev/null differ diff --git a/docs/Thesis/gen/P2PMulticast.pdf b/docs/Thesis/gen/P2PMulticast.pdf deleted file mode 100644 index c50fc9e24752ac37e21907e473fc5b49c63e2507..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/P2PMulticast.pdf and /dev/null differ diff --git a/docs/Thesis/gen/PathFinder.pdf b/docs/Thesis/gen/PathFinder.pdf deleted file mode 100644 index 937a3bf610ebc1102f500fbc9a5a3838cb3bf16a..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/PathFinder.pdf and /dev/null differ diff --git a/docs/Thesis/gen/ProxyServer.pdf b/docs/Thesis/gen/ProxyServer.pdf deleted file mode 100644 index 7c4481edda1b142faa85d2b20668a8fc5adbc7fe..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/ProxyServer.pdf and /dev/null differ diff --git a/docs/Thesis/gen/PublishSubscribe.pdf b/docs/Thesis/gen/PublishSubscribe.pdf deleted file mode 100644 index 1411155012c4c4a00f802f57ccf708997b387eee..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/PublishSubscribe.pdf and /dev/null differ diff --git a/docs/Thesis/gen/ScenarioList.pdf b/docs/Thesis/gen/ScenarioList.pdf deleted file mode 100644 index aeedf01f3fe5f909f232b6e1987ceec5333cb61e..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/ScenarioList.pdf and /dev/null differ diff --git a/docs/Thesis/gen/Sharding.pdf b/docs/Thesis/gen/Sharding.pdf deleted file mode 100644 index 8913ef36309914d0e70e585d4c508866900395b5..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/Sharding.pdf and /dev/null differ diff --git a/docs/Thesis/gen/Simulation.pdf b/docs/Thesis/gen/Simulation.pdf deleted file mode 100644 index 2d7567b946f571cb774e557b603dc695da9ab029..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/Simulation.pdf and /dev/null differ diff --git a/docs/Thesis/gen/ThreeTierArch.pdf b/docs/Thesis/gen/ThreeTierArch.pdf deleted file mode 100644 index 8c0264b93d8ba950905fc3964630aebb6091bc1d..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/ThreeTierArch.pdf and /dev/null differ diff --git a/docs/Thesis/gen/Zoning.pdf b/docs/Thesis/gen/Zoning.pdf deleted file mode 100644 index bb056fa904bdd2003e547942a0fef6f83efe7467..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/gen/Zoning.pdf and /dev/null differ diff --git a/docs/Thesis/gen/ppt2eps.log b/docs/Thesis/gen/ppt2eps.log deleted file mode 100644 index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..0000000000000000000000000000000000000000 diff --git a/docs/Thesis/literature/3DSymSystem-M.Ambroz.pdf b/docs/Thesis/literature/3DSymSystem-M.Ambroz.pdf deleted file mode 100644 index e0626a00c5dce5dc2a7299ff23cfecce18ea7034..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/3DSymSystem-M.Ambroz.pdf and /dev/null differ diff --git a/docs/Thesis/literature/Boss-ADV-DARPA2007.pdf b/docs/Thesis/literature/Boss-ADV-DARPA2007.pdf deleted file mode 100644 index efbf159e3c4c29c76ac04d3d00bdf018b3bdb809..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/Boss-ADV-DARPA2007.pdf and /dev/null differ diff --git a/docs/Thesis/literature/Caroline-An-Autonomoulsy-Driving-Vehicle-for-Urban-Environments.pdf b/docs/Thesis/literature/Caroline-An-Autonomoulsy-Driving-Vehicle-for-Urban-Environments.pdf deleted file mode 100644 index 0c85cc01499528be00eef1a5b9b9cec3912143c6..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/Caroline-An-Autonomoulsy-Driving-Vehicle-for-Urban-Environments.pdf and /dev/null differ diff --git a/docs/Thesis/literature/CommunicationArchitectureForMMG.pdf b/docs/Thesis/literature/CommunicationArchitectureForMMG.pdf deleted file mode 100644 index ffe6bd34d82d8cfc8b5130354827a7817b60a347..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/CommunicationArchitectureForMMG.pdf and /dev/null differ diff --git a/docs/Thesis/literature/CyberWalk.pdf b/docs/Thesis/literature/CyberWalk.pdf deleted file mode 100644 index 6507857b2b6efc7a739a7784fd8be92820f3fa4e..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/CyberWalk.pdf and /dev/null differ diff --git a/docs/Thesis/literature/DAfMMO-RPG.pdf b/docs/Thesis/literature/DAfMMO-RPG.pdf deleted file mode 100644 index 33148ad947b959f0835032e6a31f5df54caffd86..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/DAfMMO-RPG.pdf and /dev/null differ diff --git a/docs/Thesis/literature/DistributedMPlSS.pdf b/docs/Thesis/literature/DistributedMPlSS.pdf deleted file mode 100644 index 974e8d24aec7abebdbc28d7da6631418d906c73e..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/DistributedMPlSS.pdf and /dev/null differ diff --git a/docs/Thesis/literature/Engineering-Autonomous-Driving-Software.pdf b/docs/Thesis/literature/Engineering-Autonomous-Driving-Software.pdf deleted file mode 100644 index 69ed2208ca61aee0ecb1f518474302ef0f7c0b6c..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/Engineering-Autonomous-Driving-Software.pdf and /dev/null differ diff --git a/docs/Thesis/literature/LatencyEvaluation.pdf b/docs/Thesis/literature/LatencyEvaluation.pdf deleted file mode 100644 index e1085bd99a987e067710b0fe2b776683b44eda14..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/LatencyEvaluation.pdf and /dev/null differ diff --git a/docs/Thesis/literature/MMORPGengineArchitecture.pdf b/docs/Thesis/literature/MMORPGengineArchitecture.pdf deleted file mode 100644 index dc19f62861a62c8253a1d45db6807229f62a9adf..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/MMORPGengineArchitecture.pdf and /dev/null differ diff --git a/docs/Thesis/literature/Maneuver-Based_Trajectory_Planning_for_H.pdf b/docs/Thesis/literature/Maneuver-Based_Trajectory_Planning_for_H.pdf deleted file mode 100644 index 86a283e35571725e5de4d521e4b0a2f2931d0e98..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/Maneuver-Based_Trajectory_Planning_for_H.pdf and /dev/null differ diff --git a/docs/Thesis/literature/MiMazeMGI.pdf b/docs/Thesis/literature/MiMazeMGI.pdf deleted file mode 100644 index dd90258c2dafec6aa654da40ee842c3ba01a20c0..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/MiMazeMGI.pdf and /dev/null differ diff --git a/docs/Thesis/literature/P2PSfMMG.pdf b/docs/Thesis/literature/P2PSfMMG.pdf deleted file mode 100644 index 5ba952d66a916f156bb3bc0b9dea33eed37ff0d0..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/P2PSfMMG.pdf and /dev/null differ diff --git a/docs/Thesis/literature/ScalableArchitectureMG.pdf b/docs/Thesis/literature/ScalableArchitectureMG.pdf deleted file mode 100644 index 156decf5ea33a03fe695bae6644f0199c025ea87..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/ScalableArchitectureMG.pdf and /dev/null differ diff --git a/docs/Thesis/literature/ServerSelectionAlgorithm.pdf b/docs/Thesis/literature/ServerSelectionAlgorithm.pdf deleted file mode 100644 index b5d723934f87763417b07cc87cfe3f570432e0d4..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/ServerSelectionAlgorithm.pdf and /dev/null differ diff --git a/docs/Thesis/literature/StR-AVMHD-K.Dresner.pdf b/docs/Thesis/literature/StR-AVMHD-K.Dresner.pdf deleted file mode 100644 index 8f301a09e1f5e51cb759d0a780e519a825251f92..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/StR-AVMHD-K.Dresner.pdf and /dev/null differ diff --git a/docs/Thesis/literature/TrafficCharacteristicsOfMMORPG.pdf b/docs/Thesis/literature/TrafficCharacteristicsOfMMORPG.pdf deleted file mode 100644 index 102b54de8317b6877689812bb0a0af98b0fd4cb8..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/TrafficCharacteristicsOfMMORPG.pdf and /dev/null differ diff --git a/docs/Thesis/literature/VoronoiVsDelaunyTriangulations.pdf b/docs/Thesis/literature/VoronoiVsDelaunyTriangulations.pdf deleted file mode 100644 index 414cd8a512b3121be7b0d61249812f547cf7478e..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/literature/VoronoiVsDelaunyTriangulations.pdf and /dev/null differ diff --git a/docs/Thesis/makefile b/docs/Thesis/makefile deleted file mode 100755 index da36dfbf277d9d528399704222cfddc23de96f17..0000000000000000000000000000000000000000 --- a/docs/Thesis/makefile +++ /dev/null @@ -1,107 +0,0 @@ -###################################################################### -# -# makefile -# fuer normale Latex-Projekte mit ppt-Bildern -# -# Anzupassen sind: TARGET, SOURCES, PICSPPT -# (und sonst normalerweise nichts, also nur die -# folgenden vier Zeilen) - -# Ziel: -TARGET=Masterarbeit.pdf - -SOURCES=$(wildcard *.tex) $(wildcard tex/*.tex) - -PICSPPT=$(wildcard src/pic/*.ppt) -PICSPPTX=$(shell find src/pic/ -regex "[^~]*\.pptx" -type f) - -BIB=src/bib/Literatur.bib - -IMG=$(wildcard img/*.*) - -LISTINGS=$(wildcard src/listings/*.*) $(wildcard lst/*.*) - -###################################################################### -# alles zusammen (und am Ende einige Hilfsinfos ausgeben) -all: at-start check-commands $(TARGET) warnings - @echo -------------------------- - @echo ghostview $(TARGET) \& - @echo gmake clean - -# Zu Beginn einige Hilfsinfos ausgeben -at-start: - @echo target: $(TARGET) - @echo tex-files: $(SOURCES) - @echo ppt: $(PICSPPT) - @echo pptx: $(PICSPPTX) - @echo imgs: $(IMG) - -.SUFFIXES: $(SUFFIXES) .ppt .gflag .pptx .gxflag .tex .eps .ps .pdf - -.PHONY : all at-start clean warnings check-commands biblatex - -# %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -# generate pics from ppt: -.ppt.gflag: - mkdir -p gen - @echo do ppt2eps $< -o gen - @java -jar commands/ppt2eps/ostp-client-ppt2eps-2.3.4.jar $< -o gen 2> gen/ppt2eps.log - touch $@ - -# generate pics from pptx: -.pptx.gxflag: - @mkdir -p gen - @echo do ppt2eps $< -o gen - @java -jar commands/ppt2eps/ostp-client-ppt2eps-2.3.4.jar $< -o gen 2> gen/ppt2eps.log - @touch $@ - -# %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -$(TARGET): $(SOURCES) $(BIB) $(PICSPPT:.ppt=.gflag) $(PICSPPTX:.pptx=.gxflag) $(LISTINGS) $(IMG) - ./commands/biblatex pdflatex $(TARGET:.pdf=) - -pics: at-start $(PICSPPT:.ppt=.gflag) $(PICSPPTX:.pptx=.gxflag) - -# %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -# ueberfluessigen Schrott loeschen -clean: - @rm -f $(TARGET:.pdf=.aux) $(TARGET:.pdf=.blx) $(TARGET:.pdf=.dvi) - @rm -f $(TARGET:.pdf=.idx) $(TARGET:.pdf=.log) $(TARGET:.pdf=.pdf) - @rm -f $(TARGET:.pdf=.toc) $(TARGET:.pdf=.pdf) $(TARGET:.pdf=.blg) - @rm -f $(TARGET:.pdf=.bbl) - @rm -f $(SOURCES:.tex=.aux) - @rm -f *.bak *~ - -cleanAll: clean - @rm -rf gen - @rm -f $(PICSPPT:.ppt=.gflag) $(PICSPPTX:.pptx=.gxflag) - -# %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -# latex-Warnings nochmal kompakt ausgeben: -warnings: - @-echo "------------ Warnings from bib:" - @-grep arning $(TARGET:.pdf=.blg) - @-echo "------------ Warnings from latex:" - @-grep arning: $(TARGET:.pdf=.log) | wc -l - @awk '/arning:/' RS= $(TARGET:.pdf=.log) - -# %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -# check, ob Kommandos existieren -COMMANDS=latex bibtex grep rm # biblatex -check-commands: - @for i in $(COMMANDS); do\ - which $$i > /dev/null || \ - (echo "ERROR: command $$i not available!"; \ - echo " please install this command first, e.g. from"; \ - echo " http://www.sselab.de/?"; \ - exit -1); \ - done - -open: - pdfopen --file=$(TARGET) - -splchk: spell - -spell: - @for i in $$(find . -type f -name "*.tex" | sed 's/\.tex//' ); do \ - aspell -S -t --encoding=utf-8 --lang=en-US --extra-dicts=./paper.pws -p ./paper.pws -c $$i.tex ; \ - done diff --git a/docs/Thesis/readme.txt b/docs/Thesis/readme.txt deleted file mode 100755 index acda86944fd5b20435d3d36f29657066ad02723e..0000000000000000000000000000000000000000 --- a/docs/Thesis/readme.txt +++ /dev/null @@ -1,14 +0,0 @@ -- Bilder unter src/pic ablegen. -- Latex-Quellen für weitere Kapitel unter src/tex ablegen. -- PDF erzeugen durch 'make' oder 'make all', aufräumen durch make clean. -- Ausgabeordner target in CVS/SVN/GIT ignore setzen! -- make kann unter Windows bspw. mit cygwin genutzt werden (http://www.cygwin.com/). -- zur Ausfürhung wird eine Tex Umgebung benötigt, z.B. MikTek (http://miktex.org/). -- Werden Dateien umbenannt, muss ggf. das makefile angepasst werden. - -Wenn an der Vorlage Anpassungen vorgenommen werden, bitte auch hier nachziehen: -http://www.se-rwth.de/theses/vorlage.v12.zip - -Formulare (Bei Abschlussarbeiten): -- Eidesstattliche Versicherung: Ein Exemplar wird in die Arbeit eingebunden, ein zweites ist im ZPA oder beim Prüfungsausschuss abzugeben beziehungsweise lose beizulegen. -- Logo: Formulare müssen zusammen mit der Anmeldung von BaMa-Arbeiten abgegeben diff --git a/docs/Thesis/src/bib/Literatur.bib b/docs/Thesis/src/bib/Literatur.bib deleted file mode 100755 index cb159b19703a11458d9a1b24b7fa831f912b91f4..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/bib/Literatur.bib +++ /dev/null @@ -1,485 +0,0 @@ -% ========== Autonomous driving vehicles ========== -@article{DBLP:journals/aes/AmbrozKP05, - author = {Miha Ambroz and - S. Krasna and - Ivan Prebil}, - title = {3D road traffic situation simulation system}, - journal = {Advances in Engineering Software}, - volume = {36}, - number = {2}, - pages = {77--86}, - year = {2005}, - url = {https://doi.org/10.1016/j.advengsoft.2004.07.007}, - doi = {10.1016/j.advengsoft.2004.07.007}, - timestamp = {Mon, 05 Jun 2017 12:38:20 +0200}, - biburl = {http://dblp.org/rec/bib/journals/aes/AmbrozKP05}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@article{DBLP:journals/jfr/RauskolbBLMCEFGOSWHNDHMWBBGKR08, - author = {Fred W. Rauskolb and - Kai Berger and - Christian Lipski and - Marcus A. Magnor and - Karsten Cornelsen and - Jan Effertz and - Thomas Form and - Fabian Graefe and - Sebastian Ohl and - Walter Schumacher and - J{\"{o}}rn{-}Marten Wille and - Peter Hecker and - Tobias Nothdurft and - Michael Doering and - Kai Homeier and - Johannes Morgenroth and - Lars C. Wolf and - Christian Basarke and - Christian Berger and - Tim G{\"{u}}lke and - Felix Klose and - Bernhard Rumpe}, - title = {Caroline: An autonomously driving vehicle for urban environments}, - journal = {J. Field Robotics}, - volume = {25}, - number = {9}, - pages = {674--724}, - year = {2008}, - url = {https://doi.org/10.1002/rob.20254}, - doi = {10.1002/rob.20254}, - timestamp = {Thu, 15 Jun 2017 21:29:17 +0200}, - biburl = {http://dblp.org/rec/bib/journals/jfr/RauskolbBLMCEFGOSWHNDHMWBBGKR08}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@inproceedings{DBLP:conf/ijcai/DresnerS07, - author = {Kurt M. Dresner and - Peter Stone}, - title = {Sharing the Road: Autonomous Vehicles Meet Human Drivers}, - booktitle = {{IJCAI} 2007, Proceedings of the 20th International Joint Conference - on Artificial Intelligence, Hyderabad, India, January 6-12, 2007}, - pages = {1263--1268}, - year = {2007}, - url = {http://ijcai.org/Proceedings/07/Papers/204.pdf}, - timestamp = {Wed, 20 Jul 2016 13:58:40 +0200}, - biburl = {http://dblp.org/rec/bib/conf/ijcai/DresnerS07}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@article{DBLP:journals/tits/GlaserVMGN10, - author = {Sebastien Glaser and - Benoit Vanholme and - Sa{\"{\i}}d Mammar and - Dominique Gruyer and - Lydie Nouveliere}, - title = {Maneuver-Based Trajectory Planning for Highly Autonomous Vehicles - on Real Road With Traffic and Driver Interaction}, - journal = {{IEEE} Trans. Intelligent Transportation Systems}, - volume = {11}, - number = {3}, - pages = {589--606}, - year = {2010}, - url = {https://doi.org/10.1109/TITS.2010.2046037}, - doi = {10.1109/TITS.2010.2046037}, - timestamp = {Wed, 17 May 2017 14:25:46 +0200}, - biburl = {http://dblp.org/rec/bib/journals/tits/GlaserVMGN10}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@article{DBLP:journals/jfr/UrmsonABBBCDDGGGHHHKKLMMPPRRSSSSSWWZBBDLNSZSTDF08, - author = {Chris Urmson and - Joshua Anhalt and - Drew Bagnell and - Christopher R. Baker and - Robert Bittner and - M. N. Clark and - John M. Dolan and - Dave Duggins and - Tugrul Galatali and - Christopher Geyer and - Michele Gittleman and - Sam Harbaugh and - Martial Hebert and - Thomas M. Howard and - Sascha Kolski and - Alonzo Kelly and - Maxim Likhachev and - Matthew McNaughton and - Nick Miller and - Kevin M. Peterson and - Brian Pilnick and - Raj Rajkumar and - Paul E. Rybski and - Bryan Salesky and - Young{-}Woo Seo and - Sanjiv Singh and - Jarrod M. Snider and - Anthony Stentz and - William Whittaker and - Ziv Wolkowicki and - Jason Ziglar and - Hong Bae and - Thomas Brown and - Daniel Demitrish and - Bakhtiar Litkouhi and - Jim Nickolaou and - Varsha Sadekar and - Wende Zhang and - Joshua Struble and - Michael Taylor and - Michael Darms and - Dave Ferguson}, - title = {Autonomous driving in urban environments: Boss and the Urban Challenge}, - journal = {J. Field Robotics}, - volume = {25}, - number = {8}, - pages = {425--466}, - year = {2008}, - url = {https://doi.org/10.1002/rob.20255}, - doi = {10.1002/rob.20255}, - timestamp = {Mon, 23 Oct 2017 17:50:06 +0200}, - biburl = {http://dblp.org/rec/bib/journals/jfr/UrmsonABBBCDDGGGHHHKKLMMPPRRSSSSSWWZBBDLNSZSTDF08}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@article{DBLP:journals/corr/0001R14a, - author = {Christian Berger and - Bernhard Rumpe}, - title = {Engineering Autonomous Driving Software}, - journal = {CoRR}, - volume = {abs/1409.6579}, - year = {2014}, - url = {http://arxiv.org/abs/1409.6579}, - archivePrefix = {arXiv}, - eprint = {1409.6579}, - timestamp = {Wed, 07 Jun 2017 14:40:19 +0200}, - biburl = {http://dblp.org/rec/bib/journals/corr/0001R14a}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} - -% ========== MMO & Game architectures ========== -@inproceedings{DBLP:conf/gi/MullerG04, - author = {Jens M{\"{u}}ller and - Sergei Gorlatch}, - title = {A Scalable Architecture for Multiplayer Computer Games}, - booktitle = {{INFORMATIK} 2004 - Informatik verbindet, Band 1, Beitr{\"{a}}ge - der 34. Jahrestagung der Gesellschaft f{\"{u}}r Informatik e.V. - (GI), Ulm, 20.-24. September 2004}, - pages = {154--158}, - year = {2004}, - url = {http://subs.emis.de/LNI/Proceedings/Proceedings50/article3126.html}, - timestamp = {Tue, 31 May 2011 16:04:26 +0200}, - biburl = {http://dblp.org/rec/bib/conf/gi/MullerG04}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@inproceedings{DAfMMO-RPG, - author = {Marios Assiotis and Velin Tzanov}, - title = {A Distributed Architecture for Massive Multiplayer Online Role-Playing Games}, - year = {2005}, - month = {May}, - url = {https://pdos.csail.mit.edu/archive/6.824-2005/reports/assiotis.pdf} -} -@inproceedings{DBLP:conf/netgames/FiedlerWW02, - author = {Stefan A. Fiedler and - Michael Wallner and - Michael Weber}, - title = {A communication architecture for massive multiplayer games}, - booktitle = {Proceedings of the 1st Workshop on Network and System Support for - Games, {NETGAMES} 2002, Braunschweig, Germany, April 16-17, 2002, - 2003}, - pages = {14--22}, - year = {2002}, - url = {http://doi.acm.org/10.1145/566500.566503}, - doi = {10.1145/566500.566503}, - timestamp = {Sat, 15 Dec 2012 19:10:50 +0100}, - biburl = {http://dblp.org/rec/bib/conf/netgames/FiedlerWW02}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@incollection{DBLP:reference/cg/Fortune04, - author = {Steven Fortune}, - title = {Voronoi Diagrams and Delaunay Triangulations}, - booktitle = {Handbook of Discrete and Computational Geometry, Second Edition.}, - pages = {513--528}, - year = {2004}, - url = {https://doi.org/10.1201/9781420035315.ch23}, - doi = {10.1201/9781420035315.ch23}, - timestamp = {Wed, 12 Jul 2017 09:11:49 +0200}, - biburl = {http://dblp.org/rec/bib/reference/cg/Fortune04}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@book{puntambekar2009data, - title={Data Structures And Algorithms}, - author={Puntambekar, A.A.}, - isbn={9788184316599}, - url={https://books.google.bg/books?id=0OZ8dwfwsAQC}, - year={2009}, - publisher={Technical Publications} -} -@Book{fowler2003patterns, - author = {Fowler, Martin}, - title = {Patterns of enterprise application architecture}, - publisher = {Addison-Wesley}, - year = {2003}, - address = {Boston}, - isbn = {978-0321127426} -} -@Book{gamma1995design, - author = {Gamma, Erich}, - title = {Design patterns : elements of reusable object-oriented software}, - publisher = {Addison-Wesley}, - year = {1995}, - address = {Reading, Mass}, - isbn = {978-0201633610} -} -@techreport{fette2011websocket, - added-at = {2016-04-12T13:27:50.000+0200}, - author = {Fette, I. and Melnikov, A.}, - biburl = {https://www.bibsonomy.org/bibtex/20ca2a43d416f2e0b90052720400f92ac/ripe}, - howpublished = {Internet Requests for Comments}, - institution = {RFC Editor}, - interhash = {a9ed69aa19a7951d4aa83ad9191088be}, - intrahash = {0ca2a43d416f2e0b90052720400f92ac}, - issn = {2070-1721}, - keywords = {socket.io websockets}, - month = {December}, - note = {\url{http://www.rfc-editor.org/rfc/rfc6455.txt}}, - number = 6455, - publisher = {RFC Editor}, - timestamp = {2016-04-12T13:27:50.000+0200}, - title = {The WebSocket Protocol}, - type = {RFC}, - url = {http://www.rfc-editor.org/rfc/rfc6455.txt}, - year = 2011 -} -@manual{STOMP, - title = {Simple (or Streaming) Text Orientated Messaging Protocol}, - url = {http://stomp.github.io/}, - organization = {stomp} -} -@manual{SFS, - title = {SmartFox Server 2X}, - url = {http://docs2x.smartfoxserver.com/}, - organization = {gotoAndPlay()} -} -@manual{Jetty, - title = {Jetty Web-server}, - url = {https://www.eclipse.org/jetty/documentation/}, - organization = {Eclipse} -} -@manual{PGSQL, - title = {PostgreSQL}, - url = {https://www.postgresql.org/}, - organization = {PostgreSQL} -} -@INPROCEEDINGS{Cronin01adistributed, - author = {Eric Cronin and Burton Filstrup and Anthony Kurc}, - title = {A Distributed Multiplayer Game Server System}, - booktitle = {University of Michigan}, - year = {2001}, - pages = {01} -} -@inproceedings{DBLP:conf/vrst/NgSLL02, - author = {Beatrice Ng and - Antonio Si and - Rynson W. H. Lau and - Frederick W. B. Li}, - title = {A multi-server architecture for distributed virtual walkthrough}, - booktitle = {Proceedings of the {ACM} Symposium on Virtual Reality Software and - Technology, {VRST} 2002, Hong Kong, China, November 11-13, 2002}, - pages = {163--170}, - year = {2002}, - url = {http://doi.acm.org/10.1145/585740.585768}, - doi = {10.1145/585740.585768}, - timestamp = {Thu, 02 Mar 2006 10:39:40 +0100}, - biburl = {http://dblp.org/rec/bib/conf/vrst/NgSLL02}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@book{DBLP:books/daglib/0002204, - author = {George Reese}, - title = {Database programming with {JDBC} and Java {(2.} ed.)}, - publisher = {O'Reilly}, - year = {2000}, - isbn = {978-1-56592-616-5}, - timestamp = {Tue, 12 Apr 2011 15:08:24 +0200}, - biburl = {http://dblp.org/rec/bib/books/daglib/0002204}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@proceedings{DBLP:conf/infocom/2004, - title = {Proceedings {IEEE} {INFOCOM} 2004, The 23rd Annual Joint Conference - of the {IEEE} Computer and Communications Societies, Hong Kong, China, - March 7-11, 2004}, - publisher = {{IEEE}}, - year = {2004}, - url = {http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=9369}, - isbn = {0-7803-8355-9}, - timestamp = {Mon, 26 Jan 2015 16:54:49 +0100}, - biburl = {http://dblp.org/rec/bib/conf/infocom/2004}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@inproceedings{DBLP:conf/icmcs/GautierD98, - author = {Laurent Gautier and - Christophe Diot}, - title = {Design and Evaluation of MiMaze, a Multi-Player Game on the Internet}, - booktitle = {{IEEE} International Conference on Multimedia Computing and Systems, - {ICMCS} 1998, Austin, Texas, USA, June 28 - July 1, 1998}, - pages = {233--236}, - year = {1998}, - url = {https://doi.org/10.1109/MMCS.1998.693647}, - doi = {10.1109/MMCS.1998.693647}, - timestamp = {Thu, 25 May 2017 00:43:21 +0200}, - biburl = {http://dblp.org/rec/bib/conf/icmcs/GautierD98}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@inproceedings{DBLP:conf/netgames/FritschRS05, - author = {Tobias Fritsch and - Hartmut Ritter and - Jochen H. Schiller}, - title = {The effect of latency and network limitations on MMORPGs: a field - study of everquest2}, - booktitle = {Proceedings of the 4th Workshop on Network and System Support for - Games, {NETGAMES} 2005, Hawthorne, New York, USA, October 10-11, 2005}, - pages = {1--9}, - year = {2005}, - url = {http://doi.acm.org/10.1145/1103599.1103623}, - doi = {10.1145/1103599.1103623}, - timestamp = {Wed, 15 Feb 2006 10:03:39 +0100}, - biburl = {http://dblp.org/rec/bib/conf/netgames/FritschRS05}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@inproceedings{DBLP:conf/netgames/KimCCKCY05, - author = {Jaecheol Kim and - Jaeyoung Choi and - Dukhyun Chang and - Taekyoung Kwon and - Yanghee Choi and - Eungsu Yuk}, - title = {Traffic characteristics of a massively multi-player online role playing - game}, - booktitle = {Proceedings of the 4th Workshop on Network and System Support for - Games, {NETGAMES} 2005, Hawthorne, New York, USA, October 10-11, 2005}, - pages = {1--8}, - year = {2005}, - url = {http://doi.acm.org/10.1145/1103599.1103619}, - doi = {10.1145/1103599.1103619}, - timestamp = {Wed, 01 Feb 2017 14:59:06 +0100}, - biburl = {http://dblp.org/rec/bib/conf/netgames/KimCCKCY05}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@article{DBLP:journals/cn/LeeKC05, - author = {Kang{-}Won Lee and - Bong{-}Jun Ko and - Seraphin B. Calo}, - title = {Adaptive server selection for large scale interactive online games}, - journal = {Computer Networks}, - volume = {49}, - number = {1}, - pages = {84--102}, - year = {2005}, - url = {https://doi.org/10.1016/j.comnet.2005.04.006}, - doi = {10.1016/j.comnet.2005.04.006}, - timestamp = {Thu, 18 May 2017 09:51:00 +0200}, - biburl = {http://dblp.org/rec/bib/journals/cn/LeeKC05}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@article{Caltagirone:2002:AMM:771322.771339, - author = {Caltagirone, Sergio and Keys, Matthew and Schlief, Bryan and Willshire, Mary Jane}, - title = {Architecture for a Massively Multiplayer Online Role Playing Game Engine}, - journal = {J. Comput. Sci. Coll.}, - issue_date = {December 2002}, - volume = {18}, - number = {2}, - month = dec, - year = {2002}, - issn = {1937-4771}, - pages = {105--116}, - numpages = {12}, - url = {http://dl.acm.org/citation.cfm?id=771322.771339}, - acmid = {771339}, - publisher = {Consortium for Computing Sciences in Colleges}, - address = {USA}, -} -@book{DBLP:books/lib/TanenbaumW11, - author = {Andrew S. Tanenbaum and - David Wetherall}, - title = {Computer networks, 5th Edition}, - publisher = {Pearson}, - year = {2011}, - url = {http://www.worldcat.org/oclc/698581231}, - isbn = {0132553171}, - timestamp = {Wed, 26 Apr 2017 17:48:08 +0200}, - biburl = {http://dblp.org/rec/bib/books/lib/TanenbaumW11}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@book{TaylorEtAl2007, - added-at = {2007-09-25T21:44:52.000+0200}, - author = {Taylor, Richard N. and Medvidovic, Nenad and Dashofy, Eric M.}, - biburl = {https://www.bibsonomy.org/bibtex/2b3629dfb38560c560224a4191e568494/tommens}, - description = {software evolution bibliography}, - interhash = {64dcb03a1c9a2f9a26b0760f022f02ea}, - intrahash = {b3629dfb38560c560224a4191e568494}, - keywords = {architecture software}, - publisher = {Addison-Wesley}, - timestamp = {2007-09-25T21:45:11.000+0200}, - title = {Software Architecture: Foundations, Theory and Practice}, - year = 2007 -} -@book{Cozzi15, - author = {Patrick Cozzi}, - title = {{W}eb{GL} {I}nsights}, - month = {July}, - year = {2015}, - isbn = {978-1498716079}, - publisher = {CRC Press}, - note = {\url{http://www.webglinsights.com/}} -} -@book{dirksen2014three, - title={Three.js Essentials}, - author={Dirksen, J.}, - isbn={9781783980871}, - series={Community experience distilled}, - url={https://books.google.bg/books?id=3mT4AwAAQBAJ}, - year={2014}, - publisher={Packt Publishing} -} -@book{DBLP:books/daglib/0067388, - author = {Edsger W. Dijkstra}, - title = {Selected Writings on Computing: {A} Personal Perspective}, - series = {Texts and Monographs in Computer Science}, - publisher = {Springer}, - year = {1982}, - url = {https://doi.org/10.1007/978-1-4612-5695-3}, - doi = {10.1007/978-1-4612-5695-3}, - isbn = {978-3-540-90652-0}, - timestamp = {Tue, 16 May 2017 14:01:33 +0200}, - biburl = {http://dblp.org/rec/bib/books/daglib/0067388}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@book{DBLP:books/daglib/0021734, - author = {George T. Heineman and - Gary Pollice and - Stanley M. Selkow}, - title = {Algorithms in a nutshell - a desktop quick reference}, - publisher = {O'Reilly}, - year = {2009}, - url = {http://www.oreilly.de/catalog/9780596516246/index.html}, - isbn = {978-0-596-51624-6}, - timestamp = {Tue, 08 Feb 2011 13:07:59 +0100}, - biburl = {http://dblp.org/rec/bib/books/daglib/0021734}, - bibsource = {dblp computer science bibliography, http://dblp.org} -} -@Book{walls2015spring, - author = {Walls, Craig}, - title = {Spring in action}, - publisher = {Manning Publications}, - year = {2015}, - address = {Shelter Island, N.Y}, - isbn = {978-1617291203} -} - -@inproceedings{BKRW17a, - key = {BKRW17a}, - author = {Butting, Arvid and Kautz, Oliver and Rumpe, Bernhard and Wortmann, Andreas}, - title = {{Architectural Programming with MontiArcAutomaton}}, - booktitle = {In 12th International Conference on Software Engineering Advances (ICSEA 2017)}, - year = {2017}, - month = {May}, - location = {Athens, Greece}, - publisher = {IARIA XPS Press}, - pages = {213--218}, - keywords = {} -} \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/AoICircle.png b/docs/Thesis/src/pic/DiagramXMLs/AoICircle.png deleted file mode 100644 index 94d446caebef106a1d27eba658fc2b2ab9cb5021..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/DiagramXMLs/AoICircle.png and /dev/null differ diff --git a/docs/Thesis/src/pic/DiagramXMLs/AoICircle.svg b/docs/Thesis/src/pic/DiagramXMLs/AoICircle.svg deleted file mode 100644 index ab4f41835fc6a5c7bdf8ba222977116e1212653f..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/AoICircle.svg +++ /dev/null @@ -1,2 +0,0 @@ - - \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/AoICircle.xml b/docs/Thesis/src/pic/DiagramXMLs/AoICircle.xml deleted file mode 100644 index e1071f0eb3053274b38bafa59bb8b2ccfe600dd0..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/AoICircle.xml +++ /dev/null @@ -1 +0,0 @@ -7VdNj9owEP01OXaVDwLhWGDpHlqpEoe2R28yJO46dmQMhP76jpNxSBZYdbW02kpwwX4ztsfvPdvgRfOy/qRZVXxRGQgv9LPaixZeGAZ+GOOXRQ4tEk0IyDXPKOkIrPgvcCMJ3fIMNoNEo5QwvBqCqZISUjPAmNZqP0xbKzFctWI5nACrlIlT9BvPTEG7cOVZ/AF4XtDKo3jaBh5Z+pRrtZW0nBdG6+bThkvmpqKJNgXL1L4HRfdeNNdKmbZV1nMQllrHWjtueSHala1Bmj8ZMJq0I3ZMbMGV3BRmDo4LHIG0Y2e2L7iBVcVSG9mj8ogVphTYC7DJNlWrxZrXgAvMut352BHsEcSs42euhNIYkkraqTdGqydwINLmN58u4lSw66y5EL1MIhhxJc2SlVxY0z2A2IHhKaPAuamZ4LlELEW2AIMzIgO0gfoio0GnE9ofVAlGHzCFBnxISFpy/oS6+6ONghFhRc9CHcjIunk39VE/bJCEF+RMbnL25Mw1yzgck6k4By+4xg1yJZuQtgW9yQGkeBD/U8mn/7/kXeb7OMFBPDjBQRSf6nlOziuoGSen4mX4MlGXqG7ot/o0svT0g5qb7wTb9g/bvottT2IlTejODycOaONRlDjgK2iORVsqF610TJuP9kHtC43Ykts9tAvJ7FkGIr34TzDmQE882xqFkD1sKleSic9KVVT8qwz0WqO0tFouX3YFUq+2OqUsd5Jxxzm4tz457x4Nghm+G87/Ji9Mr+KF4CUvTJNnVhiPb1Z4h1bwb5f8dS/58fCOD4O/dsdj9/h7von1/jNF978B \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/AoIHex.svg b/docs/Thesis/src/pic/DiagramXMLs/AoIHex.svg deleted file mode 100644 index 9a17a0c17913ffd51ff4a0a61cdf3f7bad6c82de..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/AoIHex.svg +++ /dev/null @@ -1,2 +0,0 @@ - - \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/AoIHex.xml b/docs/Thesis/src/pic/DiagramXMLs/AoIHex.xml deleted file mode 100644 index 3fa33765ccb9b6591b362d14d033f8b86aec78c4..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/AoIHex.xml +++ /dev/null @@ -1 +0,0 @@ -7ZpNb6MwEIZ/DdfKxkkD19B2e1lppRz27MIErBqMXKch++vXBpuEspH2UoMQVKrM6+95PLYzIiBJ2fyQtC5+igx4EKKsCchTEIY7vNX/jXDpBLKzQi5Z1kn4KhzYH7AisuqJZfAxKKiE4IrVQzEVVQWpGmhUSnEeFjsKPuy1pjmMhENK+Vj9zTJV2Fm44Rn9FVhe2J4327jLeKPpey7FqbLdBSE5tk+XXVLXlG3oo6CZON9I5DkgiRRCdamySYAbyzqrdfVe7uT2w5ZQqf+pEFksn5SfwA25HZi6OFvoMdYmWUBDc1EFZF+DZCUokFf1l5P0FPbngik41DQ11c56gWitUCXXb1gn+0kj/cLpG/B9b7ZEcGGarUQFpqiS4h2cqK2J2qfPcXBMs0fG+U1Ja3eti0q90JJxsxZfgX+CYim1Gf9qmnKW62k+pdqIZo57ayOQCpq7hsY9Pu0UILQx5EUXsRUeLXDrD9itpPN1dWFkteJmZUVWo3ZB533LV6o6YcHegfy4QvYCGZPtgPLOJ+TdCnkST459Qo5WyJN4Mt76pByvlL1QDlH88IWzz3PZ7Rwr5+/mHG0epjuZY7xYzEn7zAbz2J19Hs5xuFjOc3dnr8dzTFbOU9y0/W7am8VCntem/fWmrbvzSHkNf03iysTrfr3c8Ne8XZl4/TG13PhXhMzfXCiPb9l+D+blhsDm5c3jW7bfo3m5QbCZcR75s9fTuW94Be3dob0e0BgtNw42r8s2cV8jTBHUxmgNg02E2WewE6M1CjYNZq+3bYyWGwebN+bvvITp1+snZm3ezVd85Pkv \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/ClientServer.svg b/docs/Thesis/src/pic/DiagramXMLs/ClientServer.svg deleted file mode 100644 index d664284889bde326ca615f4d00cde7c064950066..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/ClientServer.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Central server
[Not supported by viewer]
DB
DB \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/ClientServer.xml b/docs/Thesis/src/pic/DiagramXMLs/ClientServer.xml deleted file mode 100644 index db33142ee008fd663029aada01ba63207900168e..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/ClientServer.xml +++ /dev/null @@ -1 +0,0 @@ -7Vpdk6I4FP01Po4FBPx4bO3pnYfZqqntrdrdxwgRshOJG2Kr++v3Bm5ADHZ1z9C6VuGL4eTmg3tOTiI4IsvN4RdFt9mvMmFiFHjJYUQeR0Hge0EEXwY5VgiZIpAqnmBQAzzzf5ltieiOJ6xoBWophebbNhjLPGexbmFUKblvh62laI+6pSlzgOeYChf9gyc6w7uw0zP4F8bTDEcOo3lVsaLx91TJXY7DjQKyLj9V9YbarrCjIqOJ3J9A5POILJWUuiptDksmTGpt1qp2Txdq62krluu3NCDYotBHe+ssgUzgZS5z+FqUN8RMEw+uMr0RUPShyA5c/3lS/suEjIF8sig0VfrBUAFYLGhR8NjCT1zUPeSJGwTgScjfTOsjSoTutARIKp3JVOZUfJVyi3GFVvI7W0ohVXknxCs/dY0l0sSuZa6f6IYLo88vTLwwzWOKFV1dVGkyubmYaZtKuVMxRpGaUlgpTG6YVkcIUUxQzV/aXVGUbFrH1U2/SQ6DBJ5dXgTVg4vLj7x2F5DjlGls1bAPhZNpNFCpiQv6qDp+oWKHs10KzrDbU9W8MGUyKB4ET3OAtKFlQfFKsLU2PGxpzPP095KyWQN8Lasfgwb5DdeWX2IZ3Zph4t3KqLGopOAbWhKuYPlzaQaBxBt+SwqtgMO2XuvlZtoKumJiUS9Yyzpq/l1qArGeROKK/2GVmVyyw+s6c0WFYghRC/vGtnwPsezEsqbeZdm1BPOaOoIPcI/p4B4YFX6Me8yu5h7h4B734h7YoD6A3cBN7Fg/6SaeexaBm1fHsm7sh8QCVcDcDy3wjSkOs2YKexlMCC7x3F6ZAopk/pPG9FZFRIN/3It/oF8Es2saRj/Hj7ZhTM8MY9I4iAnwxx6ZDYbximFMOgxjdiXDmAyGcS+GceHAcVUDIVE/BjKOTi2k5R/tw0ZtJYNzdDjH9IZHjengHHfmHJ9qW6h/yM7H0RXNg3yAefiDF1TQ7IZeMBu84M68gJydIvzJFU8RwdzRi6OUdvoMv/uMa/YMxJuIvaJbh7SS/s0hNW/YxisKC3zMC4l6gNJDnpbd+9H7SO6NOCv0GFgyJ5lX5NMDx35wxjHpsvtpB8m+3wfLriu4LCNpCdW00FKxN/H8v16cDsd9MDk5O/N7ocNj2MFj2MczA/eN1iiYCI0pgJo1xT1o8s/OvIZdNGmqISil5ntpDvPU9F8wBTmxXa2UjbAIzKvq38Jn0oFs6rYyFAPPp6sywDCxNQ/kyzuPFqPo0XADW7rdF9x9p3tzau1Gn8Ib+bV//qsvclfyvEMBQR8KcB8SPL6Fj/by6/BShJwVc07EhieJuGQN7fPie1z9FjROz2gM3G036IdGuGz+FVG9imr+eUI+/wc= \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/Cloning.svg b/docs/Thesis/src/pic/DiagramXMLs/Cloning.svg deleted file mode 100644 index 1420075575e1f990c4437fd781a1a662ff7b14c8..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/Cloning.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
Client
Client
Client
Client
Client
Client
Server 1
Server 1
DB
DB
Client
Client
Client
Client
Client
Client
Server 2
Server 2
DB
DB
Client
Client
Client
Client
Server 3
Server 3
DB
DB
Synchronization
Synchronization \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/Cloning.xml b/docs/Thesis/src/pic/DiagramXMLs/Cloning.xml deleted file mode 100644 index b2410dd2a9f691394bf0bfe33384cc86fc08bddd..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/Cloning.xml +++ /dev/null @@ -1 +0,0 @@ -7Vxdc6M2FP01fiyDAPHxuEk23YftzE7TmbaPCiiGLkYeWU7s/vpKID4kwcb2AokbeNiFixBC59yrqyM5K/d2c/iVom36G0lwvnLs5LBy71aOE4YO/1cYjpUBRmFlWNMsqUygNTxk/2JptKV1nyV4pxRkhOQs26rGmBQFjpliQ5SSF7XYE8nVt27RGhuGhxjlpvXPLGFpZXXr5gn7F5ytU/lmD0bVjUcUf19Tsi/k61aO+1Qe1e0NqquSFe1SlJCXjsn9vHJvKSGsOtscbnEuerbuteq5+4G7TbMpLtgpD3iBbAc71p+OE94T8rIgBf/vpvwgLB6x+VXKNjk/BfwUHzL2V+f8b1HEciC/3DFE2ScBBbfFOdrtsrg232d5U0ORmIW4sVPkH8zYUVIE7RnhJkJZStakQPlXQray3I5R8h3fkpzQ8ktcuzyaOzWQouwTKdg92mS54OcXnD9jlsVI3uirouom0TdKT+/InsbS5IVm74MGU+4pmGwwo0dehOIcsexZrQtJzq6bcs2j30jGa3Rs6V4wkPSR3gU8W62Cd/IaM/lUCz8/6TSjNZWkGCCI/KhnlO9lc2/zDMt6u7x5xlT0Yf4pz9YFNzEBzA2SVzl+YgKJLYqzYv1HCVrYGr6Wt++c1vK79C5Q2lK0Fa+J94+Cj7uKDEAAk2SUB4CMiJdwNATCJYg1hT2VsY3DiWdz9Ijzm8Zla9wl68/iE6drp6T0+Yt5JvoSHwZ9eoBV8gHPU9nhysuXNpABW9rSThAL7GEeKgz6AV2gvdDlyunS8GAWvjgLX66ML66nDz6RBWdkjGswxuCK2oEC4Zc0Y/iBQy9KvPCU1YCtJMDmsBbprPWIeCJiZTsiGcHPPhXrsnoAz4N5NOhqqsccJ0x/SKARUIa+hrLTh3LQAzIAI6DsRaPkpbaZl/Lvp8fyngU8tzZUBSLg1YZvmGa81aKj7+wPmc7WQ3mVS6rON2aKe7Ljg3EoYcEuKRRGqGyACxcaLjjvjAveCYOAjOkJYmjHCMUnDQPvevQ2hoARAr1va4E+8oww7/WEeX3KeRGM0IDxAVP+Odxmejv/RqbiRTFP1dBjWUD0z1ZMeMv2wJsVvBM9xp2qTufMdLE/p1SSyF+8N0qzoA/VtByaabnfg4szBi6+gcvdzQl4qE7RkwBJk8FjHYhNliT5kMOqIf6cVOwNYPSBNrsCJozOVDBOIe4FH1Pcg7OJe2EI1IA8nbgHF3Hv2mbfEVDZMau4N8WkLNAmZX47SxMFgGW74ZKI12GoHvHnCEPQ8jtHoA5jLrTc7hFMFaP8RVG+9hg1q6LsTyETgI8ZbJzZgk3E43zncNQMKPQs6AYBgBAEjge8yWLNshpxbbEG2FqwAT3z5OmCjalDNQKGqUh9LAEjdHx1FOhdJ5pKwghNCcPAY1kmGgFkTT107TmXicLgBJQXHfgkJPUFv8jEcSodODR1iEVvvBDGQNcbgQHjVHpjdELMFR21HfxOuZ1TjoirplVnyOaBJptHfaNOs5FT6QLQxK6fygnMmLQkkW+dRFbUNFnTaqxz7mHxo4UiV0ORQxMd1PFxXsoEYMlnR8lnX4EZOOb0cbL01fcNDJddTjNrXHK07u5sCc6gzehbWwJTgzIdfZnSnObM2pzG93pC9lSTGj+cwLmX1bKznDvqce4eUXs+5zY3Lzd6oWvQ5f+mF7469KpTNwDgjIJhYEq5iwZxKZKaCBH2pcqTqRCmmGQG4r4YNxAfO1gnaJeWIEwe3Jq9V5YNQmUEgLYrr/X4PrSP2YsG872BGGrILdpeKNcMq+EAIzqAwx7Aa9tPrh/6kaZ66VVUzTfWCI2KAv3HLYFW0XiLjZEpAlwvT83l8gup5b0pjTxgOSr+EbyQSJpc4OrzxfGI1GgO182kNqkVP/VQZ6ztFPbyCPZ+olUAX+HGqSQL9c3FEdQV7DFpZkpQD8ciTikpeFJaqoVLunTJFvFQH7zMX2D06ooXZEv8sv3jEhUJ2r/f4X7+Dw== \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/DistributedZoning.svg b/docs/Thesis/src/pic/DiagramXMLs/DistributedZoning.svg deleted file mode 100644 index 6b8dadbe2512f011911a9dd9ee8adf333770016a..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/DistributedZoning.svg +++ /dev/null @@ -1,2 +0,0 @@ - - \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/DistributedZoning.xml b/docs/Thesis/src/pic/DiagramXMLs/DistributedZoning.xml deleted file mode 100644 index fe538cc17b14207e75ea332a0d725253244011bd..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/DistributedZoning.xml +++ /dev/null @@ -1 +0,0 @@ -7ZpLd6IwGIZ/Dct6SAIi2zq9bGblYtYRIuQ0EE6M1c6vnyABRGTEVi6eAwtL3tzgez5eSaqBltHhTeAk/M19wgxo+gcD/TIgBMCF6k+qfGnFtJ1MCQT1tVYKK/qX5A21uqM+2VYaSs6ZpElV9HgcE09WNCwE31ebbTirzprggNSElYdZXf1DfRlmKsovL9XfCQ1CPbNlu1nFGnsfgeC7WE9nQLQ5Hll1hPOh9EDbEPt8fyKhFwMtBecyO4sOS8LS2OZRy/q9NtQWly1ILNt0QFmHT8x2JL/i43XJrzwU+5BKskqwl5b3ireBnkMZMVUC6hRvkwzAhh6IGvW5uCVTFRheE/ZcBGXJGReqKuYxSZtKwT9ILqpYmcejqMlDn86zoYyddd/wWL7iiLI0y94J+ySSelhXXBoVMxrESvNUdIjQDVf6Vs167HQ4P4mQ5HAi6Vi+ER4RKb5UE10714PkaY90eV/mEDS1Fp7kTyFinbdBMXQJT51ofpdZWhPLe7IcFiaYaN6VpnVG88nplebks50+mz3ThBPNDr81+4UJJ5jdGi3sFyeYcHbqtD3jNCecXVptvzTtCWaXVtvvCmU+v04z5ZA03FaxeYPXefOmoDRGAJj2WT4jZzYHrmk5+rMWENuuxyPXfhSOFsmtetBkmybTCNO83Kq6kut6t06tUG/IfR9vw/ROjtM2ZsQp+Sy/6uj7YNli8T0Ay4r4H4wFhUBgn5KSUBsn+xbdHwHN3zTgrPowl8IJcnDBzsA93MwZ3s0scB6CJwgH87PFKJ+BB/YzZzg/c0fJ8tH9rAHoKPzMabFw6tzPrDM3UxY2A4O4mdNiW2BysxvczDEvo++DZYsdu8nNbnWzJqDjcLMW/z/p2s2KLrmbVb3MdoG76M/PxrlCeWA/Q8P52Th3Dh7dzxqAjsLPFmN4OzvzMwDsmWtZ0DURcizXAj26WS9biYsBX1la7C5Mdn2LXQ+3Oei0WEyLkEfr3fY6ywq6Shi6sGr3eIzPqm/fGEQL07Vh9mmZdae6k3GrYvlbzGPdyQ9e0cs/ \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/MVC.svg b/docs/Thesis/src/pic/DiagramXMLs/MVC.svg deleted file mode 100644 index 9ca92a9145277e1bb1ea4f1e9e4089bebb4d45f9..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/MVC.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
fill
fill
notify
notify
Model
[Not supported by viewer]
update
update
Controller
[Not supported by viewer]
write
write
View
[Not supported by viewer] \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/MVC.xml b/docs/Thesis/src/pic/DiagramXMLs/MVC.xml deleted file mode 100644 index 222cb40b88687d339e8c7c358b989cd15ec0c3f1..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/MVC.xml +++ /dev/null @@ -1 +0,0 @@ -7VlLU9swEP41OcLEtkzIEQKUQzvTGWZaehS2YqsolisrL359JWtlW7EdoCSBMvEBrNVqZe337cPOIJjMVl8EztNvPCZs4A/j1SC4Gvj+yAvVXy1YG0EQjo0gETQ2Iq8W3NEnAsIhSOc0JoWjKDlnkuauMOJZRiLpyLAQfOmqTTlzd81xQlqCuwiztvQnjWUKp7CPp+W3hCYp7Izs8R5w9JgIPs9gu4EfTMvLTM+wNQWGihTHfNkQBdeDYCI4l+ZutpoQpj1rvWbW3fTMVo8tSCZfssAPA7Nkgdkczj6lWqV8Orm2DiGx8g8MuZApT3iG2XUtvYzmYkG0WU8NSheUo6EapXLGYIKsqLzX4tNRCMNfdiqTYn0PS8rBr1LR14qFxEJeaGSVLOMZsbIb/bR2TWw1IoaLgkZGCCp6j99EyjXQDc8lV6L6NF85z0GvkII/kglnXJTnD4blVc1YUmjdKc/kDZ5Rprl+S9iCSBphmIC9PB/GXSaNs7WHe1EEUcHnIgItPziHwMAiIaDno1HFIhWbhM+I8qNSgsA8GZ566jILBWFY0oW7K4bISaq1lbnvnKrnqVX4dFqojRv8UjeNXWtRyboeBtpjNBjYYt8ypZLc5bg8+1JlHJdUuMhNEpjSlSbdZRVW2r0MPxB2WQWmRaAi0SuQVkTaWJ4IHFNS4wriN3MCM5pkmsjKNhEVSRZESLLaTpNe8ANIOmuba2G8rDPcOYjSRnKzsi5mOMBvQzkctkA9ZErx3JQy+uwpJcZFWnnuX/PLuCu/oG6KvTiXvJwxfisvZFzS6bpFJBUR0qWEIAV9wg+lgnZHrjNX+TDh5SC86oovHVnKx+wCJmY0jksS9qSPurJ3o9ILX38F6Ahu6G/gKHXf0MQOYmtbzh+Ox8iJ/ZPzt5UAa9p3rY5cAzsqEONjgThMgfDG71ghkPc8zAq2XN/GWOJCcqE9+Qz0B0B6MxV8OFzRBqxhG1bUASvaCazoeVjr0u59CED/x9D1XIyrZu+50N1FqUZhB8ZnTIIPHLDP/sy5nTgpSm9dKAXvLF/Vk+ou0f/hu4IxpR7DWDNzfW2AC7rFrI1ug1IN4Hxkx2DY29YbtJB8BTnfr6HfSVyHaP8NfaObP34G6GvT0VlXmx4erE1vx/48V/WZHNv0zTa959UJTCmGB6PQDeidNOkeOnXNnmyY2E2bbnn4liIQdhWBiVISnDGF/+esBDkRVHmaCN300CyBRUU18vfU3nsHrBfofO/1wt436kX9Tfm0GtqPQ8da0q4lo45aYt6/D1FLUPtNfynosZS0SokJpi2lxBuOPSfW9/O9Z7yXQjLa09vED0qWxxKy29dMtLcSoob176CGR/VPzcH1Xw== \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/MapSplitting.svg b/docs/Thesis/src/pic/DiagramXMLs/MapSplitting.svg deleted file mode 100644 index 17eb38edd0de76ad15d28dd9934e98296c93ffef..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/MapSplitting.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
5 - 8
5 - 8
3 - 6
3 - 6
5 - 6
5 - 6
2 - 5
2 - 5
4 - 5
4 - 5
2 -3
2 -3
6 - 9
6 - 9
8 - 9
8 - 9
1 - 4
1 - 4
1 - 2
1 - 2
7 - 8
7 - 8
4 - 7
4 - 7
1
[Not supported by viewer]
2
[Not supported by viewer]
6
[Not supported by viewer]
5
[Not supported by viewer]
4
[Not supported by viewer]
9
[Not supported by viewer]
8
[Not supported by viewer]
7
[Not supported by viewer]
3
[Not supported by viewer] \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/MapSplitting.xml b/docs/Thesis/src/pic/DiagramXMLs/MapSplitting.xml deleted file mode 100644 index 386a03f5ce61a192e82db96bef8334ba3e1cc6cd..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/MapSplitting.xml +++ /dev/null @@ -1 +0,0 @@ -7VpNk6IwEP01HK0iiYAeV3c+LnvysOcMRKAmEBaj4v76DdCgbJgaDwRnqkKVJbzuBNLvdb7AIduseilpkfwSEeMOdqPKIT8djBFaY/VXIxdAXC9okbhMI8CuwC79yzpHQI9pxA4DRykEl2kxBEOR5yyUA4yWpTgP3faCD+9a0JhpwC6kXEd/p5FMWpR0j1fjryyNE7jz0lu3hjcavselOOZwOweTfXO05ox2VUFFh4RG4nwDkSeHbEshZHuWVVvG69h2UWvLPX9g7R+7ZLm8q4DfljhRfoSme+pyoX4reEJ56YLStIvVJV2HbM5JKtmuoGFtPSsdKCyRGVdXSJ32Lat9OX1jfNPHZiu4KJUpFzmrXWUp3lkHqpC5zdFbOgbqavcp5zeeEFyFi1w+0yzlteJeGT8xmYYUDGNVU57GucJCFSmmjJuIHpKmcQhK7aDlrh5UiPOJlZJVNxAE+YWJjMnyolzAin2oBRJigQgA56u8eqfkRlodRkHRcV/3lVZ1AsyOs7zSSCZAsm9Jno7k5X8kByMUu4YoRusPE9lybJDj0UQey+NJWA40kjGQ7FmSzfXWY4lsqq9Geme9tBw/aEQ2lsgIaSw3mUwsxbOOx+YI1rtqH9J4/eU5huLfjN7xObWpCdfIWLyyBJsl+O4MdicgWF8ZI+B3+eX5/Uad9AOnWvqSqWMYW4ZnnU0bG4ZHsjiw+1szzKZn7aqRp7HcrZkCy7KxvnreTUyicexgn0to5oBj/89RdIbFoXm58EM5EFxUV6M6i+t/1FWjHqCtqcU14XwiFXoo2jcR+7SqGfhW8zjDSrl7Zj5Jd7A0pBRslWJ+5JhXKsiUVnyrlRkWhPe+YZlGK6ZGIM9qZYYZ6bxawYa0srRaMT+vnVUq2JRU1lYqD9qTNCgW/b3RNGJZWbE8aFfEoFhcQ2IJrFjMD0LzakXfQZtGKsRKxfwgZHTNrC6v36M2tpuPfsnTPw== \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/Multicast.svg b/docs/Thesis/src/pic/DiagramXMLs/Multicast.svg deleted file mode 100644 index 6ca1c0be00bc017f34e0859ab35bfe8edec1d368..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/Multicast.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
P
P
P
P
P
P
P
P
P
P
P
P \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/Multicast.xml b/docs/Thesis/src/pic/DiagramXMLs/Multicast.xml deleted file mode 100644 index 119f3c4ca5c7e8e7238aaa0c4f54c28d8d0d2b6a..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/Multicast.xml +++ /dev/null @@ -1 +0,0 @@ -7ZpJc5swFIB/jY/NIIS8HBs3aQ7tTGdyaHJUQAY1MvLIcmz311cgsQjhxHGAaTv44LHe08b73iLAE7hcH74KvEm+84iwie9Fhwn8MvF9NPPVdyY4asEsmGpBLGikRaAS3NPfxAg9I93RiGytjpJzJunGFoY8TUkoLRkWgu/tbivO7FU3OCaO4D7EzJX+pJFMtBQW28vkd4TGiVk5QAuteMLhcyz4LjXLTXy4yj9avcbFVGaibYIjvq+J4M0ELgXnUv9aH5aEZZYtrKbH3Z7QltsWJJXnDJibfbxgtiPFlvONyWNhi+x6NqYbEZIc2gjgp6K75+4BlFem/IXwNZHiqLqYiYJiiPEVANDVIgj8hQfhLFgEYK7V+woEQlqU1BgUMmzQx+VC1fWrH8YEJ+znzd62R46XZCPABF7vEyrJ/QaHmXavgkHJErlmRl0C9lSD4SfCrksXWXLGhVKlPCVZVyn4MymEynO8/FNqCkfMpl1Rxmo9jY8pOU/lLV5TltnyjrAXImmIjcKEGfBNu20pzGicKlmo4BGlvD4J/nzACNqAPwWeQ7SM/DpSMPW6YDp3mP5woKoxKreQt4Hi7UYnnBU9ZE4wEs7zfYMwcgDDFr6wC7z+1IUZqWRumsb0VdB6Nk9yoPKh9vsx63Llo6yZqr08mCF5QytnKCeGhfyclZrMlgxvtzQsxLeUldOnkdtJCWtdfhEpj4Yc3kmuRFzIhMc8xewb55silbzHez7qJRHeJmWO0wbOrPq6fygIfCfCspaboqhMEpOin86wricJwrCkL/YKH4v7xZjLO490vxHps0FTOXCPK2Mq7xbwdNE4jbmAe0vlAIx4+8bbPIvBAfm2JOBLSrVnlWqrUgO7UqNmJbOqdsm6KtneP1yyL6zSwG+p0gANVaV92L1PjKDPBq1vjgYBHXQDWgd8DXV1TK9yweMY7++L9xNVowc3QN3frp28Vxtd4B0u4A3lAsXy4zGvv2Meso950yFPebPOIxycjHDnWcV//lzm0oiHbREfDBbxcIz4niNezW5FPPCGvHEPRr59820+l5kPyRc5fB28UlCcxuwMvhfjtISvkCxBxAJHlFSQzAR/JWDUALxw36G0PljthO905Ns33wC+naD7A3zGe+0R8AcBN87cAM6vhoxh9zX3iLjrHD1FFuKW26qO+Kpm9S+gXFf7oxW8+QM= \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/Overview.svg b/docs/Thesis/src/pic/DiagramXMLs/Overview.svg deleted file mode 100644 index 2767810ea9cbca096a9f23d1084c2f4584640b87..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/Overview.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
World Builder
World Builder
Business Logic
&
Web Services
[Not supported by viewer]
Zone
Zone
DB
DB
World Model
World Model
Room
Room
Business Logic
&
Web Services
[Not supported by viewer]
Simulator
Simulator
Simulation Controller
Simulation Controller
Additional Simulators
Additional Simulators
Simulation Buffers
Simulation Buffers
Controllers, Sensors, etc.
Controllers, Sensors, etc.
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Path Finder
Path Finder
Data Tier
Data Tier
Business Logic Tier
Business Logic Tier
Representational Tier
Representational Tier
(Model)
[Not supported by viewer]
(Controller)
[Not supported by viewer]
(View)
[Not supported by viewer] \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/Overview.xml b/docs/Thesis/src/pic/DiagramXMLs/Overview.xml deleted file mode 100644 index a5f5e0b9dd4f38c343ebf0dc273b7eba4afd2625..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/Overview.xml +++ /dev/null @@ -1 +0,0 @@ -7V1bc6M2FP41nmkf4gFxf8xl033YzmSaTrftm2IUmy5GLsi59NdXAoGRJRM7CDntKp7ZhYO46HznpnOEmHnX65efSrhZ/YxTlM+Ak77MvJsZAK7vOfQ/RnnlFDeKGsqyzFJO2xHus38QJ/ITl9ssRZXQkGCck2wjEhe4KNCCCDRYlvhZbPaIc/GuG7hEEuF+AXOZ+jVLyaqheu3jMfpnlC1X/M5+kDQHHuDi27LE24Lfbga8x/qvObyG7aX4haoVTPFzj+R9mnnXJcak2Vq/XKOc8bblWnPe7YGj3WOXqCBHnRC3D0Je276jlLKC7+KSrPASFzD/tKNe1R1E7BIO3VuRdU43XbqJXjLye2/7D9ZkHgVstyDla3eM7TQHATtYEViSS4YbpS1yWFXZoiXfZnl3+SKVG1Fir8lfiJBXLk9wSzAl7frwBeMNb1eREn9D1zjHZd1rz6n/uiMt6qztIy7ILVxnOZPmzyh/QiRbQH6A38sFfF91yRRWq5pd7GoNvxmTD2LGSRXelou2VatSlCVL1Lbz3U5mqC4ivEaUr7RRiXJIsifxDpDrxLJrtxMMusFl44CctLd/gvkWtbK9JziiWDyvMoLuN7DuwTO1E6KodJLP2ubwAeVXne60PCxwgU7FiopCryVXPg0YwjxbFkzwKEqo7HB8QiVBL8NIyvjwE0DCucrN5IXbEp57RsfhtFXP4HQGZAyowAkGlZ+z/0RtB4K2O6K2u07UEu5QmdFHZry8cfZtQIf8zgA4/2ED8E6dB7FC50FiSOeBE04gHtGQeHjAPUo8jnIR/Pl24uFY8dDpEtrb91zCV1zSQAs4V9ssTyl01kOM9BCd8e88BJA9REfre4hQg4Nw/UmiQ2ce9EyCOzscHHr//9jwvbqfKHTf843pfiLp/tW2ygpUVZT6BS8p+0GY0we7eqBmIFySuqshXDMlb/6VG3xFD/Tse1Q+ZQs6+rPWY6T18MP3Wo9O88cNGlxJSv5kLN8HlvaQSDhwcPoM56Qeyj3uAr/d5xdmxxn7KA75JefuOkvT2khJ7D5BXnTY9STYQyZWIKOK/PUAI7tuCRTW9c3BrvLEC3xomzsnsyAUOOAq+u+pJNPTwgD/bQZQidiwzRQSWBFcImt0BPGRkTWEXSRhd3P1fdiUQ4znpwTzxBF+goYFyVx1tA+aG8/duPdLFPYnmoOo/9MRZgZva6N1/qcmlyLR+bsKC6vMLfk6ckuuf4SFtZieimm8h6ljFlM5nrOY6k4CH5sC1gQpkCBtkzi8rGfxHZvC8UWdVUX602VwPAnfXzBefx/h0iAuvvO2f5xuBBZ6EgTvya07s6MLrZFUaLVFllpD+DhULKwCtezoz6RFyaAgaEmxOgNiYaXieKkwl19tb2/zqx/Zte/nV8269lAOvieu3stzdayx6AfRogsJjRkLOZt7n6239Da0g1bJNSu5FxpVcj1TdAbiAWfueX5fz4+bgmE1v1Y9VRnWnOZHribpiA5W5J15GIaCG7DiMVI8DiTxJ3AMcpWeO4YMF5R+TXtb4jy3M3U0uAkguoku/d53E+FkbsI3YAjimqm9eNABnjUGIxMNxqbrRcPDBf2JBuo5dqMJG1icKCyquZ3mhCWQ08bWReiuBHhhaHAkEcjTJiyk4yGN9iD1TEIqF+8u0zRj0R1kDbssgM31jUfaPWcaIBouF73beYOBcC8Kk773vqDxnn17Z+zgLxhbWKpPpWyEr70GG5wVpOpd+Y4RBnJY/t5rofvtHTDUnm40T7AT3q4rR1qujzABdc8dq0ZscahQ6FCH6ZYLPNZGH2GjgwPJE46hHFDFkzlfO8FNK4KtVoqGxxyevhwfC8myq+3jI7KRlA6MDWppODy9ws6zOXMuPBoZDh0vCHYBg+kzGr4vq3YXVvV1O9DigeXyhoVUd0bD92UfPBmkwNE0LVKsY+ylpX1PGNi6dFzbGXQ7rn3TkAeBypAbK2oG8stCuzomDc+uWeILFRVudxBZzK1d0J3/8n15tDydqY90TYMZrG/Ggl2wEx1OCO5U5apGU40Ed7EW8bBTIccLQqRyDsbqlvHwkkXvzZMLcjE0+LNSoZSK2FVIhbmVitrb90OGPGNPfDgscG1YcExYEPtiWHBhdAp8HFl1/4jqDs6r7sCq+9Tqbka9h8M6q95nUm9PFeMZm/Qey3PTrHpP483NOvNp3oS12j5S2/3zOnO5zG61fRptd41OaWvXObHq/rHUXZXdN6fuyfAbbVYqPpBUGAz5FDUf6wQmcQIgMvlSQiIP1WX9l5Z0F76n0cfzSJACHWCwh7iDhAJR1LcHjnuCfsl49PgdDJTRTpsoLM3sjeNoLi49KxXoGsXn5+2wlC6VuOCtSzXmQrrUO2YMA0fPG44nlHjCqCsH2grgmx4iUSUFDH6rYjgTPMG3KuLkuJdf7bcqzi8e3e17fuaOfYsLOLdZYb9UoSGOkL5UYTJTDBz5fZIbSCCl/Jop0P3+VjsMXBEdECWt8zax3mG3vPvggmYWLK5L+18HMI6WXDD/BW1KVNEOwO71UotWE1IHzpnRUr2J1Kz9x3go4BP+vcXtgYuq5vYlG7qEm5fdwXa9wB/qJYB/bC9GH6S5XrvcoBr6gwOyw1IgIXgQa5UnFn31CeBrCobGSc++YfZUwuMrZEfLJwBd1dL7WmRnNynXCtCUAuS3KZNzSZDqTVYtEvRbhp6t7ExqfOJ91zWl7NDd3ZeNmxzQ7vPR3qd/AQ== \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/PathFinder.svg b/docs/Thesis/src/pic/DiagramXMLs/PathFinder.svg deleted file mode 100644 index 884b0e0a7d6cac31a3c9003e264194084be0cd0c..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/PathFinder.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
1
[Not supported by viewer]
9
[Not supported by viewer]
2
[Not supported by viewer]
4
[Not supported by viewer]
7
[Not supported by viewer]
5
[Not supported by viewer]
3
[Not supported by viewer]
6
[Not supported by viewer]
8
[Not supported by viewer] \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/PathFinder.xml b/docs/Thesis/src/pic/DiagramXMLs/PathFinder.xml deleted file mode 100644 index af371e9e55c84e3f8d1a250e228564789bcb6210..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/PathFinder.xml +++ /dev/null @@ -1 +0,0 @@ -7VxLk5s4EP41Ps4Ub+xjxplJDpuqVPmwyVGDZZsNRizIr/31K4HEw2gYTyzJZlf4YGi1BOr+1N1qCSbufHv8koNs8w0tYTJxrOVx4n6eOI5tzxzyRyknRrH8sKKs83jJaA1hEf8DOSOj7uIlLDqMGKEEx1mXGKE0hRHu0ECeo0OXbYWS7l0zsIY9wiICSZ/6Z7zEm4rq8sej9K8wXm/YnT1/VhW8gujXOke7lN1u4rir8qiKt4A3xRoqNmCJDi2S+zxx5zlCuDrbHucwobLlUqvqvbxRWj92DlN8UYWgqrEHyQ7yRy4fDJ+4LMruQFrBmrhPh02M4SIDES09EPUT2gZvE3Jlk9O6Q5Q3Aa8weapFMkcJyklRilJIWXGOfkFOJJIKyqMu4YKnza7iJGlxzsuD0lGKX8A2TijQ5mgbR+TZFyAtyN+3BWNoVbTKg9BBEq9TQouIoCApfFqCYlN2kt6uL0Ym2T3MMTy2SEysXyDaQpyfCAsrdQKmYjYEHmyXEQ4NoGqmTQtMnAYYhtd1240iyQnTpVivgd1TI1wShLNLlOMNWqMUJM8N9Sna5ftaBF2ttzQMjzH+QcmPoc8ufzIuIq38VJX5/PInq9aRb4FBjj/RcdqGA6G9xLRLrLEl54gSUBREtSWRsdBm/oIYn5jxADuMCKnp2R8IZfXtzpBWw0CAtDaivsJkD3EcAVbA7mV7A8iqBE+l/eaY5MpBuzxiXFNm5EC+hozL9cUAy2ECcLzvNn8NWKbGBqixAd6ZDQgFFsBSZQH6SpRtAez28G9G/I+2NWjKjAEYNAD2TGABAk0WgN/cmADVJkAYBoiiAClGIBylWp8D+rtrtZ5HdyLLriq28wMNsd1AaDd12sb9wXq0rJBTvsM8Jh2iMi+rGaM/aPTDvs23XU02n09ZbwMju40aFiS4Bkb3A6OyKpEhOLUYMhSnuGi1/J0SWt7OEprFlwvZg3fYvavY3fBseFS9awZLLabLxo93gwDbDIThIFowjbZ1BdG+bwAxCkDMdM2qxplYGWH4rXdW5QrUGiSYCaSj3+DvHeIFD0UJ80+EwXWyY1NIztb03+bNkAeoWqroPdC8AxNQZNWayCo+UqlfhZuhMd3CDasuDzISUHIGEmECXpR+q4lX5d+sntqMN7i1N+BLiS1vMNXlDDh8jTPQn2VX5gp89Vn2oVzMxGTZP2gB/L4FeAte8k3APaVjb+XXb5JgV7bKxjUoPRacmVhQaizYg8nFi7FSosG7Won5zw79i12/DJV6OrbYmB020ly/6/Vdv+1ocv2e+txgFyz2QJwYmkDxt9DiaQILv/eQsyA14qyA7zsKEwCw0rO1JkcQJtoCX2HLSBhe4P2pArLL+1lvfQavvAVrsP9+YD16XXfpCSTgCCTgSJDABfuM/++QrlHyPqZ1aMw3GvtQ+PoB9XUH8qlzpcEceTp2fjgmdJUWjAT9WOQtay9/VVv9OobJcKrFirYtZeN8mWjl059OV3HtSqbO3aZeqHz8m3XMD45xwasCoaYh7k01w8EkK34LD7reHRvniyMjMPkX2Hxlq9qi/JOMRS3HLGpJzWnddocTzzJIh4lnYKJyH9yD3pXPcU4KRvBqYU+vWpc/7Qvyg3eo1xHsZ7vphyP4h0mkG/XQGHWlRl3vfhZb1R5438BEaYio1/mLfIQMlLgGJUp3x2meSKiabwYGJmo3UeqdSYjeoJABk6mBiVqfozQ2IZfN9/Kq97ibjxK6z/8C \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/PeerToPeer.svg b/docs/Thesis/src/pic/DiagramXMLs/PeerToPeer.svg deleted file mode 100644 index a900d779cfa1c47df992fbd84caab8b6be8a3935..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/PeerToPeer.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client
Client \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/PeerToPeer.xml b/docs/Thesis/src/pic/DiagramXMLs/PeerToPeer.xml deleted file mode 100644 index fdfffe6d83b791171ee3b0e687c1dd09330d407c..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/PeerToPeer.xml +++ /dev/null @@ -1 +0,0 @@ -7VrLcpswFP0aL9sBYQxeJk7SLpJN3ZkmSwVkUCOQR8iJ3a+vBJdX7eB6QuTxjLyI0dGVBPfcJ/HEW2TbbwKv0wceEzZBTrydeDcThOZzV/3VwK4CPD+ogETQuILcFljSPwRAB9ANjUnRE5ScM0nXfTDieU4i2cOwEPytL7birH/qGidkD1hGmO2jv2gsU3iK+vY0/p3QJIWTp/68mnjG0Usi+CaH4ybIW5WfajrD9VawUZHimL91IO924i0E57K6yrYLwrRma61V6+7emW1uW5Bc/tcCWFHIXf3oJFaagGHOc/V1XT4Q0UscNUplxtSlqy7JlspHDX/1YfQEQup8setM6eETrCokFvJKs6SAiOGioFEN31HWbJ7H+0IK7Ij8JlLuwHrwRnIFcSFTnvAcs3vO182Jgr+QBWdclA/pOeWnmak51rIrnss7nFGmTXfBM3UscpY4L9TXwxIEDm1VaVKr710yam3zjYhAygPrxiIhtTU1hqDci/CMKN0pEUEYlvS1vzsGQ08auZZtdQGEHyYfjn7FbAObLhjV9/qvSbwSIalyjitGk1xBUiv2GsOIkZXUmlzjiObJz1LpYQvcl9M3qEV+gOO4JZbitT4m2jxrUysqMl2t0JgK5duU60OUyjRDpfJr65z2jbHxJb2W4WfCrhtvrPkCgz7JHpS5dSTBnT9sJ1qnZDtsKfs2UC+A8AHRNYDhWxuqXAewtBOmarmPGM3UGs2lGk14PqtRrNk8c9Y84+/nmZmhPOPOxyG/S33L9mNDI1BfzVnyh8n3DJGPRqowe+SjIfYDS/9x+k3VmL4tFy61XOhXC2bLhelI5QJ6t16wQeNI0JjtB43QVM5wxqHfFgwjkm8qY6CRWoUe+cEQ+8jSf5x+U/XizBYMl1owhOesGEZKGQMVQzeK2FcMB6JGcL6k4fqf3mVa+k+n31TScGej0O8O0o8s/SfS75uiPxwp+Nu3y+ORb6xZ9EYiPxhg3/r+qfSb+udCYPuFC+0XvjTNADQMrtGGIfiEijEYrBgdGzb6YSM8X8OAxnrD3MsaNjEcZ9hUUYhGagn7bwRc6+Afo99USxjauuBC6wI0N1cWqGH7Y9tyrvN7Zu/2Lw== \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/ProxyServer.svg b/docs/Thesis/src/pic/DiagramXMLs/ProxyServer.svg deleted file mode 100644 index edc96bb49d4393f13ce5f2661f7a533e04e3ac15..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/ProxyServer.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
Client
Client
Client
Client
Client
Client
Server 1 (ISP)
Server 1 (ISP)
DB
DB
Client
Client
Client
Client
Client
Client
Server 2 (ISP)
Server 2 (ISP)
DB
DB
Client
Client
Client
Client
Server 3 (ISP)
Server 3 (ISP)
DB
DB
Proxy
Proxy \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/ProxyServer.xml b/docs/Thesis/src/pic/DiagramXMLs/ProxyServer.xml deleted file mode 100644 index 4b3f5ac3fcc9966e13c0c9c244529b00b5756f00..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/ProxyServer.xml +++ /dev/null @@ -1 +0,0 @@ -7Vxdj6M2FP01kdqHIgyYj8f52OlW2kqjTqW2j57gSdh1cEScmaS/vjbYBNtES6ZAkh14GMG1MXDP8fXxtScz/261+7VA6+XvNMVk5rnpbubfzzwvDHz+Vxj2lSFIksqwKLK0MoGD4Sn7F0ujK63bLMUbrSKjlLBsrRvnNM/xnGk2VBT0Ta/2Qon+1DVaYMvwNEfEtv6VpWxZWX31esL+GWeLpXxyAOXnPaP5t0VBt7l83MzzX8qjKl4h1ZRsaLNEKX1rmPxPM/+uoJRVZ6vdHSbCs8pr1X0PR0rr1y5wzjrd4HrVLa+IbLF65/LN2F45g9/C/c4vbt+WGcNPazQXJW8ceW5bshXhV4Cf1l/j8guCnjG5rf1xRwkteFFOc9HShhX0G1ZG7ia3POoS5XXR7EtGSKOmdCi305w9oFVGBMk+Y/KKWTZHsqCtaUSyRc5tc+4dzAtvU7RZ4lQ+RjoCFwzvjroT1CBx6mO6wqzY8yryBqgIomgvL98OHAqUbdnkjyuNSPJ2UTd9AI+fSPzasQwiG7mUs1peSseXYJTf7Org4V3G/m6c/yOqOB4sIUEFuxHdSjiPoM0mmyvzQ0bqFvLUrsSNjSpfMWN72d3RllFuogVb0gXNEflC6Vox6RR6nEqDyk3CNxrMG7ot5tIUxJ2hLzBBLHvV22rDUd76SDPe4oEykU4ZEBhU4E5eYCbvMthQv0Y3gsRWX78jGZbtNnkjOgH3IbmRHYYJYOruQ/ALE0jwOJDliz9L0OKD4UtZfO8dLH9IpgOvChJr8Zj59rkMBBUZgAAmzQoezDMqHsLREAiXICoKB9cVbnoIKIERUDw7oAC3JaBEPcQT6E50uTa6uAZd4jH5YkuJiS+XzRc/MAefxIEjMsb/vvjUHeh1EqElAVa7hZiaOM+ICxEn21DJCH52ky/K5gE8DebhhOhxAvWhSkMDZa8N5agFZAD60KVJL7rUtXUp//5iX5Y5gM84paGqkIBAGR5xkfG3Fo6+dz+knFVDeaUl9c7Xp8Tt3PFBP5RwYJMUGiN0NsCJCzUXvAvjQtBhEJAxPUUMbRgtfsRcRA+BPjTkH0gCK8y3px96gBFaMD7hgn8Ot/G3dn/67enxZwtY/q1Mx63AXLKh57KC8NNaTHzL94K3M3gvPMc7l5J1tmxs15aamPwlOJPcgiHU5Tm05XnSgo/XBz6hhc/9bQc89M7RIoSkyeKzCcQqS1NyrOPqof4USXYGGENzUg5sGL2hYBwiyRd9zCQfHC3JF8dAD8zDJfnglOS7tll4Ep0xyTfE5CwyJmfhYbYmKgDH9eNJkKswpGbnY4Qh6ISNI9Jp50PHbx7RUDEqnDLLVx+jklEzheEQCQPwMcONN1q4SXikbxyeroHiwIF+FAEIQeQFIBgs2kzrEtcWbYALDMHcMlMeLtjYGak6leFNqYyqb3uhPh60rhwNlcyI7WSGhce0cNQDyEY+0XfHXDiKow4oT5nhTkiaS4CJjeNQmeHYzkhMmcd3wmiqcDVMjpB5TGwYbU3eJpOPSOyjSPcsieuUp+OCWEtTQNeX12YS4tgyYpAcXVQ+orwtbI0UpFx4ay7GVYObzYEGxrAFY2X7n6I9TAyKmU1Ur28Jc6uhyNxbEhkN9afw1ebya6WmPS19J5uCszInAI4xxVOjzMncMVZYfFNO9MedehZxdeQ55FfFfgp988thN8z749TlxKQIfocOXXkVmyt3CXTgUMwKbfk65R0uO+9g7pQLRk072KPYxJfL5kvshufji9JTUxJk0CRImBibdlpXPgZLgoShrUam3bPjrphEtiCKuvOo9x2Tkdeh4095sS6dO/L1zu2H4+2YDOMBeva09eKknp209GzvjD3b/oeYeuWJF00rT+VIa2h0MN66U2SvDE6p7HfCGBiRt+VfFYdKZQPX7mePBd3trwFK7TcLLhBXV8e1ZW9024D6Dlj55eGHMqr8zOG3SPxP/wE= \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/PublishSubscribe.svg b/docs/Thesis/src/pic/DiagramXMLs/PublishSubscribe.svg deleted file mode 100644 index eec880dc8a70963512db0f4c2a653aecf213d150..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/PublishSubscribe.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
 a
[Not supported by viewer]
 b, c
[Not supported by viewer]
 a, c
[Not supported by viewer]
Publisher - Subscriber service
Publisher - Subscriber service
 a
[Not supported by viewer]
Publisher 1
Publisher 1
 b
[Not supported by viewer]
Publisher 2
Publisher 2
 c
[Not supported by viewer]
Publisher 3
Publisher 3
Subscriber 1 (S1)
Subscriber 1 (S1)
Subscriber 2 (S2)
Subscriber 2 (S2)
Subscriber 3 (S3)
Subscriber 3 (S3)
Topic
<b>Topic</b>
Subscriber
<b>Subscriber</b>
a
a
S1, S3
S1, S3
b
b
S2
S2
c
c
S2, S3
S2, S3 \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/PublishSubscribe.xml b/docs/Thesis/src/pic/DiagramXMLs/PublishSubscribe.xml deleted file mode 100644 index 42afb2f7be69c91cfa4a05eeca0b4c22666de9b8..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/PublishSubscribe.xml +++ /dev/null @@ -1 +0,0 @@ -7Vtbj5s4FP41SLsPMwI718cm7bQPrVQpK237aMBJvHVwBM6tv35tsAGPQUknhIkUR5oBji/A+c73cY5JPDjfHD+naLv+xmJMPeDHRw9+9AAIAjAWG2k5FZYBmBSGVUpi1akyLMhvrIy+su5IjDOjI2eMcrI1jRFLEhxxw4bSlB3MbktGzbNu0QpbhkWEqG39l8R8XVihvjxp/4LJaq3OPBhOi4YQRb9WKdsl6nQegMv8UzRvkJ5KTZStUcwONRP85MF5yhgv9jbHOabStdprxbiXltbyslOc8EsGAA1Uxk/63nEsXKEOE5aIzSy/IyzH+OJozTdU7AZiFx8J/1Hb/ym7PIOhPEx4evqhhuQHRaNsyzhK+QeJU3WO3PZCKC2HxLpHRFGWkagwqi7yjP9hzk8qeNCOM2FiKV+zFUsQ/crYVvXLeMp+4TmjLM1vEfr5p2zREMu+S5bwF7QhVEbuF0z3mJMIqQZ1rgCo46YpbQgUKhnbpZHyMQiU38VNrzDXYAwKo0SgNlRB9xmzDRZuFB1STBEnezNYkYr5VdmvAl7sKOxb4gCqU+8R3WEduyO0ES6cJWEmN8gro7YKFo6P3AyJFGfkNwrzDtIfW0YSnl/acOYNP8qJKFklElbhISzcN9vjVDqZflANGxLHcvyMohDTWcmpmrsVq5phacXvMrxKUsjrwkevQXDU/RmsNRBSo/xnfzAGxdCTMdHFEKq5v0s31rqw5TITgfMa4/ISLoNdy3Kn9Hfsfxv7h+/H/uFZ9ocemMv4fxwRmHQoAuNgYIjA032pwPQGKjB2MvA2GRi9nwyMLkkCHkwGpl3mAqNXMgDuSQZgN7WASgCUEASGClS5wU81gaECFcfrQhA8jBB0x/lXgaIDdwqeRSk+FI+j/D+ERjiCkW/OWAiTmuS64NK3WNOW77uQkmwtaA/8J/G32IVZlJIwN2Q43RPhoNcRWYWfxOewJhwvtij35CFFWzMky/LabxeQ8snzB1Ehgq5Nf66KFksNW8PHkqNW2ZkOzfIDKowP1bpGoPusa2sage+3h9fFj5Qy3PsqMIBLLXK6TRpSi+5l5vLUQsetW18A7SR+Q04RjMemiN9XaaHjsEX2bXUwpcDp+1l9f5r6psAHDQKvbXWBH3Si76BnfXfyntNqemfyDs7Ke/g48q6dcbW8P4maMRjeVZGoI69F0G05cIJ+raCPehV02LOgj52i537370zR4VlFf6BFQO2MLhL28vXifQi6xrBF0G05cIJ+paCDfjN0+82+sdAmrt3/axH87XC+Fmc4ftdKzH6Ha+AMcpyBw7l7nPtN0OyXdAbOMMcZOpw7x7lf3Yb2yplIwCgvSunRSu78w7YiC1ZWMWPZ4MBvztaseLj0tQlo4Pik4a1JN9DbNbYFfZ3zDv/u8Q8m/tkAuB35B3ZSjhymHXMa+j1yemC/AFsExZdpFq7G6pyuTdjekK52jRU6TLum66BPujZUU25tu3uaNmB6Q5rapVPkMO2appM+aWp/q0zS1D1Vb0TXBmy7oqs4rH73VixkV78thJ/+Bw== \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/Sharding.svg b/docs/Thesis/src/pic/DiagramXMLs/Sharding.svg deleted file mode 100644 index cbc5b505d22eaf62d936821c98e157e16c21852c..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/Sharding.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
Client
Client
Client
Client
Client
Client
Client
Client
DB
DB
DB
DB
DB
DB
Proxy Servers
Proxy Servers
Shards
Shards
Persistence servers
Persistence servers \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/Sharding.xml b/docs/Thesis/src/pic/DiagramXMLs/Sharding.xml deleted file mode 100644 index a9399495e7bc81257538beb48c2edd3a11c80585..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/Sharding.xml +++ /dev/null @@ -1 +0,0 @@ -7Vxdb6M4FP01eVxkm+/Hfkx3HmalarvS7j66wU2YITgybpvur18bbAIYEkIhSSWiaAYuxg73nHt8MZcu7LvN7neGt+s/aESSBQLRbmHfLxAKbEf8Kw0fhcENw8KwYnFUmODe8BT/R5QRKOtrHJGs1pBTmvB4WzcuaZqSJa/ZMGP0vd7shSb1Ubd4RQzD0xInpvXvOOLrwmrrnyft30m8WquRHVdd3jNe/lox+pqq4RbIfsk/xeEN1l2pjrI1juh7xWR/W9h3jFJebG12dySRntVeK8576Dha/mxGUt7rBBioH8I/9LWTSLhC7aY0Ff/d5ldE5DlA7K35JhGbUGySXcz/kWbLVXv/qkYZx4zfSCj23eS2hzhJVBuSRrrFMsFZFi8Lo2oiB/hJOP9Q/MCvnAoTZXxNVzTFyQ9Kt6pdxhn9Re5oQll+FTbIP+URjaJs+0JT/oA3cSLJ+Z0kb4THS6wOtHVRuEj6pdPNypTRV7ZUrZygBFSECaEbwtmHaMNIgnn8Vu8LK8KuynblqY80FqMgoGLLc1RsqdBC0Kl3IZy8IlydtcdebFR+xt6UM6KdHY4ixxtOXtXPvUtiovqtcuaNMOnD5CaJV6kwcQnMLVZ7CXnhEoktXsbp6q8ctGBv+JEfvkd7y58qtGBuW+OtHGb5+pyTqCADlMBEMRPRH1M5iHC9RDgHUdPXqbO1jDZ5boKfSXJbxqvGvaTqCXwSdK20VAE/mGfSl2R3mGkmq9QJjg1q7IB+KEIzt7zvhQwC1WpdETEfdFOxRqIDjIEwnEhPxPWzD3noN2AB29WW/LCFwtLwSFgsfjZhsw6pVq7CtdAFjVMHjXqLU19G6NFnDfmyGoL88JwK4p9DQdAsIP0FBLUJCGjn0PgCgmYB+eICEoAz6kd5azWtfjQExJv1o1M/PP+SCYgefdaPL6sfjr7FPYuAAMcgjEEV6e5t55WqVSn8rJuDUz0AAWjkYNBpuY8LWnwA4QhOcO3jPqhzSJL8fR1z8iTYL1u8M7w1mJvHwGa3kouG1jMWQmfFGVVBIbZu0lXePXRPY/po7NXRvhRASQk/EEP9iF6wyQS6gqI/GYo9mKxBiTDHGaeM9MLxqhXIwPBzSGlRqgek1xaPTguSzhhAegaQ97cGlOLqeAOpmvtbYkWZDI81p8JNHEVJFzXqudQpUTvN3HIESLeZnLYAiVqARKNMLu4VTi4t+flkM0tgUnmeWYbR3L3czBKYSfU8s5yM1BXMLIH5iGeeWYYCedmZZRbWkYT1IMYBOjp3Tqa6EPSQ3bNnD3brI8bJEggfzjwfKYHwL5dA+GhOIE5IIDqQuoIEwjfXGOYEYiiQl00gzFRwFtbpE4j2ld0Jc4hwhvkCMLdnSdPBrDuZYZ4UZs9xazBD57zRDOds+BIw27b5RHJCkHsky5USAuXqCGfrPPWBhzKv7sTXGQKLHPQRcwFJmg+HAFz0rxs4eC/itvhX2z5ZU+34DbEOGrAV5QxGTbXZUXiko/GKsyHs8ShhZsUnWBEILQ98EHq+78DQdhsS4MJhHAm8k7odkzE9lghnxnyCMRAgv4atNw5lIHBO6ndEzqAeCUZr+Vqt7m1vHkCgQaVqNdZeO2+8/c2BhhSVeeSpZDE7q6wITcGQ07KTq2FIWem5qNR5Wo6r6z6bhZzXTqIABpZd/dQ4AG1QP+oPY5ev3xjU/Yb9MhyBM/6oNNvKBln31fhBYxy39iaj2Ch6HE7b09Kn66GtLkMudwriuqCzBPnamevrdz60XjXXM3unVtCzyjnSCew6hZAXWsquptLpNPG0TGsm1/nINfje7jC5HHQ+cvVYwb1KcqkJF1rARrVJ1y33m+zqJORXpWMQAisoJ59ych6Y64VhYIWOW36DZreWuCPZf+3JOGn3WG6eOfmVOGm8TDEOJ0W3Z+PkF711nTnZxUlHCBr0UPlFUzA0HyQIyy+ajqDmWzaPjO6kk58IeyMsM/h6hYUUtZWWkasq8vfg1LtyzkiPcmzUXB4xS/hC1yT2KEUW+rlRBfKnNWbRjPT4SAfAvyTS5vqC0OAszjhJhb8F1nOITwR86AXHgS/Vd3zkL/KY5WiqUXXyZ1/wvtiD2kapozswR4Xl68MdHQ2e5cXu/s+3Fc33fyHP/vY/ \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/ThreeTier.svg b/docs/Thesis/src/pic/DiagramXMLs/ThreeTier.svg deleted file mode 100644 index 707e086fa1ab13372f11c7a860ac301f0da4e7dd..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/ThreeTier.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
Client
Client
Client
Client
Client
Client
DB
DB
Representational Tier
Representational Tier
Business logic Tier
Business logic Tier
Data Tier
Data Tier
Web Server
[Not supported by viewer]
Web Server
[Not supported by viewer] \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/ThreeTier.xml b/docs/Thesis/src/pic/DiagramXMLs/ThreeTier.xml deleted file mode 100644 index d03fbe26c1a62e39aafcf2eb5981c7cf5e741049..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/ThreeTier.xml +++ /dev/null @@ -1 +0,0 @@ -7Vtdc5s4FP01fqwHkPh6zEezfejOZJrOtPsog4K1lZFXyIndX78SSNggcLBDnGYGP8TS1UWCe44u54IzAzer7V8crZd/sxTTmeek2xm4nXleGDvyrzLsKoMfBpUh4yStTO7e8EB+Y23Ux2UbkuKi4SgYo4Ksm8aE5TlORMOGOGfPTbdHRpurrlGGLcNDgqht/UFSsayswJyesn/BJFvqlaEfVwMLlPzKONvkermZBx7LTzW8QmYqPVGxRCl7PjCBzzNwwxkTVWu1vcFURdZErTrurme0Pm2OczHoAKhxKcTOXDtOZSh0N2e5/LourwirYxzZW4oVlU1XNvGWiJ8H7X+Uyzz0VTcXfPez7AdBbagcHBAawz3mZIUF5nryQiAurhSE0pBQVBQkMeY7QuuF89R2ksYDl3+xEDtNLbQRTJoYF0uWsRzRr4yttV8hOPuFbxhlvAwAcMpPPWIIoHwfWS7u0IpQxesvmD5hQRKkB/RaLtT9rimraKsQ9yKmTQXb8ER7wUjvAcQzbNzcPWHkNsRMRpHvpBPHFAny1FwA6Q2R1X57VsiGJkY3SczqT4hu9Kw3lKjzbVPnCXMVD3pFSZZLk1BBvka6R/GjUFFdo4Tk2fcSgGhv+FoO33p7yze9w9zStkRrtUyyWShKFjrYKqgp4TIJEKYWkWFTaFWA6DODTdLWm04dS9EC0+t62xrMNPFP4oak3oGn3vcvcKafIyqWeHucJTb4JgGbTPW8z16uo23Lg8wVOq/nhwv9N0girRwC/Dpl6BxSO0wpZEAK8b33TCFm9SmFfJgU4kcXTSHhJXRIO4VAOOWQE3JIEHblkB4ajZ5DzOpTDvkwOSS6aA4xmueAIBY1mvFSgD4vicAPEmnl8SyrWQulEu/VNlOV7nyB5Cafk4JpAsjWVZ6V07v+aaiOhpRhdiJhURnsCF9GADUwcm9ncjec+xbMYQfKNUKvg9mdYL4AzJEB671gtiWjLRH2t18d7BQVy1IguC18B2ZQeA4watF7JCQoebmc57gn3GNtBA7i63fE19gG32H1CveMqJtlDTDw537kgtgHMIpA6DXghi0MKx2gpzh8otSe1T9l1kpJWLOW5KgDMowv3oC00CnXeqTeGeR5UZr1kadmbC1WXSlOo6Za9UFtaKtVI39Nu3GA7Lf9/3hqOuE8iqMoDKDU6DEEDRLJ7TUPIh/EQBYp0AticB5VQzeYQxB5juRl6MZOfNIqI1IXRDZTzyh+nHnkNwjg+D34H9REXhQ0aRZPNdHxTdGsiVzwrkWRazLqq7njns6dAMYt7gTBRJ7Xk+dST+VcOEBjKU277tWT+gUcWhh3p+fC+x9Ve81yAnQ8uu5SmaOUjMB+pmAFwJQGKRKoEIzjQdXEH1PaD2GvVVn04t3AtaLPUZHwZshBW+7dXlvYydMXx7RcR4mmTVZI2g+VViRNaR8Xmvn2lGJxnER0LnLmkNaWtOs+2IGrNwqu9svGYzJ+pLLvoveA91LVcdSq6Nt1+lDh7AcvTDSiNobxxIcL8cGLR+KDNdGIfDDXPvFhdD74fhNGEJ3Lh9ZEb5gefFsGfMNrjgsZUqTexSDl/p3IW/ikDYZpg6PKALY5ckFp0PEjgutNQXJcFNJKWSaLxQnrEbH2Wts4ijveAHS+zxsHb2DhfStrsAnjt9zPF93QQce9PKBCX3ID3uC/DTMDn6q37lfSwfXW2/2gbGXq+wdeyLEHzJ8UT6oZ5dlUk1YuE31GeRcMWsrPKMEXHgGMQ5+uhzcTfT4QfSLvYvSR3f3P6iuluf/PBfD5fw== \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/Zoning.svg b/docs/Thesis/src/pic/DiagramXMLs/Zoning.svg deleted file mode 100644 index 94f74949cded1b9ea62309afc4d761c3937b13fe..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/Zoning.svg +++ /dev/null @@ -1,2 +0,0 @@ - -
Zone 1
Zone 1
Zone 3
Zone 3
Zone 2
Zone 2
Zone 4
Zone 4 \ No newline at end of file diff --git a/docs/Thesis/src/pic/DiagramXMLs/Zoning.xml b/docs/Thesis/src/pic/DiagramXMLs/Zoning.xml deleted file mode 100644 index 9457a2bd1f4c8429524a9387b31bf25ac7ca275c..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/pic/DiagramXMLs/Zoning.xml +++ /dev/null @@ -1 +0,0 @@ -7ZpNc6MgGMc/jcd2QCAmx23abi976mFn9kaVKFOUjKFNup9+IaLxJWlsR5k9kENG/w9vPr8HfCAJ0Do//CzpNvslEyaCECSHAN0HYUiiUH8b4aMSIryohLTkSSXBk/DM/zIrAqu+8YTtOgWVlELxbVeMZVGwWHU0WpZy3y22kaLb65ambCA8x1QM1d88UVmlonp4Rn9iPM1sz5isKsMLjV/TUr4VtrsgRJvjpzLntG7KNrTLaCL3LQk9BGhdSqmqq/ywZsJ4tvZaVe/xgrUZdskKNabC0o7jnYo3Vg/5ODD1UfvCPM/WFmOlYodzBOhLXRwMxwCbJ9PxwmTOVPmhi9iGcF3FxgqE5HaFcbgCCEV4heGyMu9PIAippKzFoNaoRZ82HZ2eX19YF1xwB7zujiNdZiqAAN3tM67Y85bGxrrXc0Frmcp1B/dQXzZ8TVlBX5i4ayJkLYUstamQBTNFVSlfWS3qwAHHT2Op49A0u+FCtEraENO6LNQjzbkwrnxi4p0pHlNrsLMMYnt/risqeFpoLdbsmDbeXeQ+nm8TZJbvTQQGQCECQ6KQgAmQhh7p5EgxHIE0Ooc0nAIp8khnR0rGEsVTEMWe6Ozr7nLssgunILq8TlTX0Pkcu06T7rZVkrfhBxMB38fbET8h24BJS5pwdoJmG/gvgSPUW5URvI0gDpfEftcM2hFwLgAm4L8akVh6/hMv4b1E+gbDW+KO+Ijc2ROfeMYvesQd4h6RV3vcE+MG5GqONhfuETm3xz0vbuiS94iM3POemHcvYYfAIW/iebvfcvfmN3b4+l543q55k/5BN3LIO/K8nc/vVZc3cYjbH7+4n964ixu5e3tDMNx8/zGuCmtDi7t+QtUFfBZSG4mVBl4z/tKOFz+sIedJIi5FVPcA9wsxNIp2+AntCeCO+RGLnKE7xe8dEAz32pYu8nTnoAud0h1utSzd4Zrt6X5nYe6fizulO9xYWbrY052DLozgXHT17emvOUdb699P6OEf \ No newline at end of file diff --git a/docs/Thesis/src/pic/imgs/Old/AoI.jpg b/docs/Thesis/src/pic/imgs/Old/AoI.jpg deleted file mode 100644 index 6438e534184de7d753d2d0af8975e0b2154695b9..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/AoI.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/ClientServerArch.jpg b/docs/Thesis/src/pic/imgs/Old/ClientServerArch.jpg deleted file mode 100644 index b8da734f1412ab74b1936e682b66a0ec5db63e25..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/ClientServerArch.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/Cloning.jpg b/docs/Thesis/src/pic/imgs/Old/Cloning.jpg deleted file mode 100644 index 8c93c3fc5636db923e5aff72c4599921296d95e6..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/Cloning.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/DistributedZoning.jpg b/docs/Thesis/src/pic/imgs/Old/DistributedZoning.jpg deleted file mode 100644 index 000754829a3052fd3c0d9698c6b92681e3f45a9c..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/DistributedZoning.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/MVC.png b/docs/Thesis/src/pic/imgs/Old/MVC.png deleted file mode 100644 index 27f3407bfd909fdea23af1cd4dc67c34e7cd653a..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/MVC.png and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/MapSplitting.jpg b/docs/Thesis/src/pic/imgs/Old/MapSplitting.jpg deleted file mode 100644 index f196a2ea120790ed61ecbd9f26926a54d4765a1a..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/MapSplitting.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/Overview.jpg b/docs/Thesis/src/pic/imgs/Old/Overview.jpg deleted file mode 100644 index bcf1ceb573fb9605fdeb7162482d1277c6efc49e..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/Overview.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/P2P.jpg b/docs/Thesis/src/pic/imgs/Old/P2P.jpg deleted file mode 100644 index c2c6a1afae6a83eea46262d8c29cf9e4f670b42c..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/P2P.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/P2PMulticast.jpg b/docs/Thesis/src/pic/imgs/Old/P2PMulticast.jpg deleted file mode 100644 index d2796ff28053346dae6e00b297228717340f1b93..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/P2PMulticast.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/PathFinder.jpg b/docs/Thesis/src/pic/imgs/Old/PathFinder.jpg deleted file mode 100644 index f648a1b7e6a2f2c324e48e1229337e69c185e433..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/PathFinder.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/ProxyServer.jpg b/docs/Thesis/src/pic/imgs/Old/ProxyServer.jpg deleted file mode 100644 index c3594dbba6acd30bd5427f4d44fbfd7b1ded78f3..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/ProxyServer.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/PublishSubscribe.jpg b/docs/Thesis/src/pic/imgs/Old/PublishSubscribe.jpg deleted file mode 100644 index 69036721d2b8675ae17e015e96d3a11eacd9c74e..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/PublishSubscribe.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/SFSArch.jpg b/docs/Thesis/src/pic/imgs/Old/SFSArch.jpg deleted file mode 100644 index 9c19f62e0092b2987cf1d27d9b9a8f2c5405064a..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/SFSArch.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/Sharding.jpg b/docs/Thesis/src/pic/imgs/Old/Sharding.jpg deleted file mode 100644 index 25b66835fc42f9887eb0277b52fcb02b121f5c9e..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/Sharding.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/ThreeTierArch.jpg b/docs/Thesis/src/pic/imgs/Old/ThreeTierArch.jpg deleted file mode 100644 index 4a991b81d0e6d53b73a7f5f4c2c6204e02b2f944..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/ThreeTierArch.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/Old/Zoning.jpg b/docs/Thesis/src/pic/imgs/Old/Zoning.jpg deleted file mode 100644 index 7ca79e63597948661d20211e042fb82e77603207..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/Old/Zoning.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/screenshots/Messaging.png b/docs/Thesis/src/pic/imgs/screenshots/Messaging.png deleted file mode 100644 index 4c569edc8aa3a16aa1d37258ed0999e3565c7cf5..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/screenshots/Messaging.png and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/screenshots/Performance-1.png b/docs/Thesis/src/pic/imgs/screenshots/Performance-1.png deleted file mode 100644 index 486c9ff067120cde4a152c0adbbb62b654dd5673..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/screenshots/Performance-1.png and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/screenshots/Performance-2.png b/docs/Thesis/src/pic/imgs/screenshots/Performance-2.png deleted file mode 100644 index af2dfd7afbdc2691769f56889f8ac99bf85185f0..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/screenshots/Performance-2.png and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/screenshots/SwitchCar.png b/docs/Thesis/src/pic/imgs/screenshots/SwitchCar.png deleted file mode 100644 index 20f7d2369382a16aeabe2f59ba90d0476d6e4caa..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/screenshots/SwitchCar.png and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/screenshots/WebServerConfig.png b/docs/Thesis/src/pic/imgs/screenshots/WebServerConfig.png deleted file mode 100644 index b38792e113d91c3604447e8a10a7e757340051fa..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/screenshots/WebServerConfig.png and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/screenshots/ZoneConfiguration.png b/docs/Thesis/src/pic/imgs/screenshots/ZoneConfiguration.png deleted file mode 100644 index 46e0f37ca9e75daed82c3532904beba8002eb284..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/screenshots/ZoneConfiguration.png and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/screenshots/play-scenario.png b/docs/Thesis/src/pic/imgs/screenshots/play-scenario.png deleted file mode 100644 index 2007eb1cfbb0e07659834ea8cd45df6a8cc52ec1..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/screenshots/play-scenario.png and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/screenshots/scenario-menu.png b/docs/Thesis/src/pic/imgs/screenshots/scenario-menu.png deleted file mode 100644 index 3faa650b88445b604f08c36d4d69829f5d7bbefd..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/screenshots/scenario-menu.png and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/sfs-class-loaders.png b/docs/Thesis/src/pic/imgs/sfs-class-loaders.png deleted file mode 100644 index 8b004d72fbbfa9c326c928e50ef953ee40ce7b82..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/sfs-class-loaders.png and /dev/null differ diff --git a/docs/Thesis/src/pic/imgs/sfs-room-architecture.png b/docs/Thesis/src/pic/imgs/sfs-room-architecture.png deleted file mode 100644 index 45e1c76340f139d4c7e7312cfd3e509db62491ee..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/imgs/sfs-room-architecture.png and /dev/null differ diff --git a/docs/Thesis/src/pic/logo.jpg b/docs/Thesis/src/pic/logo.jpg deleted file mode 100755 index 00da52d4fce6ebf0ce4a779661e3b9ac4eea2627..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/logo.jpg and /dev/null differ diff --git a/docs/Thesis/src/pic/pics.gxflag b/docs/Thesis/src/pic/pics.gxflag deleted file mode 100644 index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..0000000000000000000000000000000000000000 diff --git a/docs/Thesis/src/pic/pics.pptx b/docs/Thesis/src/pic/pics.pptx deleted file mode 100755 index cb6d8d38c0a74580d41b5c2d49971b89d102ccea..0000000000000000000000000000000000000000 Binary files a/docs/Thesis/src/pic/pics.pptx and /dev/null differ diff --git a/docs/Thesis/src/tex/abstract.tex b/docs/Thesis/src/tex/abstract.tex deleted file mode 100755 index a9455c45685ab50aa64f9c613dcbbe1315dff5a1..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/abstract.tex +++ /dev/null @@ -1,13 +0,0 @@ -\vspace*{2cm} -{\bf\Large Abstract} \\ [1em] -Autonomous driving vehicles are currently a challenging research topic in automotive field, whose main goals are to ease traveling by automating vehicle's navigation and control, as well as ensuring safeness of passengers, pedestrians and other vehicles, taking part in traffic situations. - -This concept requires many components to work together, in order to implement and ensure that an AI component for vehicle control is capable of substituting a human being and meeting all the safety requirements, seems to be a complex and responsible task. As a tool for easing the development of the concept as well as its implementation as a prototype vehicle, a simulation of such autonomous driving vehicles in a controlled environment can be implemented. Such a simulation in a virtual environment provides the opportunity one to setup and execute scenarios, which in real world would require a prototype that has a higher cost. - -We have implemented a simulation platform, capable of configuring scenarios, executing multiple different simulations simultaneously including all the selected scenarios and providing 3D visualization to the end user. In order to make the virtual world more realistic we borrow ideas from Massive Multiplayer Online Game development \cite{Caltagirone:2002:AMM:771322.771339} to allow users to interact with each other. This means that in a multi-user virtual world, execution of a scenario has to guarantee that all vehicles defined in it have to complete their task by reaching their final destination, as well as ensuring that unexpected events are handleable without side effects, e.g. vehicles defined in other scenarios, that interfere currently executed scenario, will not cause any accidents. - -Since our simulator environment allows us to \textit{plug in} and execute different simulators using components, such as vehicle control, navigation and coordination, network data collection and transmission, combined with extensible configuration, it is capable of providing a large amount of statistical data. The amount of data provided, as well as the specific cases covered, depend on the executed simulators, used components as well as user-configured scenarios and environment configuration. - -The main goal of our solution is to allow test execution of real scenarios in virtual environment, based on real map data, and to provide statistical data, useful for analysis of prototypes of autonomous driving vehicles. By extending our simulation platform, a larger amount of scenarios can be tested, and by allowing custom environment and vehicle configurations, the amount of prototypes, that can be simulated, is increased, which makes our simulation platform a powerful tool for easing the development of autonomous driving vehicles. In particular this master thesis targets to distribute a simulator in a way that allows large amount of users to configure and execute simulations and interact with each other from any device, supporting web browsers and \textit{WebGL} (\cite{Cozzi15}) as well as reducing server's load, reducing latency and improving users' experience. - -\newpage \ No newline at end of file diff --git a/docs/Thesis/src/tex/conclusion.tex b/docs/Thesis/src/tex/conclusion.tex deleted file mode 100644 index 141ed1fb12e5cebe80e8d146dcda216e3c45c2fe..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/conclusion.tex +++ /dev/null @@ -1,11 +0,0 @@ -\chapter{Conclusion} - -Autonomous driving vehicles are important scientific topic nowadays. Many researches are being conducted in both hardware prototyping as well as software simulation. Since software simulation is cheaper, better configurable and also can provide very detailed statistical data, many simulators are developed or in development process. - -Common software simulations are normally single applications, which have to be installed on a machine with all the necessary dependencies, to allow configuring and running a simulation. These dependencies can be about the technical data, necessary for correct calculations or models defining how dynamic simulation objects, as vehicles for example, behave in different situations. A simulator distributed as a single application might also depend on the operational system, which leads to limited scope of potential users. Additionally, when a new model has to be used, a new version of the simulator application has to be installed, together with a new database storing the necessary data for running the new models. The simulated environment is also stored in the database, and since an application is installed as a bundle, whenever new simulation scenario configured for specific terrain and environment needs to be executed, the simulator application might not be able to provide the necessary environment to run this simulation. In such cases additional updates have to be requested or the simulator application should be open for client extensions, i.e. allowing the users to develop software extensions of the simulator in order to be able to simulate their specific scenarios. Such mechanism however does not seem to be a good solution, due to the fact that most of the users of software simulator are engineers, rather than computer scientists or software developers. - -As we already introduced our platform, we have pointed out that our solution allows easy update of visualization and even server applications, due to the easy deployment of new versions of the applications and that the user does not have to install specific application, but rather user our client application in a regular web browser. Additionally, our server serves a real world data provided by OpenStreetMap, and due to the distributed approach we have made use of, our platform is capable of serving very extensive map. Along with all these advantages, the client/server approach brings its negatives, concerning to mostly system resources, communication and security. As we already discussed, the communication between client and server as well as the security of the connection between these application are optimized via communication protocols, encryption and correct management. Resource consumption is still high, especially because of the broad virtual world, which is served by each sector. However, our platform is built in a way allowing distribution on many machines, thus providing a solution, which will reduce the memory consumption and allow even larger world map to be served by the simulation platform. - -More work has to be done in optimizing the simulation processes and reducing further necessary memory for handling world data. We currently work on development of new concepts for simulation optimization, before we can start their implementation and adaptation to the current simulation platform. - -As test driven development is in the basics of the development process of our platform, automation of model and simulation tests is a desired improvement for our platform. \ No newline at end of file diff --git a/docs/Thesis/src/tex/cover_en.tex b/docs/Thesis/src/tex/cover_en.tex deleted file mode 100755 index ab926ace8665ddf3e77062ca35bb35538f58824e..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/cover_en.tex +++ /dev/null @@ -1,73 +0,0 @@ -%Dieses Teildokument beschreibt die Titelseite. -% - -% Seitenzähler auf 1, Römische Ziffern. -\setcounter{page}{1} -\pagenumbering{roman} - -\thispagestyle{headings} - -%\changepage{}{}{}{}{}{}{}{}{} -\changepage{5,1cm}{2.4cm}{}{-0.7cm}{}{-2,3cm}{}{}{} - -% Eigentliche Titelseite. -\begin{titlepage} - -\begin{figure}\raggedleft\includegraphics[height=3.0cm]{src/pic/logo.jpg}\end{figure} - -\begin{tikzpicture}[overlay] - -% horizontal lines -\draw[color=se_dark_blue, thick] (-1.6, 0.9) -- (17.4, 0.9); -\draw[color=se_light_blue, thick] (-1.4, 0.7) -- (17.4, 0.7); - -% vertical lines -\draw[color=se_dark_blue, thick] (-1, 0.9) -- (-1, -24.5); -\draw[color=se_light_blue, thick] (-0.8, 0.7) -- (-0.8, -24.5); - -\end{tikzpicture} - -\vspace*{-1.5em} - -\begin{flushleft} - {\fontfamily{phv} - {\LARGE - RWTH Aachen University \\ - Software Engineering Group \\} - \vspace{3em} - - {\LARGE \textbf{Software architectures of distributed multi-user}\\} - {\LARGE \textbf{simulation of autonomous driving vehicles}\\} - {\LARGE \textbf{\ }\\} % Replace with \emptyLine if title is shorter - {\LARGE \textbf{\ }\\} % Replace with \emptyLine if title is shorter - \vspace{3em} - - {\Large \textbf{Master Thesis}\\} - \vspace{3em} - - {\large presented by\\} - - {\LARGE \textbf{Ilov, Petyo}\\} - \vspace{3em} - - {\Large \textbf{1st Examiner: Prof.\ Dr.\ Bernhard\ Rumpe}\\} - \vspace{1em} - {\Large \textbf{2nd Examiner: Prof.\ Dr.\ Stefan\ Kowalewski}\\} - \vspace{1em} - {\Large \textbf{Advisor: Dipl.-Ing.\ Evgeny Kusmenko}\\} - \vspace{7em} - - {\large The present work was submitted to the Chair of Software Engineering \\} - \vspace{1em} - % The present work was submitted to the chair of software engineering - {\large Aachen, \today\\} - } -\end{flushleft} - -\end{titlepage} - -\changepage{-5,1cm}{-2.4cm}{}{0.7cm}{}{2,3cm}{}{}{} - - - - diff --git a/docs/Thesis/src/tex/evaluation.tex b/docs/Thesis/src/tex/evaluation.tex deleted file mode 100644 index d9e6807db5280daef6a6394a0c33368c4f5c0858..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/evaluation.tex +++ /dev/null @@ -1,36 +0,0 @@ -\chapter{Evaluation} -\label{chap:evaluation} - -Since our simulation platform is a distributed solution, in this chapter we are going to evaluate the behavior and status of the web server at different levels of stress, i.e. at different amount of connected users. As the users need to pass through several steps before they are able to start visualization of their simulation, the web server experiences different type of stress. - -The first stage for using our simulation platform is always the login phase, at which each new user has to authenticate. At this point the web server does not require many resources, since user login is handled by using database transactions for credentials verification and no additional computations. Messaging at this point is also not under high load, since no specific user request are sent and no large messages are sent back to the client. - -As we can see on Figure \ref{fig:performance1}, in the login phase the web server uses just several hundred megabytes, which are enough for keeping the system running and serving requests. After users start selecting simulation scenarios, the amount of resources necessary to process the simulations, to provide the virtual world as well as to store the buffer data increases non-linearly, depending on the scenario complexity, i.e. the amount of tracks included in the scenario and the number of currently active rooms. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{src/pic/imgs/screenshots/Performance-1.png} - \caption{Server resource usage at login phase} - \label{fig:performance1} -\end{figure} - -SmartFox server keeps a slightly more memory allocated than the actually used memory, in order to provide a buffer for its processes. The allocated by the server memory is always restricted by the systems capacity, i.e. depending on the hardware of the server machine. In our example we are using a machine with 8GB of RAM and 2.60GHz processor allowing for 4 main threads to run concurrently on the system. And at the stage of running several concurrent simulation scenarios in 2 different rooms (sectors), while more than 40 users are connected to the server, requires 2GB allocated memory as shown on Figure \ref{fig:performance2}, which is 25\% of the system memory. At this point the CPU usage is maximized, due to all the computations necessary to process the simulation scenarios. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{src/pic/imgs/screenshots/Performance-2.png} - \caption{Server resource usage at simulation phase} - \label{fig:performance2} -\end{figure} - -As we can also see, memory usage reaches its peak when the users have selected their scenarios and all the necessary rooms and buffers for handling the simulations are created. Whenever the web server is doing calculations for a single sector, i.e. in a single room, due to the fact that only one simulation will process all the scenarios, the resource usage does not increase further. Creating buffers for user simulation does not seem to require too much memory, and is also a configurable behavior, due to the capacity restriction of simulation buffers set in the server's configuration. Nevertheless, creating more and more rooms, which have their own simulator instances, increases the resource usage a lot. This is due to the fact that each room also keeps its sector map data loaded in memory, and a single sector can contain many map objects. - -Another aspect of the server performance is the network traffic. As we can see on Figure \ref{fig:performance2}, the size of the messages sent from the server to the client are way more, than the size of the messages sent in the opposite direction. This is due to the fact that the server mostly receives user requests containing simple command names and eventually simple parameters, but the server responses normally contain data about scenarios and their tracks, virtual world data or frame data. While comparing user requests and internal messaging on Figure \ref{fig:traffic}, we can notice that the main system threads are almost not loaded at all, since they are used only for internal messaging, thus the main network load falls onto the extensions and their handlers on zone and room levels. We must also emphasize, that the outgoing messages graph does not consider WebSocket connections, thus it shows a very little traffic activity. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{src/pic/imgs/screenshots/Messaging.png} - \caption{Server messaging traffic} - \label{fig:traffic} -\end{figure} - -As we are using the regular free SmartFox version, our simulation platform is restricted to handle up to 100 concurrent users. As we already discussed, concurrent user connections does not cause much load on the server, but keeping many rooms active, thus loading many sectors in memory and running different simulation instances in each sector makes the server experience a huge load. CPU usage seems not to be a problem, since the server schedules and manages its threads, but memory usage is very high due to the large amount of world objects loaded in memory for each sector. - -Running many concurrent users in a single sector slows down the simulation, but guarantees that no resource issues will occur. As keeping many rooms active leads to high memory usage, sector size has to be adjusted accordingly. The less sectors are active, the less map objects will be loaded in the memory, but if sectors are too big, room creation will require a bigger portion of memory to be allocated at once. Keeping a good balance between sector size and number of active sectors will allow for robust server functioning. Distributing rooms to different server machines can solve the problem, but will require those rooms to be statically created, thus always active and ready to serve user request. \ No newline at end of file diff --git a/docs/Thesis/src/tex/futureWork.tex b/docs/Thesis/src/tex/futureWork.tex deleted file mode 100644 index 785d054a50c9e8ed220fb02e8c3e6bd7c9585847..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/futureWork.tex +++ /dev/null @@ -1,29 +0,0 @@ -\chapter{Future Work} - -Our simulation platform is a result of long work on the client and server applications in combination with development of sensors, simulation controllers, simulators and models. During development of all these components of the final system, many concepts have been implemented, but also some ideas did not find place in the simulation platform. In this chapter we are going to explain several new ideas, which are about to become a part of the simulation platform. - -\section{Single simulation per vehicle} - -As we already explained, our simulation platform works by splitting the virtual world on sectors. For each sector, a separate simulator is assigned and manages all the vehicles, which have to be simulated in the sector. This means that when the simulator executes, calculations over the whole virtual world as well as all the vehicles have to be made, in order to produce simulation frames. - -As we saw in chapter \ref{chap:evaluation}, maintaining the virtual world is the most memory consuming activity, followed by simulation buffers. By borrowing an approach from game development, we consider that decoupling further the simulation can bring more advantages and even more flexibility in the whole platform. The new idea, we want to apply in future, is based on the \textit{area of interest}, which we already discussed in section \ref{sec:aoi}. - -Instead of using one simulator, handling all the vehicles in a single sector, we want to run single simulator for each vehicle. Of course we will preserve the world structure, i.e. using sectors, as well as some simulator working on the territory of a whole sector, but the main vehicle simulation, has to be done by a single module and only for a single vehicle. In order to achieve this goal, an area of interest has to be defined for each vehicle, additionally a new simulator instance has to be created for each vehicle and take as input only the rough trajectory of the track, which the vehicle is supposed to follow. Once a simulator for a single vehicle is started, it will compute a precise trajectory and new simulation frames only for its own vehicle, and will operate in an area, including the close virtual world around the rough trajectory only. This small area can be fetched directly from the database, by which keeping a whole sector in memory might become unnecessary condition. This will greatly reduce the amount of data involved in simulation computation, as well as the number of vehicles, since only one will be handle per simulator instance. Since only one vehicle is involved in this simulation, the physics engine has to compute less data and therefore execute faster. - -As vehicles can enter area of interest of other vehicles, synchronization between the simulators handling the interacting vehicles has to be implemented. Using events for notifying simulators, that an external vehicle is entering the area of interest, can ease the problem with vehicles interaction. Additionally if vehicles are getting too close to each other, the controller modules of each vehicle have to react and decide whether changes have to be applied to the simulations, in order to avoid collisions. Whenever an external vehicle enters the area of interest of another vehicle, both vehicle simulators have to synchronize each other about the positions of the vehicles and include this data to their own frame data, which will be used later by the visualization application. - -The simulator(s) operating over the whole sector are commonly used for communication between vehicles, thus they have to be able to receive data from all the vehicles running currently in the sector, but should not require virtual world data, in order to reduce the memory consumption. Rather they have to respond to vehicle messages and give information, which may or may not be considered by the vehicle's simulator, depending on the case. - -The visualization has to be changed slightly, in order to apply the new decoupled simulation approach. The world data has to be built dynamically for each frame, depending on the current position of the area of interest, which changes with the movement of the vehicle. Changing viewpoint to other vehicles will not be possible for normal users, but can be allowed for spectators, i.e. users that do not request simulations, but are allowed to observe simulations running in a single sector. - -Applying such approach based on area of interest can decrease memory consumption, due to the restricted amount of virtual world objects, that have to be provided for each simulation, which in the worst case will be the whole sector map. Additionally single simulators will execute much faster, due to the fact that they operate only with one single vehicle. In the worst case, a single simulator has to consider other vehicles, only if they are in its area of interest and are too close to the simulated vehicle. In such cases the controller module is supposed to support the simulator by estimating the situation and giving suggestions for simulation changes, in order to avoid collisions. Global simulators can gather information from all the simulated vehicles in a single sector and provide result data, for example for traffic jams, repair works, blocked streets, etc. This decoupling will reduce greatly memory consumption, but also increase the performance of single tasks, due to the decreased amount of input data, that has to be processed. - -\section{Online model development, test and deployment} - -The chair of software engineering at RWTH-Aachen University develops a modeling language, described in details in \cite{BKRW17a}, and has also developed an Online IDE \footnote{Integrated Development Environment}, allowing for development of new models in a web application. Since each new model has to be tested and since the IDE is used online, a solution allowing online testing has to be provided too. However, executing new models directly on our simulation platform requires also deployment of the new models as well as their adaptation to the simulation platform, in order to preserve correct behavior. Therefore a new idea has to be developed to ease the entire development process, i.e. to allow easy transition from development phase to test phase and deployment. - -Since the online IDE is already deployed and working, test integration has to be provided, allowing for online simulation tests. As a solution, a simple server application can be used, on which the new model is deployed together with adapters to be used by the SimulationController and a single simulation scenario. The simple server then can execute the scenario in order to test the newly provided model. Each time a new model is created and a test is required, a new simple server instance is started to run the test simulation. After successful model test, the simple server has to be stopped, and the model together with the adapters used by the SimulationController as well as the updated SimulationController code has to be submitted to the version control system and then deployed on the general simulation platform. As the platform supports hot deployment, no restart will be necessary to apply the new changes on both client and server applications. - -Another solution can be applying translation of the model into JavaScript code, which can be used as a simulation of a test server application, providing the necessary frame data to the visualization application directly. As it seems to be more reasonable to translate the model implementation into JavaScript, since the visualization application as well as the online IDE are both web based, this will also require large amount of modules such as sensors, controllers, etc. to be translated also into JavaScript. This task might turn to be way too complex for implementation, due to the differences between JavaScript and Java or C++ languages, which used for development of the modules we mentioned above. - -However, the whole idea is really fresh and many discussions are required for gathering solution concepts. In this section we emphasize on the concepts we have currently gathered and need to be discussed further, in order to exploit any advantages or disadvantages of these approaches. \ No newline at end of file diff --git a/docs/Thesis/src/tex/introduction.tex b/docs/Thesis/src/tex/introduction.tex deleted file mode 100755 index b56f9b57a20d6ba7fd6121a246336c46adf94aea..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/introduction.tex +++ /dev/null @@ -1,55 +0,0 @@ -\chapter{Introduction} - -Autonomous driving vehicles require a large amount of implemented features and concepts to be adjusted to work together. Many challenges for building prototypes of such vehicles have already taken place all over the world. Such challenges require teams of experts to develop, test, analyze and prepare their prototypes to meet specific requirements. As an example of the challenges and problems, that experts had to go through in development of a prototype of autonomous driving vehicle for \textit{2007 DARPA challenge} can be seen in \cite{DBLP:journals/corr/0001R14a}. Details of concrete implementation of such a prototype vehicle can be found in \cite{DBLP:journals/jfr/UrmsonABBBCDDGGGHHHKKLMMPPRRSSSSSWWZBBDLNSZSTDF08}, where the winner team of the challenge, \textit{Boss}, explains more about the work its members had to do, the problems they had to solve and the details about the implementation and adjustment of the prototype. One can also take a look at the details of the best non-US team in the challenge, \textit{Caroline}, \cite{DBLP:journals/jfr/RauskolbBLMCEFGOSWHNDHMWBBGKR08}. - -Autonomous driving vehicles are considered the future of transport, therefore large amount of scientific works and industrial efforts is put into solving the problems, that this idea brings with itself. Some of the problems are solvable by using appropriate hardware sensors and applying fast algorithms for data mining and processing. However, testing prototypes in real world consumes more time and is more expensive than \textit{virtual world simulation}. - -It is clear that building a prototype vehicle requires more or less a big team of experts, great dedication, long time for development, implementation and adjustment, and last but not least, the cost for it is high, due to necessity of large amount of hardware components. Software simulators however, have proven to be an efficient tool for easing tests execution, gathering statistical data and running analysis for projects and concepts of almost any scientific field. Theories and concepts, especially applicable in industry, require testing and analysis of many components and meeting harsh requirements for safety, performance, etc. These obstacles are often eased by software simulators, developed in a specific way, depending on tasks requirements. This means that software simulators for the same concept, might differ greatly, because their main goal is to ease performing a task referring to specific aspect of the problem, that has to be solved. - -Since different concepts have many different aspects, that have to be considered, tested and analyzed, developed software simulators differ in architecture, implementation, etc. Most of the simulators are developed as a single application, which means that the user has to install the software, in order to be able to use it. Normally such applications come with a big database holding vehicles, environment and other objects model details, as well as implemented logic for running and configuring simulations. The result of simulation can be in text or video format, meanwhile also visible via the software application. - -Classic solutions for simulators normally include a single application, which has to be installed on client's machine with all of its dependencies. Such simulators brings all the data for building virtual environment, i.e. map and terrain data, static objects as traffic signs, buildings, trees, etc. as well as dynamic objects as vehicles, pedestrians and even additional data for weather, day-time and so on. Such application can be reviewed in \cite{DBLP:journals/aes/AmbrozKP05}. It allows users to prepare in great details simulation scenarios, to apply analyses on simulation's result data as well as to perform 2D or 3D visualization of the simulation. Additional module is included to export result statistical or video data. This structure based on heavy modules, that bring significant amount of precise logic, allows such a simulation application to provide very good and detailed simulation results. However, a downside of this approach is the static data available on client's machine, in other words, the possibility that the models for vehicles, pedestrians and even simulation logic is outdated. Whenever a module is outdated or needs to be replaced by another module, which executes different calculation tasks, additional packages have to be imported and adjusted to work with the application. Of course releasing updates for the application can solve the problem. - -Another approach for automotive simulators can be borrowed from computer game development and especially multiplayer games. Since more and more types of digital devices are getting produced and are able to connect to Internet, along with the evolution of web technologies and web browsers, a combined solution based on gaming over Internet seems to be a suitable way of developing a scalable software simulator. - -Modern software application are normally based on distributed approach. On one hand this technique eases the use of client application as well as providing dynamic updates, which do not requires any additional user actions, and on the other hand users can share knowledge with each other. Distributed simulators are not an exception and as an example one can point out \textit{CyberWalk} (\cite{DBLP:conf/vrst/NgSLL02}) - a web platform allowing simulation of geographical data in a virtual world as well as sharing geographical location between users. Although it simulates only static environment data, it provides up-to-date map data and allow users to share additional information about geo-locations. - -If we take a look of \textit{massive multiplayer online gaming} approaches, we can borrow architectural styles and ideas, that can help building a distributed simulator. Multiplayer gaming has two main architecture type approaches for handling simultaneously many players and keeping game state consistent - \textit{client/server} and \textit{peer-to-peer} (P2P) architectures. As an example of a solution for MMOG using peer-to-peer architecture, we can point out \cite{DBLP:conf/infocom/2004}. - -Since P2P architectures require additional game state synchronization, in the example we cited above, a distribution algorithm is used, in order to split players into groups, depending on their location in the virtual world. This eases the communication between players, by synchronizing game state only between players in the same group. In other words, players in one group synchronize group game state (objects) between each other and do not communicate changes to players in other groups. When players in one group interact with each other, for example by trading, they synchronize only themselves and do not multicast updates to other players in the same group. For static objects coordinators are assigned inside each group and they also communicate changes for objects concerning more than a single group of players, which provides synchronization between groups. When a player switches a group, he starts multicasting updates only to members of the new group, as well as receiving updates from the new group and eventually coordinators. Distribution of coordinators, which are to keep the state of certain objects, is done dynamically and does not depend on players' choice. A visual representation of player-groups, synchronization and multicast updates is shown on Figure \ref{fig:Multicast}. - -\begin{figure}[h] - \centering - \includegraphics[width=.9\textwidth]{gen/P2PMulticast.pdf} - \caption{Player grouping and update multicasting} - \label{fig:Multicast} -\end{figure} - -The motivation for this master thesis and our main goal, is to provide a distributed multi-user simulation platform, which has a well scalable and easily changeable architecture for simulation of large amount of vehicles dynamically added to an existing virtual world, thus allowing testing a bigger scope of potential problems that might occur when autonomous driving vehicles are used in real world. - -Additionally, borrowing ideas from multiplayer game development, allowing users to communicate and interact within a platform, can cause unexpected event to occur, due to interaction between simulated vehicles by different simulations, whenever several simultaneously running simulation scenarios are executed. This situations add a new challenge for us, whose solution on a later phase can bring our simulation to a level of handling environmental dynamic objects, simulated by algorithms for \textit{artificial intelligence}. This can allow simulation scenarios to be executed in a populated by AI objects virtual world, allowing a simulation model to operate completely by itself, thus trusting only the data, provided for example by sensors and GPS modules, rather than simulating all the objects and executing calculation for many objects and reducing performance. - -The list of challenges, which have to be solved, in order to allow implementation of our approach as well as bringing all the possible advantages, is as follows: - -\begin{enumerate} - \item Increasing scalability - \begin{itemize} - \item by distributing server on many machines, decreasing machine load and computational power requirements - \item by providing client and server applications, which work together. This removes the requirement for installation of a thick client application and updates, that keep all the necessary data and specific simulation and analysis logic - \item due to the widely spread support of web-based application on different devices, as PCs and mobile devices - \item by using the plug-in approach, allowing additional simulators to be run along with the main simulation on the server. Simple update and restart of the server will allow all the users to be able to use the new simulators, without installing or updating anything on their devices - \end{itemize} - \item Increasing usability - \begin{itemize} - \item by providing web-based client application with user-friendly interface - \item due to web-integrated 3D visualization in real-time shared among all users virtual environment - \item by allowing execution of complex simulation scenarios - \item by allowing users to interact with each other, which may bring unpredicted events to occur and therefore enhance the level of quality required to be met by implemented sensors and algorithms included in the simulators - \end{itemize} - \item Increasing reliability - by using data storage on server side and synchronization between server instances, in order to provide high-level consistency of simulations in simulated virtual world - \item Increasing adaptability - by extending simulation platform with additional simulators or extending client application, and providing easy deployment -\end{enumerate} - -In order to develop and implement the solution for simulation platform, ideas have to be borrowed from massive multiplayer online games development, as well as additional simulator specific algorithms, data optimization, communication protocols and synchronization approaches. In the next chapters we give a detailed explanation about the concepts and mechanisms implemented in our solution. - -In this thesis we explain what techniques, approaches and mechanisms we have used in developing our simulation platform, allowing us to add additional simulators, to keep virtual environment ready for user-defined simulations and to support execution of multiple simulations simultaneously. \ No newline at end of file diff --git a/docs/Thesis/src/tex/literature.tex b/docs/Thesis/src/tex/literature.tex deleted file mode 100644 index 948eaeb0f02dd32a88e426a5a133aa54b454a810..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/literature.tex +++ /dev/null @@ -1,66 +0,0 @@ -\chapter{Literature for citation} - -\begin{enumerate} - \item \textbf{CITED} DBLP:journals/aes/AmbrozKP05 - An application for fine adjustment of a single scenario vehicle simulation including configuration of the vehicle as well as its driver (human body detailed configuration). After adjusting simulation configurations, a 3D animation is visualized allowing for dynamic addition of object from user side and even allowing user to control a vehicle. Additional the animation can be exported as a video file, or such a file can be loaded by the application, and visualized in its visualization module. The main goal of the simulator is to fetch statistical data and make specific analysis over it. - - \item \textbf{CITED} DBLP:journals/corr/0001R14a - details over engineering of a software for autonomous driving car, used in 2007 DARPA urban challenge. - \item \textbf{CITED} DBLP:journals/jfr/RauskolbBLMCEFGOSWHNDHMWBBGKR08 - The prototype autonomous driving vehicle called Caroline, one of the finalist in 2007 DARPA urban challenge. - \item \textbf{CITED} DBLP:journals/jfr/UrmsonABBBCDDGGGHHHKKLMMPPRRSSSSSWWZBBDLNSZSTDF08 - the winner autonomous driving vehicle in 2007 DARPA urban challenge. - - - - \item \textbf{CITED} fowler2003patterns - Enterprise architecture design patterns - concurrency, distributed systems, etc. - \item \textbf{CITED} gamma1995design - Object-oriented design patterns - creational, structural and behavioural - - - \item \textbf{CITED} SFS - SmartfoxServer documentation... - \item \textbf{CITED} fette2011websocket - WebSocket protocol documentation... - - \item \textbf{CITED} DBLP:conf/vrst/NgSLL02 - CyberWalk: a distributed virtual street-view system for sharing and viewing geographical location data based on Zoning principle (i.e. the virtual world is split in regions, each one handled by a separate server) - \item \textbf{CITED} Cronin01adistributed - A mirror-server architecture with trailing state synchronization protocol and low-latency reliable multi-cast protocol for multiplayer games (Quake), allowing near-perfect consistent, low-latency multiplayer gaming. - - \item \textbf{CITED} DAfMMO-RPG - a centralized distributed architecture for MMO (Zoning approach) - \item \textbf{CITED} DBLP:conf/gi/MullerG04 - A proxy-server architecture for RTS and FPS multiplayer games - a client/server (outer) to peer-to-peer (inner) architecture based on mirroring approach (replicating servers, which update states among the other servers in the peer-to-peer network). Clients connect to a server using client/server architecture. - - \item \textbf{CITED} DBLP:conf/icmcs/GautierD98 - MiMaze: a distributed multiplayer game using multicast communication system based on UDP to guarantee the consistency of the game state - - \item \textbf{CITED} DBLP:conf/netgames/KimCCKCY05 - analysis of network traffic made using Lineage II. Analyzing package size difference between server and client packages, latency due to delayed TCP acknowledgment and relationship between number of users and latency. - \item \textbf{CITED} DBLP:journals/cn/LeeKC05 - a Zoom-in-zoom-out algorithm for server selection and minimization of distance/delay between users in handled by different servers. - \item \textbf{CITED} Caltagirone:2002:AMM:771322.771339 - detailed explanation of a client/server architecture for MMO based on publish/subscribe and MVC model - - \item \textbf{CITED} DBLP:books/lib/TanenbaumW11 - Computer networks (network layers, topologies, n-tier architectures, etc.) - \item \textbf{CITED} TaylorEtAl2007 - Software architectures book - \item \textbf{CITED} Cozzi15 - WebGL Insights book - \item \textbf{CITED} dirksen2014three - ThreeJS Essentials - guide book for ThreeJS - - \item \textbf{CITED} DBLP:books/daglib/0067388 - Dijkstra's Separation of concern - \item \textbf{CITED} walls2015spring - "Spring in Action" - spring framework, spring mvc, REST, etc. - - \item \textbf{CITED} Jetty - Jetty web-server documentation/announcement - \item \textbf{CITED} PGSQL - PostgreSQL official website - - \item \textbf{CITED} DBLP:conf/infocom/2004 - a peer-to-peer architecture based approach for MMO games, allowing for dynamical distribution of the game state in order to keep consistency of the game state. - - \item \textbf{CITED} DBLP:conf/netgames/FiedlerWW02 - an approach for communication architecture based on publisher/subscriber, by splitting map on regions, and providing environment and interaction data in distinguished channels, for which a player subscribe, depending of its needs. - \item \textbf{CITED} DBLP:reference/cg/Fortune04 - Voronoi and Delauny triangulations - - \item \textbf{CITED} DBLP:conf/ijcai/DresnerS07 - A simulator for solving intersection problems in autonomous driving introducing space occupation requests and a FCFS light model combined with off-limit tiles for reducing the probability of accident between a human-driven vehicle and autonomous one - \item \textbf{CITED} DBLP:journals/tits/GlaserVMGN10 - A simulator algorithm for trajectory planning of an autonomous driving vehicles on highways, executing 2 steps - in order to determine the feasible maneuvers necessary to overtake an obstacle with minimized collision risk and to optimize the trajectory with respect to additional factors as comfort, consumption and speed. - - \item \textbf{CITED} puntambekar2009data - Data Structures And Algorithms (Dijkstra algorithm in here) - \item \textbf{CITED} DBLP:books/daglib/0021734 - Algorithms in Nutshell (Floyd-Warshall) - - \item \textbf{CITED} DBLP:books/daglib/0002204 - programming with Java and JDBC, connection pooling, etc. - - - - \item DBLP:conf/netgames/FritschRS05 - Evaluation of latency in different situations as Movement and Combat, Group Combat or Movement/Environment in Everquest2 (IN EVALUATION CHAPTER) - - - - -\end{enumerate} - - - -\cleardoublepage \ No newline at end of file diff --git a/docs/Thesis/src/tex/motivation.tex b/docs/Thesis/src/tex/motivation.tex deleted file mode 100644 index 1cb80459db512f5364bbbebd233c172d5120356a..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/motivation.tex +++ /dev/null @@ -1,28 +0,0 @@ -\chapter{Motivation} - -Autonomous driving vehicles are considered the future of transport, therefore large amount of scientific works and industrial efforts is put into solving the problems this idea brings with itself. Some of the problems are solvable by using appropriate hardware sensors and applying fast algorithms for data mining and processing. However, testing prototypes in real world consumes more time and is more expensive than \textit{virtual world simulation}. - -The motivation for this master thesis and our main goal, is to provide a distributed multi-user simulation platform, in order to provide a well scalable and easily changeable architecture for simulation of large amount of vehicles dynamically added to an existing virtual world in order to allow testing a bigger scope of potential problems that might occur when autonomous driving vehicles are used in real world. - -The list of issues, which have to be solved, in order to allow implementation of our approach as well as bringing all the possible advantages, is as follows: - -\begin{enumerate} - \item Increasing scalability - \begin{itemize} - \item by distributing server on many machines, decreasing machine load and computational power requirements - \item by providing client and server applications, which work together. This removes the requirement for installation of a thick client application (and updates), that keeps all the necessary data and specific simulation and analysis logic - \item due to the widely spread support of web-based application on different devices (PCs and mobile devices) - \item by using specific simulator plug-in approach, allows additional simulators to be run along with the main simulation by the server. Simple update and restart of the server will allow all the users to be able to use the new simulators, without installing or updating anything on their devices - \end{itemize} - \item Increasing usability - \begin{itemize} - \item by providing web-based client application with user-friendly interface - \item due to web-integrated 3D visualization in real-time shared among all users virtual environment - \item by allowing execution of complex simulation scenarios - \item by allowing users to interact with each other (intentionally or unintentionally), which may bring unpredicted events to occur and therefore enhance the level of quality required to be met by implemented sensors and algorithms in included simulators - \end{itemize} - \item Increasing reliability - by using data storage on server side and synchronization between servers (virtual or real), in order to provide high-level consistency of simulations in simulated virtual world - \item Increasing adaptability - by extending simulation platform (e.g. additional simulators or extending client application) and providing easy deployment -\end{enumerate} - -In order to develop and implement the solution for simulation platform, ideas have to be borrowed from \textit{massive multiplayer online games} development, as well as additional simulator specific algorithms, data optimization, communication protocols and synchronization approaches. In the next chapters we give a detailed explanation about the concepts and mechanisms implemented in our solution. \ No newline at end of file diff --git a/docs/Thesis/src/tex/relatedWork.tex b/docs/Thesis/src/tex/relatedWork.tex deleted file mode 100644 index 2d1d44e7e8f742ec2453677275de41aabd6135c3..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/relatedWork.tex +++ /dev/null @@ -1,17 +0,0 @@ -\chapter{Related Work} -\label{chap:relatedWork} - -Classic solutions for simulators normally include a single application, which has to be installed on client's machine with all of its dependencies. Such simulators brings all the data for building virtual environment (map and/or terrain data), static objects (traffic signs, buildings, trees, etc.) and dynamic object (vehicles, pedestrians, etc.) and even additional data for weather, day-time and so on. Such application can be reviewed in \cite{DBLP:journals/aes/AmbrozKP05}. It allows users to prepare in great details simulation scenarios, apply analyses on result data from execution of simulations as well as 2D or 3D visualization of configured simulation. Additional module is included to export result data (statistical data or video files). However, a downside of this approach is the static data available on client's machine, in other words, the outdated models for vehicles, pedestrians and even simulation logic. Of course releasing updates for the application can solve the problem. - -Modern software application are normally based on distributed approach. On one hand this technique eases the use of client application as well as providing dynamic updates, which do not request any additional user actions, and on the other hand users can share knowledge with each other. Distributed simulators are not an exception and as an example one can point out online geographical location map viewers (for example \cite{DBLP:conf/vrst/NgSLL02}). Although they simulate only static environment data, they provide up-to-date map data and allow users to share additional information about geo-locations. - -Since our simulation platform solution includes concepts from \textit{massive multiplayer online games} (MMOG), we have to mention the differences and problems, multiplayer gaming introduces. Multiplayer gaming has two main architecture type approaches for handling simultaneously many players and keeping game state consistent - \textit{client/server} and \textit{peer-to-peer} (P2P) architectures. As an example of a solution for MMOG using peer-to-peer architecture, we can point out \cite{DBLP:conf/infocom/2004}. - -Since P2P architectures require additional game state synchronization, in the example we cited above, a distribution algorithm is used, in order to split players into groups, depending on their location in the virtual world. This ease the communication between players, by synchronizing game state only between players in the same group. In other words, players in one group synchronize group game state (objects) between each other and do not communicate changes (multicast update messages) to players in other groups. When players in one group interact with each other (e.g. trading), they synchronize only themselves and do not multicast updates to other players in the same group. For static objects coordinators are assigned inside each group and they also communicate changes for objects concerning more than a single group (region), which provides synchronization between groups. When a player switches groups, he starts multicasting updates to members from the new group only, as well as receiving updates from the new group and coordinators. Distribution of coordinators, keeping state of specific amount of objects, is done by dynamically and is not selectable by players. A visual representation of player-groups, synchronization and multicast updates is shown on Figure \ref{fig:Multicast}. - -\begin{figure}[h] - \centering - \includegraphics[width=.9\textwidth]{gen/P2PMulticast.pdf} - \caption{Player grouping and updates multicasting} - \label{fig:Multicast} -\end{figure} \ No newline at end of file diff --git a/docs/Thesis/src/tex/simulationPlatform.tex b/docs/Thesis/src/tex/simulationPlatform.tex deleted file mode 100644 index 64068b7ea1f6d3f47d965a20b682164e345cb2c3..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/simulationPlatform.tex +++ /dev/null @@ -1,1027 +0,0 @@ -\chapter{Simulation Platform} -\label{chap:simulationPlatform} - -In this chapter we discuss in details the main topic of this master thesis. We explain the overall structure and work-flow of the platform as well as details about different aspects of it. We also point out the challenges we had to cope with and discuss in details their solutions. - -\section{Challenges} - -Constantly running simulation platform seems to consume quite large amount of resources, due to the size of the virtual world, that is about to be handled. Although distributing the server code to several machines can reduce the number of users per server, by applying the sharding or instancing technique, it can also increase the need of extra synchronization and thus the size of the bandwidth, due to increased amount of synchronization messages. In section \ref{sec:VirtualWorld} we discuss how we deal with the problem, what approach is our solution based on and what additional techniques we apply in order to reduce the resource consumption of the server. - -Distributing simulation requires additional synchronization, in order to allow smooth execution and good user experience. Since our platform make great use of splitting the virtual world in many sectors, each of which handles its own local simulation and a number of simulated objects, transferring a vehicle from one sector to another requires additional care. In section \ref{sec:Simulation} we go in details about our simulation approach, how we execute simulations, how we handle local events and how we synchronize neighbor sectors, whenever a vehicle transfer is required. - -As we already mentioned that our simulation platform keeps a huge virtual world ready to server user requests, another problem connected with vehicle trajectory and path finding arises. In section \ref{sec:PathFinder} we discuss in details how we achieve fast and yet correct path finding result in a considerably large virtual world data. - -Working with big data files and serving user queries requires well structured and defined procedure for retrieving and saving data in a database. Considering that connections between web server and database server are limited and come with a cost, we need to optimize the communication between both servers in such a way, that preserves the level of used database connections low, achieves high performance of writing and reading to/from the database. How we achieve high performance and how we transfer the data to the end-user, we discuss in section \ref{sec:WebCommunication}. - -Last but not least, security, in terms of user management and communication, as well as versatility of the server configuration, are discussed in the last sections of this chapter. - - -\section{Architecture} - -Since one part of the client is web-based application, our platform is based on the \textit{Three-tier architecture} style (\cite{DBLP:books/lib/TanenbaumW11}), including client layer, responsible for 3D visualization, web server implementing the business logic and management and database server, responsible for data storage. Space for extension is provided for additional proxy layer, in case that the platform needs to be spread among different server machines on different location. - -In order to preserve versatility of the business logic, client/server architecture (\cite{TaylorEtAl2007}) is preferred, due to its ability to ease altering of the business logic implemented on the web server. This means that every user will have to request one server machine, but will not need to keep connections to other users nor be responsible for preserving simulation state. Since a single server is considered a \textit{single point of failure}, distributing the platform to different machines decreases the probability of a failure, affecting all users connected to the platform. - -In addition to client/server architecture we do not use sharding or mirroring techniques, in order to decrease server load. We consider that the root of this problem is the size of the virtual world, handled by the server. Therefore our approach makes great use of zoning approach, which we discuss in later section. - -The platform also makes great use of \textit{Model-View-Controller} pattern, which we apply on the highest abstraction level, i.e. our client application represents the view, our web services represent the controller and our database represents the model. - -Another aspect of the architecture is dependent on \textit{SmartFoxServer} development kit. It influences especially the \textit{business tier} of our architecture, by introducing zone and room concepts, each of which has its own independent class loaders, allowing for extension plug-in in run time as well as distributing zones and rooms on different machines. Although rooms may be in the same scope as their parent zone, i.e. on the same web server, due to different class loaders, communication between rooms and their parent zone is done only via internal (for SmartFoxServer) messaging. - -Although our architecture is based on the Three tier architecture style, our business tier can be distributed on many machines whenever necessary, and consists of zone and/or rooms, both of which handle user requests within their scope. A single zone represents an instance of a whole virtual world, but does not provide virtual world data and therefore keeps the memory consumption low. A zone does not provide to its users direct access to the virtual world, rather each sector of the virtual world is loaded and managed by its own room. Each of those rooms is created and removed dynamically, whenever needed, by the zone, to which a client is connected. This means also that a user cannot connect directly to a room, rather it has to be authorized first by a zone and then redirected to specific room, which will handle user's simulation. We discuss the work-flow of the platform as well as how the virtual world is split in the next sections. - -An overview of our architecture as well as the main work-flow of the platform is shown on Figure \ref{fig:Overview}. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/Overview.pdf} - \caption{Architecture overview} - \label{fig:Overview} -\end{figure} - -\section{Basic work-flow} -\label{sec:WorkFlow} - -Our simulation platform, since consisting of server and client applications, has to initialize the server application first, after which the web based application can be served and available for any user. The initialization process is important not only because of preparing server resources to be served, but also for preparing the server application in means of loading configuration, necessary for world data processing and preparing communication endpoints. - -As a web based simulation platform, we need to provide a standard procedure of authorization and usage of the platform. Therefore, a client is allowed to use our simulation platform, only after successful connection is established to the server. After connecting to the server, a client have to login with, in order to be allowed to use further services. If client is not yet registered, he is allowed to login as a guest user, in such case the SmartFoxServer will generate a temporal account and authenticate the user. After authentication, the client application has successfully established a dedicated connection with the server. - -Next step is selecting an existing simulation scenario as well as initial vehicle, which the client wants to follow during the simulation. We provide also an option for uploading a new scenario, described by an OpenStreetMap \textit{xml} and \textit{sim} files - the first contains a piece of map, contained in our virtual world, and the second is a simulation configuration of weather, pedestrians, vehicles and so on. On Figure \ref{fig:GuiMenu} the client's application menu for these steps is shown. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{src/pic/imgs/screenshots/scenario-menu.png} - \caption{Selecting simulation scenario} - \label{fig:GuiMenu} -\end{figure} - -Whenever a scenario is selected, simulation is registered on the server and the sector's simulator starts to compute frame data including selected scenario. On the client application, an event is received, giving the information about the sector, to which the client is now connected. From this moment until the end of simulation or canceling the simulation by the user, all request to from client to server are handled by the sector, to which the client is currently connected. The sector's virtual world data is received automatically and built immediately after receiving. The user is notified that his simulation is processing and has to wait until the server sends a message, informing the user that its simulation is processed, as well as how much time has been necessary for the server simulator to process the requested simulation scenario. Example of receiving message upon simulation completion is shown on Figure \ref{fig:SimDurationGui}. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{src/pic/imgs/screenshots/play-scenario.png} - \caption{Notification for processed scenario simulation} - \label{fig:SimDurationGui} -\end{figure} - -Upon clicking on \textit{play} button, the user's vehicle is visualized and then simulation visualization is played frame by frame, until user's vehicle reaches its final destination or the user decides to terminate the visualization. During visualization, the user is allowed to switch its view perspective, by selecting a vehicle, from the \textit{vehicle menu}, which is similar to the menu for selecting simulation scenario. The vehicles listed in this menu are all the simulated vehicles, currently located in the same sector as the one the user is connected to. How a concrete visualization looks like is shown on Figure \ref{fig:SwitchCar}. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{src/pic/imgs/screenshots/SwitchCar.png} - \caption{Visualization of simulation scenario} - \label{fig:SwitchCar} -\end{figure} - -At any point of time, the client is able to go back to scenario menu and run another simulation, as well as using \textit{hot-keys} to change camera, observe vehicle by several viewpoints, etc. - -In the next subsections we discuss in details how exactly this work-flow is implemented and what happens on server-side application on each step, the user takes, while selecting and running a simulation. - -\subsection{Zone level} - -As we already explained, the zone is an instance of a virtual world, thus has the highest scope of access and management over user actions. Although on this level, no virtual world data is loaded and transmitted to users, there are several steps each zone goes through, whenever it is initializing. - -\begin{enumerate} - \item As a first step of initializing process of a zone, a configuration file containing details for world map, rules for memory consumption optimization, etc is loaded. - \item Whenever the configuration is changed and there is no world data for specified map name in the database, the virtual world has to be prepared. This happens by splitting it in sectors and saving world data for each sector in the database, for faster later access. - \item Since path-finding algorithms are not adjusted to work in distributed graph, we do additional pre-processing, allowing us in later stage to determine the trajectory for uploaded scenario. -\end{enumerate} - -After initialization, the zone is ready to serve user requests. The following actions are allowed for users, after the connect to the server: -\begin{itemize} - \item Login with or without credentials - \item Requesting list with all available scenarios as well as all vehicles, registered for each scenario. - \item Uploading a new scenario, by providing two files by the user (as mentioned above). - \item Selecting a scenario and initial vehicle to be followed. -\end{itemize} - -The last action triggers several events. First the zone tries to find in which sector the followed vehicle has to be spawned. After that the user is connected to the room, serving this sector. If such a room is not yet initialized, the zone creates it and then assigns the user to it. From this moment on, the simulation as well as each user action, are going to be handled by the room, in which the user has just been joined. - -A zone also listens for internal messages, which can be sent from its own rooms. This mechanism allows simulations to be synchronized, when they go through several sectors. When a room informs a zone for finished simulation, the zone checks whether the simulation, that has been processed, has to continue in another sector (i.e. in another room). If this is the case, the zone joins the user assigned to this simulation to the next room, which is to handle the next part of the simulation. This process may repeat, until all parts of the simulation are played, i.e. the vehicle's final destination is reached. - -A single zone in our simulation platform, according to the SmartFoxServer development kit, i.e. according to the framework \textit{extension points}, has to be implemented as sub-class of \textit{SFSExtenion} class. -\\ -\begin{lstlisting}[language=Java,caption={Framework extension by means of inheritance}] -public class ZoneExt extends SFSExtension { - ... -} -\end{lstlisting} - -This allows us to define the initialization process of a zone, which for us is important for preparing logging and database management services, loading configuration, pre-processing world data and registering event listeners and handlers. The implementation of the initializing method is shown in Listing \ref{lst:zoneInit}. -\\ -\begin{lstlisting}[language=Java,caption={Zone initialization method},label={lst:zoneInit}] - @Override - public void init() { - //set up utils - Logger.getInstance().init(this); - ApiManager.getInstance().init(this); - DataAccessUtils.getInstance() - .init(getParentZone().getDBManager()); - trace("Init Zone: Logger, API manager, DataBase"); - //parse configuration, initialize World - try { - initWorld(getConfigProperties()); - } catch (Exception e) { - trace(ExtensionLogLevel.ERROR, - "Failed to initialize the world: " + e); - } - - //initialize Business logic objects - this.scenarioBo = new ScenarioBO(); - - //handle custom login - addEventHandler(SFSEventType.USER_LOGIN, LoginHandler.class); - - addEventListener(SFSEventType.FILE_UPLOAD, this); - } -\end{lstlisting} - -As we can see, and as we already mentioned, the world initialization is done in the zone extension. In \textit{initWorld} method. In it, after parsing configuration properties, which are loaded from predefined in the admin panel configuration file, the existence of map data in the database is checked. If a map with the given in the configuration name already exists, the information about sectors and their relations is loaded from the database, without any other world data, and with this the world initialization is done. If the given in the configuration map name is not yet present in the database, a \textit{WorldBuilder} service is used to parse OSM map data and save it to the database. After the world details are saved in the database, a \textit{PathFinder} service is used to calculate all the entry/exit nodes for all sectors in the new world map, after which the same service is used to calculate all possible paths between each two nodes in a single sector, with respect to shortest distance between them. This procedure is done for all available sectors in the world map. - -After world initialization and all the necessary pre-procession steps are completed, the zone initialization ends with registering event handlers and listeners, which are about to handle specific server events. Although with different names, both are basically attaching a listener for specific event, differing only in the method signature. - -Extending \textit{SFSExtension} allows our zone class also to handle user requests. A client request is a message sent from a user to the server with command name and parameters. A client request can be sent to a room or zone extension, however, when a room details are not specified, when such a request is sent, it is received on the higher server lever, i.e. the zone level. As shown in Listing \ref{lst:zoneRequests}, on zone level we handle only two client requests - one for returning a list of currently available scenarios for the loaded map, and one for loading a scenario, i.e. requesting simulation of selected scenario. -\\ -\begin{lstlisting}[language=Java,caption={Zone client request handling},label={lst:zoneRequests}] - @Override - public void handleClientRequest(String cmd, - User user, ISFSObject params){ - - if(cmd.equals(GET_SCENARIOS)) { - send(cmd, getScenarios(), user); - }else if(cmd.equals(LOAD_SCENARIO)) { - loadScenario(user, params); - } - } -\end{lstlisting} - -Whenever a scenario is requested, together with the vehicle, which the user wants to follow, the zone extension loads the scenario information from the database and determines in which sector, the vehicle has to be initially spawned. When such a sector is found, the zone checks if there is a created room, handling the sector map, and joins the user to the room. If such room is not yet created, the zone creates it before joining the user to it. The newly joined user has attached properties, allowing the room extension to load the scenario vehicles, which belong to its sector. -\\ -\begin{lstlisting}[language=Java,caption={Scenario loading}, label={lst:scenarioLoad}] - private void loadScenario(User user, ISFSObject params) { - Integer scenarioId = params.getInt("scenarioId"); - Long trackId = params.getLong("trackId"); - - if(scenarioId == null || trackId == null) { - trace(ExtensionLogLevel.WARN, - "Missing simulation scenario/track ID!"); - }else { - List tracks = - this.scenarioBo.getAllTracks(scenarioId); - if(tracks == null) { - trace(ExtensionLogLevel.WARN, - "Simulation scenario does not exist!"); - } - - Room room = null; - List secondaryVehicles = new ArrayList(); - - for(ScenarioTrack track : tracks) { - - NavigationPath startSection = track.getSections().get(0); - room = getRoomToJoin(startSection); - - if(room == null || room.getExtension() == null) { - trace(ExtensionLogLevel.WARN, "Sector does not exist!"); - }else { - if(trackId.equals(track.getId())) { - user.setProperty(RoomExt.TRACK_ID, trackId); - user.setProperty(RoomExt.S_INDEX, 0); - }else { - secondaryVehicles.add(track.getId()); - } - } - } - - if(room != null) { - user.setProperty(RoomExt.SECONDARY_TRACKS, - secondaryVehicles.toArray(new Long[]{})); - joinRoom(user, room); - } - } - } -\end{lstlisting} - -The only server event, except the login, that is handled by the zone extension is the file-upload event, used whenever a user wants to upload a new scenario to the server. How a scenario can be uploaded as well as what it consists of is explained in subsection \ref{ssec:Scenarios}. How the event listener implemented by the zone extension looks like is shown in Listing \ref{lst:fileUploadListener}. -\\ -\begin{lstlisting}[language=Java,caption={Server event handling}, label={lst:fileUploadListener}] - @Override - public void handleServerEvent(ISFSEvent event) throws Exception { - switch(event.getType()) { - case FILE_UPLOAD: - ScenarioUpload.getInstance() - .uploadScenario( - (List) event - .getParameter(SFSEventParam.UPLOAD_FILE_LIST)); - break; - default:; - } - } -\end{lstlisting} - -As we already described in section \ref{sec:WorkFlow}, whenever all the frames for simulated vehicle are visualized, the room, handling the sector, in which the vehicle has been simulated, removes the vehicle and the user, visualizing it, and also notifies the zone extension, that the user simulation is completed in this sector. This procedure is done by using the \textit{internal messaging} between room and zone extensions provided by SmartFoxServer environment. The zone extension then checks whether the user's scenario has to continue in another sector or is completed. If it needs to continue in another sector, the zone joins the user to the next sector, as shown in Listing\ref{lst:zoneInternalMessaging}. -\\ -\begin{lstlisting}[language=Java,caption={Zone internal messaging handling}, label={lst:zoneInternalMessaging}] - @Override - public Object handleInternalMessage(String cmd, Object params) { - - if(cmd.equals(SIM_DONE) && params != null - && params instanceof Integer) { - - int uid = (int) params; - User user = this.getParentZone().getUserById(uid); - - long trackId = (long) user.getProperty(RoomExt.TRACK_ID); - int secIndex = (int) user.getProperty(RoomExt.S_INDEX); - - ScenarioTrack uTrack = this.scenarioBo.getTrack(trackId); - - //transfer to next sector - if(uTrack.getSections().size() > ++secIndex) { - trace("User " + user.getName() - + " is about to be transferred."); - - Room room = getRoomToJoin(uTrack.getSections().get(secIndex)); - //update section index - user.setProperty(RoomExt.S_INDEX, secIndex); - joinRoom(user, room); //join to new room - } - } - - return null; - } -\end{lstlisting} - -\subsection{Room level} - -Whenever a room is created, it runs its initializing process. This is necessary to load configuration, affecting the simulation process. In order to initialize a simulator, the \textit{WorldModel} also has to be initialized, and this happens by fetching all the necessary world data, that is already saved in the database, by the parent zone of the room. In the moment the room is initialized, it is ready to serve user requests, so a global simulator is initialized and started, in order to allow for registering simulation scenarios to be played. - -As we already mentioned, a room is created only dynamically by its parent zone when a user needs to run simulation in the sector, which is about to be served by the room. Each time a user joins a room, an event is triggered and the room sends its world data to the client. Client's scenario is also initialized and all the scenario vehicles, contained in the current sector are registered in the room's simulator. At this point the client application is going to render the virtual world, provided by the server and wait until the simulation is completed and all the frames are stored in a mediator. - -Once the simulation is done, the room sends a notification message to the user and the user can start playing the simulation frame by frame. Each time a frame is requested by the client, the room will fetch the head frame from the mediator for the user's scenario and send it back. Since a room can handle many users, thus many simulations, in the same time, for each scenario a buffer is created, playing the role of so called mediator. So whenever a user request a frame, he is going to receive data, from the buffer assigned to the simulation scenario, requested by the user. This grants the users consistency in running their simulation and decouples the simulation from the visualization process. - -Two users running simulations in the same sector, may visualize the simulation differently, due to the difference of the frame they are currently playing. This can be caused due to delayed execution of the simulation on one of the client's machines, or because client machines have different configuration and processing power, therefore they can process frame data at different speed. - -When users are running simulations in the same sector, they are allowed to switch their view point to follow another vehicle, which may not be included in their own scenario. However, if such a vehicle has to leave the sector, in which it is currently simulated, the users, which have not chosen to follow this vehicle initially, will not be reconnected to another room. Only the user who has requested this scenario will be able to continue following the vehicle through different rooms. - -Finally, whenever user's vehicle has reached its destination, the room serving this scenario simulation unregisters the user's vehicle from the room simulator, and sends a message to the user, that the simulation is completed and now can be visualized. - -When all the simulated frames for a single scenario are visualized, the sector room notifies its parent zone, that the user's simulation is done, and the user is about to be disconnected from the room. The zone extension, as we already explained, takes care of transferring the user to another sector, if user's scenario has to continue. If the user, whose vehicle has been unregistered, is no longer connected to a room, thus its simulation is completed and does not need to proceed in another sector, his further request are going to be served on a zone level. - -If all simulations running in a room have finished and have been visualized, all users assigned to those simulations are no longer connected to the room, therefore the room will prepare for destruction procedure, i.e. it releases all the resources used to handle the room's simulator as well as all the sector map data. Whenever a new user needs to run simulation in the same sector, a new room instance is going to be created. This allows saving resources, due to not keeping idle rooms. - -Similarly to the zones, rooms are also created as child classes of \textit{SFSExtension}. Room initialization in our \textit{RoomExt} class is taking care of loading the world detail for the sector, assigned to the created room object, preparing the simulator as well as registering event listeners and handlers as shown in Listing \ref{lst:roomInit}. -\\ -\begin{lstlisting}[language=Java,caption={Zone internal messaging handling}, label={lst:roomInit}] - @Override - public void init() { - //set up utils - Logger.getInstance().init(this); - ApiManager.getInstance().init(this); - DataAccessUtils.getInstance() - .init(getParentZone().getDBManager()); - trace("Init Room: API manager, Logger, DataBase. Room: " - + getParentRoom().getName()); - - //Load room properties, initialize world and SimulationController - initRoom(getConfigProperties()); - //initialize Business logic objects - this.scenarioBo = new ScenarioBO(); - - addEventListener(SFSEventType.USER_JOIN_ROOM, this); - addEventListener(SFSEventType.USER_LEAVE_ROOM, this); - - } -\end{lstlisting} - -One can see that the utility services as logging and data management are initialized in the room extension as well as in the zone extension. This is necessary, due to the SmartFoxServer architecture, which allows extensions of any level (Zone and Room) to be dynamically plugged in the server. This approach is also known as \textit{hot deployment} and is achieved by loading different extensions in different class loaders as shown on Figure \ref{fig:sfsExtensionDeployment}. Since each extension has its own class loader, it does not share objects with other extensions, thus it has to initialize service singleton classes separately and whenever communication to another extension is necessary, it has to be done via internal communication provided by the SmartFox framework. However, the framework as well as shared libraries and classes are deployed in \textit{parents} class loaders, which cannot be dynamically created and are shared between deployed extensions. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{src/pic/imgs/sfs-class-loaders.png} - \caption{SmartFox extension hot deployment} - \label{fig:sfsExtensionDeployment} -\end{figure} - -As we already mentioned in the \ref{sec:WorkFlow}, whenever a user joins a room, it receives automatically the world data for the sector, which is served by the room. This behavior is achieved by registering a server event listener, which sends the world data to a client, upon \textit{user join room} event, as shown in Listing \ref{lst:userJoin}. Furthermore the user's primary vehicle, i.e. the one the user has initially chosen to follow, as well as all the secondary vehicles, i.e. rest of the vehicles included in the chosen simulation scenario, are registered to the simulator. Two user properties are set, one for indicating whether the user has started visualization of the simulation and one containing the unique vehicle id of the user's primary vehicle. Additionally if the room's simulator is not yet started, it is going to be, when the first user joins the room. -\\ -\begin{lstlisting}[language=Java,caption={User join event handling}, label={lst:userJoin}] - @Override - public void handleServerEvent(ISFSEvent event) throws Exception { - switch(event.getType()) { - case USER_JOIN_ROOM: - if(WorldModel.getInstance() != null) { - User user = (User) event.getParameter(SFSEventParam.USER); - - //send LOAD_SCENARIO response to client with world details - SFSObject response = WorldBuilder.getInstance() - .getSFSWorld(WorldModel.getInstance().getContainer()); - send(ZoneExt.LOAD_SCENARIO, response, user); - - //add followed (primary) vehicle to simulation - long vid = addTrackToSimulation((Long) user - .getProperty(TRACK_ID), - (Integer) user.getProperty(S_INDEX), true); - - //add secondary vehicles - Long[] secondaryVehicles = (Long[]) user - .getProperty(SECONDARY_TRACKS); - if(secondaryVehicles != null) { - for(int i=0; i nodes, - Connection con) { - - //ensure lack of duplicates - Set entries = new LinkedHashSet(); - entries.addAll(nodes); - - String sql = "INSERT INTO entry_node (sector_id, node_osm_id) " - + "VALUES (?, ?);"; - - PreparedStatement stat = null; - - try { - con.setAutoCommit(false); - - stat = con.prepareStatement(sql); - - for(EnvNode node : entries) { - stat.setLong(1, sectorId); - stat.setDouble(2, node.getOsmId()); - //register transaction - stat.addBatch(); - } - - stat.executeBatch(); - con.commit(); - } catch (SQLException e) { - console.trace(ExtensionLogLevel.ERROR, e); - try { - con.rollback(); - } catch (SQLException e1) { - console.trace(ExtensionLogLevel.ERROR, e1); - } - } finally { - DataAccessUtils.getInstance().close(null, stat, null); - } - } -\end{lstlisting} - -\section{Web Communication} -\label{sec:WebCommunication} - -Web communication is an important part of our simulation system, because it achieves the binding between server and client applications. Whenever web communication is discussed, two main aspects have to be taken into account - performance and security. - -As we already discussed, the web communication in our simulation platform is achieved by means of the WebSocket protocol. It allows a user to connect to the server and preserve a connection, which means that a user has subscribed for server notifications as well as the user is able to send a message to the server at any time without need of opening a new connection or sending a large amount of header information, as it would have been if the \textit{HTTP} protocol has been used. Opening a single connection between user and server guarantees a dedicated secure channel, for transmitting messages between both sides. Since SmartFoxServer allows usage of the binary WebSocket protocol, additional steps for converting data into \textit{base64} strings are omitted and together with the omitted header information the overall communication performance is increased, due to decreased size of sent messages. - -As we already mentioned, the SmartFox server provides the environment for our extensions to serve user requests, sent through WebSocket connection. The WebSocket connection is opened by an HTTP request sent from client application. Once the request receives an acknowledgment response, the WebSocket connection is established successfully. - -Establishing the connection to the SmartFox server on the client side is done by using the SmartFox client API, which is used by an adapter service, responsible for establishing and managing the connection to the server, handling events triggered from the server as well as allowing custom requests, or messages, to be send to the server and received from it. Fully wrapping the SmartFox client API requires also response handling and correct serialization to be provided, whenever messages have to be sent or received. All these requirements are met and implemented in the \textit{Server.js} service, which we call also a \textit{server adapter}. Although most of its functionality is for internal use, i.e. listening to events, serialization and deserialization, the server adapter provides an API, which allows the main part of the client application to register handlers for server messages and send such to the server. - -As shown in Listings \ref{lst:serverAdapterConnection}, the server adapter establishes a connection to the server by default and registers event listeners, which implement certain logic for handles specific server events. -\\ -\begin{lstlisting}[language=Java,caption={Server adapter connection establishing}, label={lst:serverAdapterConnection}] - // Add event listeners - sfs.addEventListener( - SFS2X.SFSEvent.CONNECTION, onConnection, this); - sfs.addEventListener( - SFS2X.SFSEvent.CONNECTION_LOST, onConnectionLost, this); - - sfs.addEventListener( - SFS2X.SFSEvent.ROOM_JOIN, onRoomJoined, this); - sfs.addEventListener( - SFS2X.SFSEvent.ROOM_JOIN_ERROR, onRoomJoinError, this); - - sfs.addEventListener( - SFS2X.SFSEvent.EXTENSION_RESPONSE, onExtensionResponse, this); - - // Attempt connection - sfs.connect(); - - return self; //return public API -\end{lstlisting} - -After the connection is established, the client application code can override some event handlers, for example the handling of a \textit{login}, \textit{logout} or \textit{user variables change} events. Additionally, logging in and out of the platform as well as leaving a joined room is done via specific methods, provided by the server adapter API. Any other custom user requests are handled as an \textit{extension request}, therefore they are send in the same way, with the only difference of the message's command name, request parameters and the callback listener. This allows great flexibility, since one method allows any custom user request to be sent to the server and to provide a specific response handler. -\\ -\begin{lstlisting}[language=Java,caption={Server adapter sending extension request}, label={lst:serverAdapterRequest}] - //private methods - let sendRequest = function sendRequest(cmd, params, callback) { - if(typeof callback == 'function') - m_extensionListeners[cmd] = callback; - - sfs.send(new SFS2X.ExtensionRequest(cmd, params, m_room)); - }; -\end{lstlisting} - -However, since using this functionality directly will require that the main client code also takes care of the serialization, which depends greatly on the SmartFox serialization standard using SFSObjets, the server adapter does not allow direct usage of the \textit{sendRequest} methods, rather only via public methods, allowing only predefined requests to be sent. In our current implementation, the user is allowed to request scenario list, a single scenario simulation, to upload a new scenario or to fetch the next frame of already requested simulation. -\\ -\begin{lstlisting}[language=Java,caption={Server adapter extension requests public API}, label={lst:serverAdapterAPI}] - //public API - self = { - //extension requests - Zone - getScenarios: function getScenarios(callback) { - ... - }, - loadScenario: function loadScenario(scenarioId, trackId, - callback) { - ... - }, - uploadScenario: function uploadScenario(files, callback) { - ... - }, - //extension requests - Sector - nextFrame: function nextFrame(callback) { - ... - } - - ... - } -\end{lstlisting} - -Since our simulation platform is a long term product, that has gone through several phases, the web communication is implemented through a \textit{WebService} module, which is the only communication service used from the main client code. The WebService module provides the basic API for HTTP requests, which implementation is within the module. Nevertheless, due to the changes of communication mechanism from HTTP requests, through \textit{STOMP} protocol (\cite{STOMP}) over WebSockets, to SmartFox client API over binary WebSocket protocol, the WebService module has an extended public API, which allows using the API of currently used communication adapter, which operates over WebSocket, via the WebService module. This approach decouples the web communication adapters from the main client application code, since the WebSocket can now be used for HTTP requests as well as for WebSocket messaging, without additional adaptation to the new communication adapter operating over WebSockets. -\\ -\begin{lstlisting}[language=Java,caption={WebService pulic API}, label={lst:webService}] - return { - //generic request - request: request, - //short get request - get: function get(URL, params, contentType) { - return request('GET', URL, params, contentType); - }, - //short post request - post: function post(URL, params, contentType) { - return request('POST', URL, params, contentType); - }, - //WebSockets commands - WS_isSimRunning: function () { return SIM_RUNNING; }, - - WS_login: function (user, pass, onSuccess, onError) { - Server.login(user, pass, onSuccess, onError); - }, - WS_logout: function (callback) { - Server.logout(callback); - }, - - WS_onUserUpdate: function (callback) { - Server.onUserVarsChange(callback); - }, - - WS_getScenarios: function (callback) { - Server.getScenarios(callback); - }, - WS_loadScenario: function (scenarioId, trackId, callback) { - Server.loadScenario(scenarioId, trackId, callback); - }, - WS_uploadScenario: function (files, callback) { - Server.uploadScenario(files, callback); - }, - WS_onSimulationReady: function (callback) { - Server.onSimulationReady(callback); - }, - - //legacy - WS_attachListener: function WSattachListener(listener) { - onNextFrame = listener; - }, - - WS_start: function () { - SIM_RUNNING = true; - this.WS_nextFrame(); - }, - WS_stop: function (callback) { - Server.leaveRoom(callback); - SIM_RUNNING = false; - }, - - WS_nextFrame: function () { - if(SIM_RUNNING) - Server.nextFrame(onNextFrame); - }, - } -\end{lstlisting} - -\section{Simulation} -\label{sec:Simulation} - -Although we already discussed the general work-flow of our simulation platform, it does not give enough information about how exactly our simulator works. Since we try to preserve component-based development technique, our simulator is actually an independent component, which is combined with path-finding and trajectory planning components, which provide necessary input data to allow the simulator to process simulation scenarios. - -Since our platform has many sectors and each sector keeps one simulator active, all the simulations currently running in one sector, are calculated by one single simulator object. The input data necessary for the simulator as well as its configuration are provided by business logic of the web server, handling a single sector. Therefore the result frames calculated by the simulator are accessible for a client only through the web server. Additionally all the calculated frame data is stored in a mediator, therefore server can run simulation without being tightly coupled with the client. The client application can fetch frame data from the mediator, although still using the web server handlers, but without affecting the work process of the server and the simulator. - -Since all simulations running in one sector are merged together, additional synchronization is necessary, in order to provide each user with correct, for his chosen scenario, frame data. Additionally users running their simulations in the same sector are allowed to follow vehicles, from different scenarios. However, the web server keeps track of user's and their vehicles, and whenever a vehicle has to be transferred to another sector, only its owner (requester) will be transferred with it to the next sector. - -How fast a simulation is visualized depends only on the ability of the client's machine to render the frames as well as the speed of the connection between client and server. Since the simulation frames are loaded in the mediator, before a client can execute the simulation, each user can experience a smooth simulation, without being dependent on server-side calculation processes. - -\subsection{Simulation Controller} - -Since our platform provides the environment for simulation components, it uses external simulator, sensors and models, which are adapted accordingly, in order to be used by the platform. - -The adapter allowing the web server to handle simulations as well as decouple it from the simulator modules is implemented as \textit{SimulationController}. Each room instance has one simulation controller, which is responsible for handling all the requested simulations located in the sector served by the current room instance. In the initializing process of each room, the simulation controller is created and configured, using the server configuration, initially loaded from the main configuration file. - -The initialization of the simulation controller prepares the main simulator, the mediator buffers, as well as all the additional simulators. All the dependencies for the external simulators are met in the process of initialization of simulation controller. Whenever a user joins room, the user's simulation scenario is parsed and all the necessary vehicles are registered to the simulator via the simulator controller of that room. Additionally, the first joined user triggers the start of the simulation. - -During simulation, the simulation controller receives the produced frame data and stores it in the mediator buffers, according to the registered simulation scenarios. This means that, each buffer is responsible to handle specific simulation scenario and will not be filled up with frames, which does not contain the vehicles involved in that simulation scenario. -\\ -\begin{lstlisting}[language=Java,caption={Simulation controller storing frame data in mediator}, label={lst:simCtrl}] - @Override - public void didExecuteLoop( - List simulationObjects, - long totalTime, long deltaTime) { - - for(Car car : this.currentFrame.getCars()) { - - if(this.simBuffers.containsKey(car.getId())) { - boolean isQueueFull = !this.simBuffers - .get(car.getId()).push(this.currentFrame); - - //simulation buffer is full, allow client to start simulation - if(isQueueFull) - this.callback.apply(new Long[]{ car.getId(), 0l }); - } - //remove the vehicle, if final destination has been reached - removeVehicle(car.getId(), false); - } - } -\end{lstlisting} - -Additionally the simulation controller handles the vehicle removal process, by checking whether a vehicle has reached its destination comparing the frame data to the scenario target destination. If a vehicle has reached its destination, it is removed and a callback function is executed, in order to allow the web server to notify the user, that its scenario is completely simulated and visualization is now allowed. As we can see from the code above, if a simulation buffer is full, but yet the scenario is not completely simulated, the user will be allowed to start visualization, in order to start getting frames from the buffer, and therefore creating space in the buffer for new frame data. Although our simulation controller is prepared to handle such a problem, this case is quite unlikely to happen, with default configuration of simulator, mediator and virtual world sector size, and if buffer's size is configured to have a greater capacity, then the probability this problem might occur will decrease further. - -As we already mentioned, the static objects are registered in the simulator upon initialization of the simulation controller. However, since at any point a new user may request a scenario to be simulated, the simulation controller has to be able to add new objects to the simulation in run-time. This functionality is used by the web server, in particular the room extension code, to register new vehicle, when a new user joins the room and its scenario has to be simulated. - -The simulation controller wraps not only the different simulators and the mediator, providing an API to be used by the room extension instances, but also it takes care of applying different vehicle models, which are supposed to work together with the main simulator. Since a new models may become available, additional adapters are necessary, to prepare them to be used with the main simulator. This allows for easy change of these adapters by extending the simulation controller. - -\subsection{Mediator} - -The mediator pattern (\cite{gamma1995design}) is used to decouple components by encapsulating the way they interact with each other, thus reducing the dependencies between them. In other words, the mediator object encapsulates a communication API, which is then used by other objects to communicate with each other through the mediator. - -We make use of the mediator pattern to decouple simulation from web services and to allow visualization, without need of concurrently running simulation. Our simulation platform implements this pattern by means of \textit{queues}, and in particular \textit{blocking} queues. Those blocking queues are playing the role of a simulation buffer, with configurable capacity. -\\ -\begin{lstlisting}[language=Java,caption={Simulation buffer}, label={lst:simBuff}] -public class SimulationBuffer { - - private BlockingQueue frames; - ... - - public SimulationBuffer(int bufferSize) { - ... - this.frames = new LinkedBlockingQueue(bufferSize); - } - ... -} -\end{lstlisting} - -Each simulation buffer object handles its own blocking queue and provides an API for adding and retrieving elements from the queue, as well as time tracking between the initialization of the buffer until the time of the last adding of a frame. - -Since the simulation buffer is using a blocking queue, whenever a new frame is \textit{pushed} to the buffer, if the queue capacity is exhausted, the queue will block, waiting for free space to become available and only then store the new frame there. As we mentioned, such a scenario is quite unlikely to happen, but if this is the case, the simulation buffer will return false upon calling its push method from the simulation controller, which will trigger a procedure for notifying the user, that its simulation is ready to be visualized. Although the simulation is not completed, allowing the user to start visualization, will cause frames to be \textit{popped} from the buffer, thus making free space for new simulated frames to be stored in it. - -\subsection{Scenarios} -\label{ssec:Scenarios} - -A single simulation scenario contains details about the routes, or tracks, of the vehicles, which are to be simulated. Each vehicle follows a track, and receives a unique id only when it is simulated, and behaves depending on the loaded model, which will execute together with the main simulator, thus a scenario does not keep information about vehicles, rather only about their tracks. Each scenario is given a unique name and belongs to a map as shown in Listings \ref{lst:scenDB}. The scenario name is shown to the user in a drop down list together with other scenarios, thus it has to be descriptive. Whenever a scenario is selected for simulation, at any time the server code can access the virtual world details by using the relation between a scenario and the map it belongs to. -\\ -\begin{lstlisting}[language=SQL,caption={Scenario table}, label={lst:scenDB}] - CREATE TABLE scenario ( - id serial NOT NULL, - sname character varying(255) NOT NULL, - map_id integer NOT NULL, - CONSTRAINT scenario_pkey PRIMARY KEY (id), - CONSTRAINT scenario_map_id_fkey FOREIGN KEY (map_id) - REFERENCES map (id) MATCH SIMPLE - ON UPDATE NO ACTION ON DELETE NO ACTION - ) -\end{lstlisting} - -Since a scenario should allow many vehicles to be visualized, a single scenario can be associated with many tracks. A single scenario track is given also a unique name, describing the vehicle route, also shown to the user, to allow him to select which route to follow initially. Each track is associated with a scenario as shown in Listings \ref{lst:trackDB}. -\\ -\begin{lstlisting}[language=SQL,caption={Track table}, label={lst:trackDB}] - CREATE TABLE track ( - id serial NOT NULL, - tname character varying(50) NOT NULL, - scenario_id integer NOT NULL, - CONSTRAINT track_pkey PRIMARY KEY (id), - CONSTRAINT track_scenario_id_fkey FOREIGN KEY (scenario_id) - REFERENCES scenario (id) MATCH SIMPLE - ON UPDATE NO ACTION ON DELETE NO ACTION - ) -\end{lstlisting} - -Until this moment no information is given about the tracks, except their names. Since our simulation platform is made in a distributed manner and a single simulator can handle simulations only in a single sector, a scenario track can consist of many sections. Each track section is contained in a single sector, thus allowing for fast retrieving of precise trajectory as well as to be simulated by a single simulator. If a scenario track crosses many sectors, for each sector, the part of the track going through that sector is saved as a track section. A track section belongs to a track but also to a sector and keeps information about its start and target nodes, which are used as an input for the precise trajectory finding algorithm. However, these two nodes are defined by the \textit{path finder}, which finds the whole track and splits it into sections, as described already in section \ref{sec:PathFinder}. -\\ -\begin{lstlisting}[language=SQL,caption={Track section table}, label={lst:trackSec}] - CREATE TABLE track_section ( - id serial NOT NULL, - track_id bigint, - source bigint NOT NULL, - target bigint NOT NULL, - sector_id bigint NOT NULL, - CONSTRAINT track_section_pkey PRIMARY KEY (id), - CONSTRAINT track_section_sector_id_fkey FOREIGN KEY (sector_id) - REFERENCES sector (id) MATCH SIMPLE - ON UPDATE NO ACTION ON DELETE NO ACTION, - CONSTRAINT track_section_track_id_fkey FOREIGN KEY (track_id) - REFERENCES track (id) MATCH SIMPLE - ON UPDATE NO ACTION ON DELETE NO ACTION - ) -\end{lstlisting} - -The client application allows a user to select a scenario and track to follow from a drop down list or to upload such scenario. The process of selecting a scenario is simple as the client application requests the scenario list, displays it to the user and upon selection request scenario simulation. - -Uploading a scenario however involve more work on the server side, since the input files have to be verified, adjusted to the simulator needs and adapted to the virtual world data. After all verification and parsing procedures are done the path finder has to be executed, in order to find scenario tracks and split them into scenario sections. Only after the path finding procedure is done for all tracks defined in the new scenario, all data is saved to the database and the user's scenario list is updated. The server application uses a mediator class for uploading new scenarios, since additional external adapters are necessary, one for parsing the given scenario map and additional adapters for parsing the scenario simulation configuration and adapting it to the main simulator needs. - -Both procedures for listing and for uploading scenarios are shown in a sequence diagram on Figure \ref{fig:scenSeq}. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/ScenarioList.pdf} - \caption{Scenario listing and uploading} - \label{fig:scenSeq} -\end{figure} - -\clearpage -\subsection{Synchronization and Visualization} - -Simulating many vehicles from different scenarios and allowing many users to access simulation frames, requires synchronization between different scenario vehicles and users. This synchronization is achieved by the mediator, that we already discussed, together with usage of SmartFox \textit{user properties}. - -As we already mentioned in section \ref{sec:WorkFlow}, upon requested simulation by a user, the zone extension will prepare user simulation properties and transfer the user to the corresponding room, which is to handle the user simulation for the initial path section of the vehicle, selected to be followed by the user. Those properties contain the primary vehicle track id, the current track section to be played as well as all the secondary vehicle tracks from the chosen scenario. When the user is joined to the room, which is to handle its simulation, those properties are used to register the primary vehicle as well as all the secondary vehicles, whose track sections belong to the current sector. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/Simulation.pdf} - \caption{Simulation and visualization} - \label{fig:simVis} -\end{figure} - -Additionally the the room extension assigns a property for \textit{vehicle initialization} and \textit{vehicle id}. The vehicle id property is derived from the simulation controller once the vehicle is added to the simulation and a unique vehicle id is generated by the simulator. The vehicle initialization property is used to point out, whether the user has been notified about which vehicle he initially has chosen to follow. It is purely necessary for the visualization. Since a requested scenario may contain many vehicles and their unique ids are not known beforehand, the first frame data send to the user will also contain information about the vehicle, which the user has chosen to follow, which will also set the user's initial viewpoint to follow this specific vehicle. Once the user is notified about his primary vehicle, the vehicle initialization property is set to \textit{true} and the server will never again send the primary vehicle's id to the client application explicitly. This property is checked each time a new frame is requested by the user and it is important that the primary vehicle information is not send with each frame to the client, since it will keep the user's viewpoint always at the primary vehicle, thus disabling the opportunity the user to change its viewpoint to follow another vehicle. The whole process of simulation scenario selection, visualization and transfer between sectors is shown on Figure \ref{fig:simVis}. - -On the client side, the event listeners, registered to the server adapter, which we already discussed in section \ref{sec:WebCommunication}, help with scenario selection and initialization of the visualization. Once the visualization is started, a \textit{DataModel} module is used to handle the whole visualization process. This module is implemented as a singleton service and is used for registering and executing frame data handlers. Each handler, registered from other part of the client code, will receive only a piece of the frame data, for which it is registered. Additionally those handlers are executed as \textit{Promises}, which means that they are asynchronously executed, allowing for execution not only of calculations but also of animations. -\\ -\begin{lstlisting}[language=Java,caption={DataModel handler registering}, label={lst:dmHandlers}] - - self.addHandler = function addHandler(type, handler) { - - var handlers = [ - self.STREETS_HANDLER, - self.BUILDINGS_HANDLER, - self.CARS_HANDLER, - self.BOUNDS_HANDLER, - self.RAIN_HANDLER, - self.PEDESTRIANS_HANDLER, - self.STATIC_BOX_OBJECT_HANDLER - ]; - - if((handlers.findIndex( (el) => { return el == type; }) > -1) - && typeof handler == "function") { - - DATA_HANDLERS[type] = function (data) { - return new Promise(function (resolve, reject) { - handler(data, resolve, reject); - }); - } - } - } -\end{lstlisting} - -This turns the service into a main data handler, which allows at a single point data parsers for each type of frame data to be defined, thus allowing the data to be adjusted in a such a way, that the visualization can process it correctly. -\\ -\begin{lstlisting}[language=Java,caption={DataModel handlers execution}, label={lst:dmHandlePromises}] - var handleData = function handleData(data, initialized) { - // Timing values - self.simulationTimePrevMs = self.simulationTimeCurrMs; - self.simulationTimeCurrMs = data.simulationTime; - self.simulationTimeDeltaMs = - self.simulationTimeCurrMs - self.simulationTimePrevMs; - - //execute specific handler with specific data - var promises = []; - for(var h in DATA_HANDLERS) { - if(DATA_HANDLERS[h] && (data[h] != null)) { - promises.push( - DATA_HANDLERS[h]( - PARSERS[h] ? PARSERS[h](data[h]) : data[h] - ) - ); - } - } - - Promise.all(promises) - .then(initialized ? onHandlersDone : initialize); - } -\end{lstlisting} - -Additionally, executing all the registered handlers as promises allows the DataModel to slow down or speed up the visualization, depending on the speed, with which each handler returns status \textit{fulfilled}. Once all the handlers have returned status fulfilled, the DataModel decides to initialize the visualization, if it is not yet initialized, or to proceed with it via requesting the next visualization frame and execute a special \textit{afterEachFrame} handler for post-processing, if such is registered. -\\ -\begin{lstlisting}[language=Java,caption={DataModel after handler execution}, label={lst:dmInit}] - var initialize = function initialize() { - console.log('INITIALIZE SIMULATION ANIMATION'); - if(self.onDataProcessed) self.onDataProcessed(); - self.onDataProcessed = null; //executed only once - } - - var onHandlersDone = function onHandlersDone() { - if(typeof self.afterEachFrame == "function") - self.afterEachFrame(); //e.g. send a screenshot - - WebService.WS_nextFrame(); - } -\end{lstlisting} - -Since the DataModel controls visualization handlers execution, it behaves a lot like a mediator, providing communication API for other modules to register their handlers and therefore completely eliminating direct connection between them. Since the DataModel takes care of the visualization speed, depending on handlers execution time, it can also provide an additional caching mechanism. The caching mechanism allows the DataModel to visualize one simulated frame, while keeping the next simulated frame in the memory. Although just a single frame is kept in the memory, if a delay occurs, while a new frame is retrieved from the server, due to the cached frame, the client's visualization will proceed smoothly, since its dependency to the web communication is slightly eased. -\\ -\begin{lstlisting}[language=Java,caption={DataModel visualization and caching mechanism}, label={lst:dmVisCache}] - self.onData = function onData(data) { - if(!data) return; //stop simulation - - if(typeof self.onDataProcessed == "function") { - console.log('Init simulation'); - handleData(data, false); - }else if(!cachedPrevFrame) { - console.log('Init cache'); - cacheData(data); - WebService.WS_nextFrame(); - }else { - console.log('Play and cache'); - handleData(cachedPrevFrame, true); - cacheData(data); //cache current frame data - } - } -\end{lstlisting} - -As shown in Listings \ref{lst:dmVisCache}, the visualization proceeds in several steps. First, if the visualization is not yet initialized, the DataModel will run the necessary handlers and start rendering the visualization. The very first data received by the DataModel is always the world data, so at this point the DataModel will execute all the necessary handlers for environment objects - streets, buildings, static objects, world boundaries. If the visualization is already initialized, the DataModel will check for cached frame each time a new frame is received. If the cache is empty, the new frame will be cached, but not played and the DataModel will request another frame. Otherwise, if there is already cached frame, it will be visualized, and the new frame will be cached. This process continues until the server stops sending simulation frames back to the client. For each received frame, all the handlers, for which the frame contains data, will be executed. During visualization, mostly the handlers for vehicles and weather are executed, but if changes are done on server side and the pieces of environment data are sent with each frame, then the client application will rebuild the visualized world accordingly. - -The frame data handlers are often implemented using a separate module, tightly related to the task of the handler. For example the \textit{environment builder}, \textit{car controller}, \textit{light controller} and \textit{rain controller} modules are used accordingly in the handlers for building environment objects, vehicles and weather. The first three modules are implemented following the \textit{factory pattern} (\cite{gamma1995design}). This allows a single module to create, manipulate and also remove a scope of visualized objects. This approach proves to be handy, since whenever new objects have to be visualized on the place of old ones, the old objects have to be remove quickly, in order to free system resources. For example the environment builder keeps track of all the objects that are created using it, thus whenever new sector map has to be visualized, the previously visualized environment can be removed completely by using a single method from the environment builder API. The same approach is used for car and light controller, which are even more often required to remove old objects and create new ones. - -The DataModel decouples not only the modules inside the client application and their dependency on the frame data representation, but also the communication between client and server application, since the frame data format is allowed to change, whenever server side changes are made. - -\section{Configuration} - -Our simulation platform needs to be configured in several aspects. The first one is the initialization of the virtual world. Its pre-processing requires details about the map and how it has to be converted to Java objects. After the map is converted, it needs to be split on sectors, which contain overlapping areas and only then saved to the database. Therefore information about map splitting, i.e. sector and overlapping size, need to be included in a configuration file and used whenever a zone server is initialized. - -Since each sector has a running simulator, and handles user simulations, configuration for the whole sector's simulation, such as weather conditions for example, has to be given. - -Simulator's performance depends also on configuration, especially about frame-generating speed and frame buffer size. If the frame rate is higher, then the simulator will produce more detailed simulation, but will also take more time and will need more memory to store the frame data. Since a sector keeps running simulator's instance until all simulations are completed and stored in the mediator buffers, the frame buffer size is necessary to be restricted, which is a security measure, preventing \textit{denial of service} scenario, which may occur if all the server's memory is occupied with frame data. - -All the configuration we mentioned until now is loaded from a configuration file, added to the \textit{zone} configuration representing the virtual world on our server. Additionally, a loaded zone extension can be configuration about the amount of users allowed to connect, the amount of rooms that can be created, etc. All those settings as well as the path to the configuration file are set using the SmartFox \textit{admin panel}, as shown on Figure \ref{fig:zoneConfig}. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{src/pic/imgs/screenshots/ZoneConfiguration.png} - \caption{Zone configuration} - \label{fig:zoneConfig} -\end{figure} - - -Last but not least, the web server can also be configured, about the served port, session time, allowed communication protocols, etc. Additionally filters can be configured for security reasons or user management. Performance configuration can be fine tuned for a specific system, in order to enhance server's performance in specific aspects. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{src/pic/imgs/screenshots/WebServerConfig.png} - \caption{Web server configuration} - \label{fig:webServerConfig} -\end{figure} - - -\section{Security} - -Since our simulation application is based on the client/server architecture, it requires security mechanisms to be applied, in order to allow correct application behavior. - -As we already mentioned, our client application is based on web technologies, which make the communication between server and client vulnerable to various attacks. Due to the WebSocket protocol, SmartFoxServer increases a lot the security of the connection between client and server applications. Each time a user connect to the server, a dedicated connection is opened and preserved as shown on Figure \ref{fig:Authentication}. Thus every message between this client and the server is sent through this connection. This guarantees that the sent messages are always received by the correct side and cannot be intercepted. Additionally, for each connection, on the server side an object, containing information about the user, who has opened the connection, is created. By making use of this user-objects, on the web server user management mechanisms are implemented. This allows the server to keep track of user's actions and thus providing user-related events, which can improve the internal communication between zone and rooms. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/Authentication.pdf} - \caption{Client authentication process} - \label{fig:Authentication} -\end{figure} - -Since WebSocket protocol requires only one HTTP handshake message to be sent from client to server, in order a connection to be opened, further messages do not need to carry header information, which can expose additional information. - -Depending on the web server configuration, which we mentioned in the previous section, a client session is maintained, thus the user actions are tracked and user's connection can be restricted, by defining a session and user idle time. If a user keeps a connection open for too long, without using any services, it will be closed automatically, thus requiring a new connection to be established, once the user decides to be active again. This can help the connection management and therefore reduce the threat of denial of service attacks, due to exhausted connections capacity. - -Additionally due to the platform architecture, which is based on the three-tier model, clients are never in direct touch with the database server. Additionally each web server keep configuration, allowing it to connect to the database server and be authenticated. - -Upon login, the user's credentials are transmitted via the binary WebSocket protocol in an encrypted message, which adds additional protection against eavesdropping. Once the credentials are received on the server side, the SmartFox will decrypt them automatically to their original format. By using a \textit{custom login} on zone level, SmartFox development kit allows for custom implementation of the login logic, thus allowing for additional encryption to be used for storing user credentials in the database. \ No newline at end of file diff --git a/docs/Thesis/src/tex/technicalRequisites.tex b/docs/Thesis/src/tex/technicalRequisites.tex deleted file mode 100644 index 3517df3780c8667b7c51ebad61086c4ae8214e78..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/technicalRequisites.tex +++ /dev/null @@ -1,66 +0,0 @@ -\chapter{Technical Requisites} - -Achieving simultaneous usage of many users as well as providing good user experience and overall performance requires well defined application domain, architectural decision and precise implementation. Since we already discussed the domain in which our work is based as well as the different architectures supporting distributed software solutions, in this chapter we discuss the technologies we have used while building both client and server applications. - -Since our simulation platform can be distributed on different machines, communication between client and server has to be secure and fast. As our client application is web-based, we make use of web-communication protocols like \textit{HTTP(S)}, \textit{TCP/IP} (\cite{DBLP:books/lib/TanenbaumW11}) and especially \textit{WebSocket} protocol (\cite{fette2011websocket}). - -Another important aspect of our platform is the client application and in particular user experience and application performance. We have implemented our client application based on \textit{WebGL} (\cite{Cozzi15}), in order to simulate 3D object models. - -In the next sections we discuss more about the frameworks we chose to work with and what benefits they provide. - -\section{SmartFoxServer} - -\textit{SmartFoxServer} (\cite{SFS}) is a \textit{Software Development Kit} for developing multiplayer games and application. It is providing a rich set of features tightly connected with multiplayer game development, database connectivity, security mechanisms as well as optimized communication protocols, data serialization and user management. - -Due to the requirements and goals of our simulation platform, SFS seems to be a reasonable choice for development of our web-server application. We make great use of several features that SFS provides in its regular release version, which we discuss in the next paragraphs. - -\subsection{Web Server} - -The embedded \textit{Jetty} Web-server (\cite{Jetty}), which we use to deploy our web-based client application, play a major role in our simulation platform architecture. By deploying on a web-server we achieve flexibility in application versioning and deployment, since whenever a new version of the client application is tested and ready for release, it just has to be deployed on the web-server and it will automatically substitute the old version. No additional actions as upgrading or downloading and installing the new application version from user side is necessary. - -Since Internet and web-technologies are widely used and because of the high level of support of web technologies by different devices, using web-based platform allows us to reach a greater amount of users worldwide. - -\subsection{Web Services} - -Web Services are the core feature necessary for developing the communication between our client and server applications. By using them, we have developed a secure and organized communication, which preserve connection with each user and thus guaranteeing user's identity and increasing performance. By combining it with the binary WebSocket protocol, which reduces the bandwidth with around 30\%, due to elimination of the necessity of \textit{base64} encoding of the messages sent between client and server as well as the overall steps taken to processes a message through WebSocket and TCP/IP protocols. - -\subsection{Data serialization} - -SmartFoxServer introduces its own data representation wrapper object, which allows the messages sent between server and client use a standard for data representation. This standard is implemented in \textit{SFSObject} and \textit{SFSArray} classes, which provide an API with getters and setters, allowing data population of the wrapper object. Data type is required whenever such a wrapper object is populated and grants correction of the data, when a message is received by an application. Most of the standard data types such as boolean, byte, integer, single and double precision floating point formats are supported, making this data representation wrappers easily adaptable to many different programming languages. - -\subsection{Scope Management} - -SmartFoxServer introduces two basic concepts of scopes, a visual representation of which is shown on Figure \ref{fig:SFS}: - -\begin{figure}[h] - \centering\includegraphics[width=.5\textwidth]{src/pic/imgs/sfs-room-architecture.png} - \caption{SmartFoxServer architecture} - \label{fig:SFS} -\end{figure} - -\begin{itemize} - \item \textit{Zone} - has the largest scope in the concept of SFS architecture. It is a big part of the server application, dedicated to serve specific application or a different instance of it. It can handle user requests concerning global actions in the scope of the zone they are logged in. A zone can be served by different machines, since it does not interfere in the work-flow of other zones. Therefore the zone-concept allows SmartFoxServer to distribute one server application on many serving machines, thus decreasing server load and scalability of the whole platform. - \item \textit{Room} - is contained in a zone. It has a smaller scope and can handle user requests of clients that have already joined in it. These user requests are concerning local events, allowed actions or interaction with other users in the same room. A room can be managed by its parent zone and is allowed to communicate with other rooms through its parent zone. -\end{itemize} - -In SmartFoxServer each room and zone can be created dynamically, since each of them is loaded in its own class loader. Zones and rooms can be dynamically added to the life-cycle of the whole server application. This means that at any time server code can be updated automatically by deploying a new extension \footnote{Custom developer implementation of a Zone or Room}. This plug-in feature increases the scalability and flexibility of the whole application. - -\subsection{Data access and server monitoring} - -Additionally SmartFoxServer provides data access utility classes, easing the work with database when necessary. Default \textit{database drivers} are provided, but can also be substitute by specified custom driver, whenever necessary. Database access and credentials can be configured in the \textit{Admin panel} tool, which is deployed by default as a web-application whenever the SFS is running. - -The admin panel allows custom configuration in many aspects. Communication protocols, user and scope management properties are able to be configured and handled automatically by the server. Additionally monitoring of activities and server load in zones, rooms or for single users is provided, easing troubleshooting, server integration and deployment. - -\section{ThreeJS} - -\textit{ThreeJS} (\cite{dirksen2014three}) is a lightweight \textit{JavaScript} library for creating and displaying animated 3D computer graphics in a Web browser. It can be use in conjunction with \textit{HTML5 canvas}, \textit{SVG} or \textit{WebGL}. - -ThreeJS provides a rich set of graphics features, allowing precise 3D animation development. Based on WebGL a web application can render complex 3D graphics faster and smoother, depending of course on machine's hardware, especially on the GPU and its dedicated memory. - -Additionally WebGL provides an API close to commonly used OpenGL graphics library and is supported by all modern major browsers without additional plug-ins. This makes the library widely used in web-based application due to ease of use and wide browser support. - -\section{PostgreSQL database} - -\textit{PostgreSQL} (\cite{PGSQL}) is an open source \textit{relational database}. It provides all the standard SQL features as well as advanced SQL data types such as \textit{Arrays} and \textit{Intervals}, etc., additional procedural language features, native regular expression support, batch query execution, additional features for data import/export and many more. It worth mentioning that PostgreSQL server is also supported on Unix, BSD and Windows based systems. - -Using a database in a distributed system can help reducing memory consumption, due to caching information. Overall performance can be increased, due to fast querying and reduced response data capacity. Additionally customized data structure can optimize data processing, due to elimination of additional adaptation of the input and output data. \ No newline at end of file diff --git a/docs/Thesis/src/tex/theoreticalBackground.tex b/docs/Thesis/src/tex/theoreticalBackground.tex deleted file mode 100644 index fcbbd589dc604599458d198947628a5ee48e1741..0000000000000000000000000000000000000000 --- a/docs/Thesis/src/tex/theoreticalBackground.tex +++ /dev/null @@ -1,255 +0,0 @@ -\chapter{Preliminaries} - -\section{Massive multiplayer online gaming} - -\textit{Multiplayer} gaming allows users running client applications to connect, interact and play a game with other users all over the world. There are several types of multiplayer gaming depending on the connection to the other users, most common of which are the \textit{local connection} (over LAN\footnote{Local area network}) and \textit{online} (over Internet). - -\textit{Massive multiplayer online} (MMO) gaming brings the first concept to a new level, allowing a very big amount of users to interact with each other in a constantly active virtual world. Compared to regular multiplayer, where each time users want to play, they create a new private room, which is an instance of a region and is restricted to have a low number of users, MMO provides a very big virtual world, which is instantiated once when the server is started, and kept running until the server is shutdown, thus allowing many users to connect and interact with each other. Therefore MMO requires a certain level of scalability, in order to keep the virtual world running, as well as synchronization to provide the necessary playability to the users. Since simulation of vehicles with real world data shares many commonalities with MMO concept, we based our solution on many approaches used in MMO. In the next sections we explain those concepts and how they are handled in massive multiplayer online gaming. - -\theoremstyle{definition} -\begin{definition} -Virtual world in a MMO game includes a map, terrain and all static objects necessary to provide simulated environment, in which users can play. In this environment all players, non-player characters (NPC) and dynamic objects reside, interact and change the state of the world. -\end{definition} - -\theoremstyle{definition} -\begin{definition} -A player is defined by a single human user, allowed to interact with the environment, other players and NPCs. Each player has properties defined by the game itself and they can change during interaction with other players or non-player characters, as well as with the environment. When such changes occur, the state of the virtual world changes, since it represents everything happening in it. -\end{definition} - -\theoremstyle{definition} -\begin{definition} -Non-player characters are all dynamic objects, controlled by an artificial intelligence algorithm (AI). They can interact in the same way the human players can, but normally execute specific loop-scripts. In our application, an example of such an NPC are pedestrians and traffic lights. -\end{definition} - -The concept of virtual world populated by non-player characters executing scripts, which keep them moving in a predefined loop, or behaving based on an AI algorithm allows a simulator to adopt such approaches, in order to provide a very close to reality environment. This in addition to the many players, who can interact with the environment as well as other players increases greatly the possible scenarios, that can be simulated. - -\section{Area of Interest} -\label{sec:aoi} - -\textit{Area of interest} (AoI) is a concept used in game development. It is a mechanism, that helps reducing the visualization data, which is about to be rendered on the client application, by visualizing only data, included in certain area (scope, range, etc.). In general, the \textit{AoI} is implemented depending of the environment visualization approach, for example if the map is displayed as a combination of square tiles, then the AoI is a rectangular region of tiles around the object. The data available for visualization to the client is all the environmental data, i.e. terrain and static objects, included in AoI as well as the additional dynamic objects entering the AoI. Whether all the data is rendered or a specific \textit{viewing region} defined by AoI together with \textit{viewing angle} is used, depends on the requirements of the client application. Example of AoI implementation is shown on Figure \ref{fig:AreaOfInterest}. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/AreaOfInterest.pdf} - \caption{Area of Interest: circular and hexagonal representation} - \label{fig:AreaOfInterest} -\end{figure} - -Area of interest is helpful in large environments, where the amount of events triggered by users is very big. In such scenarios, restricting users within their AoI, allows the server to reduce the amount of events received by users as well as propagation of events triggered inside their own AoI. This means that users, whose areas of interest intersect each other, have to synchronize environment objects, i.e. update each other about those object, residing in the intersected region, but everything that happens further away from their AoIs does not require synchronization. However, moving objects, whose movement starts by triggering an event from one user, can intersect another user's AoI at some point in the time. Global location-independent events, are also propagated to users. - -In a software simulator the area of interest can be helpful, if simulation is decoupled from specific area, and rather concerned only about the vehicle, whose movement and behavior it is supposed to simulate. If such approach is used, area of interest can reduce significantly the amount of environmental data given as input, thus reducing the amount of data processed by the simulator and therefore increasing simulation performance. Additionally the concept of area of interest is borrowed from real world, thus simulating autonomous driving vehicles from such a perspective can be very helpful. - -\section{Architectures} - -Distributed software solutions are based on two basic types of network architectures - \textit{peer-to-peer} and \textit{client/server} (\cite{DBLP:books/lib/TanenbaumW11}), with various modifications. Visual representation of those architectures is shown on Figure \ref{fig:archs}. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/Architectures.pdf} - \caption{Peer-to-peer and Client/Server architectures} - \label{fig:archs} -\end{figure} - -Both architectures bring their positives and negatives. In general we can compare them in several aspects - performance (latency), scalability, reliability (robustness), control and security. - -\subsection{Peer-to-peer} - -Peer-to-peer architecture provides very good performance for applications constraining users to communicate in groups with limited size. In multiplayer gaming this architecture is preferred mostly for shooter games, due to the low latency and very high frame-per-second ration, provided by the direct connections between all users playing in the same group (game room). When the amount of users communicating with each other increases, the capacity of the network increases too, since each new user brings its computational power within the network. This ability of peer-to-peer networks, to dynamically increase network capacity and performance by each new node (client machine), is also the reason for their good scalability. However, the more users communicate with each other, the higher the load of the network is, which is a prerequisite for failures and losing consistency, due to the huge amount of messages and data, the users have to send to each other in every \textit{tick}\footnote{time interval for sending/receiving updates to/from other users}. - -In order to provide better robustness, nodes (users) in peer-to-peer networks are often restricted to meet certain requirements, mostly referring to latency, e.g. users with higher latency than a threshold are not allowed to participate in the network, since they are the reason to slow down performance for all users inside the network. Another aspect for reliability is the \textit{consistency} and \textit{fault tolerance} of the network. Since in peer-to-peer networks, each client computes its own local view over the state of the service, it is important, that this state is consistent to the states of the other users in the network, i.e. consistency is a measure for quality of the service, in other words, the higher the consistency, the better the service is. High consistency level is achieved by \textit{synchronization} protocols. The main goal of such protocols is to achieve correct synchronization between all the users communicating in the network. Detailed description of such a protocol can be found at \cite{DBLP:conf/icmcs/GautierD98}, where Diot and Gautier introduce bucket synchronization protocol, which collects updates in buckets, and executes them depending on timestamp intervals of registered user actions. - -Since peer-to-peer networks do not provide centralized control, users all together have to maintain the state (consistency) of the service. In order to achieve this goal, aspects of the global state of shared objects and resources are distributed to the users within the network. This means that a user, called coordinator, will maintain the state of specific set of objects and whenever other users request information about the state of those objects, the coordinator will send back the necessary updates. To achieve better fault tolerance, each set of shared objects (resources) is assigned to more than one coordinator. This approach increases the chance, that when a user leaves the network, intentionally or unintentionally, there will be at least one other coordinator to keep the correct state of the objects it is assigned to, thus the global state of service is preserved correct. However, high consistency and fault tolerance in peer-to-peer networks can not replace centralized authority, therefore correct understanding of the application domain is crucial, when the application architecture is getting chosen. - -\subsection{Client/server} - -Client/server architecture differs from peer-to-peer in many aspect, the most noticeable of which is the connections between users, which in client/server architecture are indirect, because all the communication going between clients, goes through the server. This feature however, provides the ability of the server to become an authority, i.e. to achieve control over the provided service. By authorizing client requests, commands, etc., the server can achieve control over the state of service, which means that the consistency level is higher, as well as increasing security, due to indirect communication between clients, in other word control over communication inside the network. - -Fault tolerance in client/server architecture has a bit different meaning, than in peer-to-peer applications. While in P2P networks, users have to keep the state of service and it is important that when a user is leaving, the state is preserved correct, in client/server architecture the server is the only state keeper (coordinator), which means that users are not responsible about the state of service, but also that the server becomes a single-point of failure. This turns to be a big drawback of client/server model, and therefore additional mechanisms are developed for reducing the chance of failure and thus increasing the fault tolerance of applications based on this architecture. - -Together with fault tolerance, scalability of applications based on client/server architecture is not very high and further improvements are necessary to bring this aspect to a higher level. As a solution systems based on client/server model are using distribution of the server on several machines. There are several approaches for distributing a server, which we explain in chapter \ref{chap:simulationPlatform}. - -Performance in client/server architecture relies greatly on the server machine capabilities. Distributing server code on several machines increases fault tolerance (reliability) and computational power, but total performance becomes dependent on synchronization between server machines. Latency however, depends only on the connection to the server, which in comparison with peer-to-peer network, removes the need of latency threshold for users, since slow users can not affect other users' experience. - -Although client/server architecture can handle much more users than peer-to-peer, a research at \cite{DBLP:conf/netgames/KimCCKCY05}, about traffic characteristics of massive multiplayer online games based on client/server architecture, shows that the number of users, however, is limited. Usually the packages sent from the server to the users are several times more than the updates that users send to the server. Also a linear dependency between the number of users and the size of the packages sent from the server, shows that the number of users, when not limited, can increase to degree, that causes the size of the packages sent from the server to the clients to exceed even the size of the MTU \footnote{maximum transmission unit}. - -\subsubsection{Multi-tier architecture} - -Client/server architecture can be modified to achieve extra security, scalability or even to be better understood. One of the approaches for extending the client/server architecture is by adding additional layers. The very first implementation of client/server architecture is the \textit{two-tier} architecture, i.e. client layer and server layer. Since software applications are getting more and more complicated, two-tier architecture seems not reliable enough, therefore \textit{mutli-tier} architectures (\cite{TaylorEtAl2007}) are developed in order to split logic, data storage and management in different layers. - -Many web-based applications, like the one we develop, are based on \textit{three-tier} architecture, visual representation of which is shown on Figure \ref{fig:MultitierArch}. Client application is a separate layer as in two-tier architecture, but server code is split on \textit{business logic tier} and \textit{data storage tier}. This separation provides better security, and therefore increased robustness, since users actions can be restricted in the business logic tier, and direct access to the database or file system can be restricted. By managing user actions and additional processing of their request, a clean-defined application work-flow is provided, which decreases chances for errors in run-time, and therefore reliability of the application. Also test-driven development is encouraged, therefore application quality can be increased. - -There exist also multi-tier architectures with more than three layers, for example additional proxy layer, load balancing layer (arbiter) and so on. Their application in real projects depend on the application domain and specification requirements. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/ThreeTierArch.pdf} - \caption{Three-tier architecture} - \label{fig:MultitierArch} -\end{figure} - -\section{Distributing mechanisms} - -One monolith server would probably fail to handle very large amount of concurrent users at a time. Therefore the server has to be distributed to many machines. Sharing the load among several machines, however, turns to be a difficult task, since distributing one layer of the multi-tier architecture requires additional synchronization and load balancing. A naive approach would be to distribute the layers of the architecture on separate machines, but this however does not provide the necessary scalability, due to the fact that business tier will still experience very high load, due to the many concurrent user requests, even though the database load would have been transferred to a different machine. - -A various approaches for server distribution are developed to ease building distributed application. We explain several of them in this section. - -\subsection{Sharding} - -One of the first techniques for distributing server applications is \textit{sharding}, shown on Figure \ref{fig:sharding}. It is based on replication of server code and data storage on different machines, which are about to handle limited amount of users. Each server (cluster) serves not only the configured limited amount of users, but also it is based in specific location, in order to provide lower latency for users in the same region. This approach grants better performance to the users connected to the shard in their region, but also restricts them to communicate with other users only in the same shard. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/Sharding.pdf} - \caption{Sharding approach} - \label{fig:sharding} -\end{figure} - -Since Internet is a global network, sharding has proven to be a very useful technique for distribution of web-based application all over the world. Although users in different shards can not communicate with each other, they receive the same service, due to the replication of business and data storage tiers. Replicating those layers also guarantees that deployment of new version or updates of the application will be spread among all shards, thus increasing scalability of the application. - -Nevertheless, a downside of this approach is separation and isolation of users in different shards. In applications requiring information sharing among very large amount of users per shard, sharding by its own can not solve the problem with distributing server load. Additional mechanisms have to be combined together, in order to achieve better performance. - -\subsection{Cloning} - -Another approach for distributing server load among different machines is the so called \textit{cloning}. It is similar to sharding, due to replication of server code on different machines, but this mechanism requires synchronization between them. The data storage tier might or might not be distributed, but always provides the same data to each server copy. - -Synchronization between server copies can be achieved by using different \textit{network topologies} (\cite{DBLP:books/lib/TanenbaumW11}), each of which brings positives and negatives to the whole system, which have to be considered when the topology is getting chosen. An example of cloning technique with ring topology is shown on Figure \ref{fig:cloning}. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/Cloning.pdf} - \caption{Cloning approach} - \label{fig:cloning} -\end{figure} - - -By synchronizing server copies, users connected to one server copy are able to communicate with users, connected and managed by another server copy, making the users to experience the service like they are connected to one monolithic server. This reduces the load on single machines, but increases the network load, due to additional synchronization messages between server copies, which also increases the complexity of the whole application. - -\subsection{Zoning} -\label{ssec:Zoning} - -\textit{Zoning} is an approach for distributing servers, which in contrast to sharding and cloning techniques, is used whenever a virtual world is handled by the server logic. This technique breaks down this virtual world into regions, also called zones. Each zone is handled by different server and therefore experience different load, depending on the amount of users currently connected to a zone. Since zones have static borders, they have to be divided in a way, that balances the load of the whole application, in other words, zones might need to have different dimensions, in order to restrict the maximum amount of concurrent users per zone. - -Furthermore, zones can be implemented in a way that restricts users from one zone to communicate with users from another zone. This means that zones, although serving different parts of the virtual world, are implemented more or less as shards, and therefore making the zone boundaries opaque, thus constraining users to receive any updates from outside the zone. Nonetheless implementations of zoning approach allowing for transparent boundaries exist. Zoning implementations allowing transparent boundaries require additional synchronization about users and objects, close to zone boundaries, among adjacent zones. We discuss such approach in section \ref{AdvancedDistributedArchitectures}. - -In general zoning approach introduces logical separation of server load by means of virtual world partitioning. Visual representation of the basic zoning mechanism is shown on Figure \ref{fig:zoning}. - -\begin{figure} - \includegraphics[width=\textwidth]{gen/Zoning.pdf} - \caption{Zoning approach} - \label{fig:zoning} -\end{figure} - -Additional algorithms can be combined together with zoning approach in order to reduce the server load. An example of such algorithms is the \textit{Zoom-in-zoom-out} algorithm, present in \cite{DBLP:journals/cn/LeeKC05}, whose main goal is to minimize the distance between users in different zones, or in other words, to reduce the synchronization delay caused due to additional synchronization of non-adjacent zone servers. This algorithm perform four steps in total: - -\begin{enumerate} - \item Allocation of each client to the closest server - \item Find the \textit{core server}, i.e. the one that minimizes the distance to all clients - \item (\textit{Zoom-in}) transfer a client to another server, if and only if the new server is the closest from the core server and the synchronization delay is still in defined boundaries - \item (\textit{Zoom-out}) transfer a client to another server, if and only if the new server is the farthest from the current one and the synchronization delay is still in defined boundaries -\end{enumerate} - -This algorithm finds application not only in combination with zoning approach, but can also be helpful whenever cloning and instancing techniques are used, in order to provide better performance for users, regularly communicating with each other. - -\subsection{Instancing} - -\textit{Instancing} is very similar to sharding on a virtual level. Therefore it requires pre-divided virtual world in zones, room, etc., which can later be instanced. When a zone has several instances, this means that several virtual zones are created, all hosting the same map data, but completely unlinked with each other, thus isolating the users inside each instance. Unlike in zoning approach, where users can transfer from a zone to another, instances do not share borders. Each instance might be a new virtual world, thus users residing in one instance do not even know about the existence of another instance. - -Instancing seems to be very useful, when controlled environment inside a virtual world is necessary. In game industry, instancing finds great application in \textit{private rooms}. Those rooms serve limited amount of users, that meet a requirement, for example a password has to be known or a specific gaming criterion has to be met, for example player's level has to be above certain threshold, in order to \textit{unlock} the room. - -Apart of static instantiation of zones, instancing can be applied when dynamic instances are necessary. In case of gathering of many users in the same zone, which inflict a very high server load, instances of the same zone can be dynamically created, in order to split the users, hence reducing the server load. - -Whenever there are lots of instanced zones, in which only a small amount of users resides, one server can be assigned to handle several instances. This is the opposite of the approaches for reducing server load, rather increasing the effective usage of each server machine. - -\section{Advanced distributed architectures} \label{AdvancedDistributedArchitectures} - -In this section we discuss several concepts of distributed architectures in combination with distributed mechanisms. - -\subsection{Proxy-server architecture} - -M{\"u}ller and Gorlatch in \cite{DBLP:conf/gi/MullerG04} present an innovative hybrid architecture style combining both client/server and peer-to-peer architectures together with cloning technique. The idea behind their architecture is to provide standard connection between clients and server, distributing server code on several machines and using proxy layer to provide faster user connection. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/ProxyServer.pdf} - \caption{Proxy-server architecture} - \label{fig:ProxyServer} -\end{figure} - -As we can see, the architecture shown on Figure \ref{fig:ProxyServer} is consisted of several layers. The outermost layer is the client tier, followed by the proxy layer, whose main goal is to provide fastest possible connection for users, depending on their ISP\footnote{Internet Service Provider}, or in other words, users will connect to the proxy server, which is maintained by the same or the closest ISP, which will provide faster connection due to a shorter package route. - -The next layer is the business logic tier together with data storage. In this layer game logic together with according database is replicated on different machines. Each of those cloned machines has all the data necessary to keep an instance of the whole virtual world, in order to eliminate transfer time, which is common for architectures using zoning approach. Since the virtual world is not divided in zones and virtual worlds maintained by each machines are not separated instances, the only synchronization, necessary to preserve massive multiplayer concept, i.e. allowing clients connected to one server to interact and communicate with clients connected to another server, has to be made between the servers. Synchronization is done by connecting all server machines with each other, in an inner network, using peer-to-peer architecture, which provides very fast connection, but increases the network load. However, since one server can handle many users, the inner network remains very small, thus network load is preserved low. - -Synchronization here is done by sending updates between server machines. When a server changes its local state, due to user action, it has to send an update to all other servers, so they can update their local state. A \textit{tickrate}\footnote{frequency at which state updates are calculated and sent} $t$ has to be defined, so at any $1/t$ seconds each server sends and receives updates to/from all other servers in the inner network. The synchronization flow of the whole architecture is as follows: - -\begin{enumerate} - \item Client(s) submit an action to the server it is connected to - \item The server validates those actions. - \begin{itemize} - \item If unallowed action has been submitted, the server rejects it and notifies the user. - \item Otherwise, the server updates its local game state, sends acknowledgment message to the user and proceeds to the next step - \end{itemize} - \item On the next \textit{tick} all the updates submitted by users in the interval between last tick and current time are sent to all servers in the inner network. - \item When an update from other server is received, each server updates its local game state and checks for interactions. - \item The result of interaction evaluation is sent back as a new update to all servers within the inner network. - \item Each server multicasts its updated local state to the affected users, within its network. -\end{enumerate} - -Better security, preserved centralized authority, better user management, low network load and low latency, thus high performance, due to client/server architecture, together with fast synchronization between servers, due to peer-to-peer inner network provides one very good environment even for \textit{first person shooter} games. Robustness as well as scalability is very high, due to the combination of both architecture styles. However cloning approach with extremely big virtual world might not work well, due to the high hardware requirements of the servers, necessary to maintain the whole virtual world on each machine. Although synchronization mechanism is well designed, consistency may be broken, if the size of update packages becomes too big, due to handling very wide virtual worlds. - -As an additional advantage, the authors have also mention that their approach allows for forecasting the number of proxy servers necessary to handle certain amount of users. - -\subsection{Distributed architecture combined with zoning technique} - -In \cite{DAfMMO-RPG} an innovative distributed client/server architecture for MMO gaming, using zoning technique is presented. The idea of this architecture is that the virtual world, which is about to be handled and maintained by the server, is first split on zones (regions), each of which is handled by a single server machine. An example of this architecture is shown on Figure \ref{fig:DistributedZoning}. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/DistributedZoning.pdf} - \caption{Distributed architecture based on zoning approach} - \label{fig:DistributedZoning} -\end{figure} - -In order to provide the massiveness necessary for MMO additional server synchronization is necessary. It is done using the publish/subscribe technique (also known as the \textit{Observer} pattern \cite{fowler2003patterns}), visual representation of which is shown on Figure \ref{fig:PublishSubscribe}. Each server, subscribes to receive updates from each of its neighbor servers, about events, happening close to the borders. This subscription works like a client/server connection, between the subscriber (client) and publisher (server) machine. Whenever an event is triggered close to the border areas, the server, which handles current region, notifies all subscribers about the event. So when a server receives notifications from other server, to which it is subscribed, it evaluates the updates and notifies the according users. - -\begin{figure}[h] - \includegraphics[width=\textwidth]{gen/PublishSubscribe.pdf} - \caption{Publish-subscribe pattern} - \label{fig:PublishSubscribe} -\end{figure} - - -The authors mention four cases, in which their synchronization mechanism has to work, in order to provide fully synchronized distributed virtual world, are defined as follows: - -\begin{enumerate} - \item A player residing in one server and staying close to its border must be able to receive events, which occur in the area from the other side of the border, which is handled by another server. This must be handled even when several servers share a border. - \item When a player is moving from one zone to another, its state has to be transferred correctly and smoothly to the next server, which handles the region the player steps into. - \item An event about an object, that originates in one zone, but ends its movement (action) in another zone, has to be transferred from the server triggering the start event to the server which is about to finalize the event. This scenario is close to scenario 2, but it affects dynamic objects, rather than players, for example bullets shot by a player residing in one area, but aimed at another. - \item When an event, triggered close to borders, may simultaneously affect several adjacent zones, it has to be spread among the server handling those regions. For example a bomb is exploding close to the border of one zone, but affecting all the objects in certain radios around it, independent of the zones they reside in. -\end{enumerate} - -The first problem is solved by subscribing servers to their neighboring servers. This way, when a player residing in one zone, needs to receive updates about an area, handled by another server, the server handling the region the player is located in sends the necessary updates to the player, when notifications from the neighbor server (publisher) are received. The user does not know about inter-server connection, and when this connection is fast, the user experience is preserved high. - -The second problem is based on the solution of the first one. However, when a player is crossing the border between two regions, the server which handled the player until now, notifies the next server, that it has to handle this player from now on, using the already established two-way connection. The transition from one region to another from players view is preserved smooth, when the connection between servers is fast and since only one additional message has to be sent, in order a transfer to be realized. - -The third problem is more or less a specific case of the second problem. However, it occurs only when objects are created in one region, and moved to another. In this case two events have to occur. The first one is the beginning of the movement of the object, which is received by the server-subscriber, which can now predict the trajectory and landing position of the object, by evaluating the event data. The second event is received by the server, in which the object will end its movement, in the moment when this object is crossing the border. By evaluating this event data, the server, which now handles the object, has to chose which trajectory and landing position to choose. The chosen calculation is normally the one with shorter (faster) trajectory. - -The last problem can affect more than two adjacent servers. Therefore, when an event is triggered, the servers, which are affected, are combined in pairs of \textit{primary} and \textit{secondary} servers. The primary server, usually the one with the lowest ID, is responsible of ordering the shared events, which each server handles its own local events. Whenever a shared event occurs on the primary server, the server executes the event and notifies the secondary server(s). However, if a shared event occurs on the secondary server, to preserve serializability, the secondary server notifies the primary server about the event and waits until it sends a notification back, allowing for execution of the event. This technique adds additional latency only if shared events happen on secondary servers, and the latency is equal to the cost of a round-trip inter-server communication message. - -Fault tolerance in for this architecture is done by making each server to keep a log of occurred events. This grants the possibility to replay events in order to recover the state of the server. - -This architectural approach shows very good performance and allows many users to be handled, without reducing the user experience. Also the bandwidth is smaller than the one in proxy-network architecture, discussed in the previous section. However, fault-tolerance is still an issue, on which additional work has to be done to optimize it. - -%Add Model-View-Controller section !!! -\section{Model-View-Controller pattern} - -Model-View-Controller (\cite{gamma1995design}) is a software architectural pattern commonly used in applications providing \textit{user interface}. The main idea of the pattern is to separate the way information is represented to the client from the internal data representation in an application. Basic MVC representation is shown on Figure \ref{fig:MVC}. - -\begin{figure}[h] - \centering\includegraphics[width=.5\textwidth]{gen/MVC.pdf} - \caption{Model-View-Controller} - \label{fig:MVC} -\end{figure} - -MVC splits the structure of an application in three base component types: -\begin{itemize} - \item Model - responsible for managing the application's data, business logic and rules as well as expressing the application's behavior and updating the view component - \item View - responsible for presenting information to the user as well as providing visual controls, such as buttons, text fields, etc., by means of which the user would be able to interact with the application via the controller component - \item Controller - responsible for handling user actions and propagating consequential events to the model component -\end{itemize} - -Although MVC pattern seems to be mostly applicable for client applications, it can be easily adapted to a client/server architecture design by redefining the Model, View and Controller components in a higher level. An example for such usage is the \textit{Spring Framework} and in particular \textit{Spring MVC} (\cite{walls2015spring}). In this notion, MVC is used whenever \textit{Web Services} need to be implemented, by defining the view as web-resource (e.g. web page), the model as the data provided by the server to the client and the controller as the web-services controller, responsible for handling incoming client requests. - -By decoupling representation from data model and business logic, MVC successfully applies the \textit{Separation of Concerns} principle (\cite{DBLP:books/daglib/0067388}), and therefore helps improving code readability and maintainability, thus allowing code reuse and parallel programming to be applied in the development process. \ No newline at end of file