Added more stuff

src/bib/mybib.bib

@@ -148,3 +148,135 @@
   howpublished={\url{https://dataplace.com/en/connectivity/edge-computing}}
   note = {Hozzáférve: 2021-05-14}  
 }
+
+@misc{cloudflare_price_of_bandwidth,
+  title={The Relative Cost of Bandwidth Around the World},
+  author={Matthew Prince},
+  howpublished={\url{https://blog.cloudflare.com/the-relative-cost-of-bandwidth-around-the-world/}}
+  note = {Hozzáférve: 2021-05-16}
+}
+
+@misc{server_location_matters,
+  title={How server location affects latency?},
+  author={Zain Imran},
+  howpublished={\url{https://www.cloudways.com/blog/how-server-location-affects-latency/}}
+  note = {Hozzáférve: 2021-05-16}
+}
+
+
+@article{liu2019edge,
+  title={Edge computing for autonomous driving: Opportunities and challenges},
+  author={Liu, Shaoshan and Liu, Liangkai and Tang, Jie and Yu, Bo and Wang, Yifan and Shi, Weisong},
+  journal={Proceedings of the IEEE},
+  volume={107},
+  number={8},
+  pages={1697--1716},
+  year={2019},
+  publisher={IEEE}
+}
+
+@article{hao2020cloud,
+  title={Cloud platforms for remote monitoring system: a comparative case study},
+  author={Hao, Yuqiuge and Helo, Petri and Gunasekaran, Angappa},
+  journal={Production Planning \& Control},
+  volume={31},
+  number={2-3},
+  pages={186--202},
+  year={2020},
+  publisher={Taylor \& Francis}
+}
+
+@article{wang2020secure,
+  title={Secure healthcare monitoring framework integrating NDN-based IoT with edge cloud},
+  author={Wang, Xiaonan and Cai, Shaohao},
+  journal={Future Generation Computer Systems},
+  volume={112},
+  pages={320--329},
+  year={2020},
+  publisher={Elsevier}
+}
+
+@article{edge_companies,
+  title={60 Edge computing companies to watch in 2021},
+  author={Dalia Adib},
+  howpublished={\url{https://stlpartners.com/edge-computing/edge-computing-companies-to-watch-2021/}}
+  note = {Hozzáférve: 2021-05-18}
+}
+
+@article{edge_gaming,
+  title={The future of cloud gaming is on the Edge},
+  author={Greg Elliott},
+  howpublished={\url{https://www.datacenterdynamics.com/en/opinions/future-cloud-gaming-edge/}}
+  note = {Hozzáférve: 2021-05-18}
+}
+
+@article{shi2016edge,
+  title={Edge computing: Vision and challenges},
+  author={Shi, Weisong and Cao, Jie and Zhang, Quan and Li, Youhuizi and Xu, Lanyu},
+  journal={IEEE internet of things journal},
+  volume={3},
+  number={5},
+  pages={637--646},
+  year={2016},
+  publisher={IEEE}
+}
+
+
+@misc{kubernetes_docs,
+	author = {Google},
+	title = {Kubernetes Documentation},
+	howpublished = {\url{https://kubernetes.io/docs/home/}},
+	note = {Accessed: 2020-05-09}
+}
+
+@misc{docker_docs,
+	author = {},
+	title = {Docker Documentation},
+	howpublished = {\url{https://docs.docker.com/}},
+	note = {Accessed: 2020-05-09}
+}
+
+@misc{kubeedge_docs,
+	author = {},
+	title = {KubeEdge Documentation},
+	howpublished = {\url{https://kubeedge.io/en/docs/}},
+	note = {Accessed: 2021-05-19}
+}
+
+@misc{edgexfoundry_docs,
+	author = {},
+	title = {EdgeX Foundry DocumentationIntroduction},
+	howpublished = {\url{https://docs.edgexfoundry.org/}},
+	note = {Accessed: 2020-05-09}
+}
+
+@misc{microservices,
+	author = {Tom Huston},
+	title = {What is Microservices?},
+	howpublished = {\url{https://smartbear.com/solutions/microservices/}},
+	note = {Accessed: 2020-05-09}
+}
+
+
+@misc{application_containers,
+	author = {Suzanne Ferry},
+	title = {Overview of Application Containers},
+	howpublished = {\url{https://mapr.com/blog/overview-of-application-containers-part-1-of-4/}},
+	note = {Accessed: 2020-05-09}
+}
+
+
+@misc{aas,
+	author = {Stephen Watts and Muhammad Raza},
+	title = {SaaS vs PaaS vs IaaS: What’s The Difference and How To Choose},
+	howpublished = {\url{https://www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose/}},
+	note = {Accessed: 2020-05-09}
+}
+
+
+@techreport{containermarketshare,
+	title = {Application Container Market by Service (Container Monitoring, Security, Data Management, Networking, Orchestration), Platform (Docker, Kubernetes), Application Area, Deployment Mode, Organization Size, Vertical, and Region - Global Forecast to 2023},
+	url = {https://www.marketsandmarkets.com/Market-Reports/application-container-market-182079587.html},
+	institution = {Markets and Markets},
+	year = {2018}
+}

src/content/glossary.tex

@@ -88,16 +88,39 @@
 \newglossaryentry{elasztikus}
 {
 	name={elasztikus},
-	description={}
+	description={TODO}
 }
 
 
 \newglossaryentry{lastmile}
 {
 	name={utolsó mérföld},
-	description={}
+	description={TODO}
 }
 
+\newglossaryentry{felho}
+{
+	name={felhő},
+	description={TODO}
+}
+
+\newglossaryentry{linux}
+{
+	name={Linux},
+	description={A Linux egy nylílt forráskdú kernel implementáció. A projekt Linus Benedict Torvalds (akkor) finn egyetemi hallgató hobbi projektjeként indult. Mára a vlág legnépszerűbb nyíltforráskódú projektje}
+}
+
+\newglossaryentry{python}
+{
+	name={Python},
+	description={A Python egy általános célú, magas szintű interpretált programozási nyelv. Fejlesztését 1989-ben kezdte Guido van Rossum}
+}
+
+\newglossaryentry{devops}
+{
+	name={DevOps},
+	description={Developement and Operations (Fejlesztés és Operálás) egy vállalati szoftverfejlesztési kifejezés, amely az egyfajta agilis összeköttetést jelent a fejlesztés és üzemeltetés között. A DevOps célja az, hogy közelebb hozza ezt a két vállalati egységet.}
+}
 
 
 \newacronym{mdt}{MDT}{Model-Driven Telemetry}
@@ -156,4 +179,17 @@
 \newacronym{ciscoie}{Cisco-IE}{Cisco Innovation Edge}
 \newacronym{oid}{OID}{Object Identifier}
 \newacronym{ann}{ANN}{Artificial Neural Network}
-\newacronym{nms}{NMS}{Network Management Station}
+\newacronym{nms}{NMS}{Network Management Station}
+\newacronym{saas}{SaaS}{Software as a Service}
+\newacronym{paas}{PaaS}{Platform as a Service}
+\newacronym{iaas}{IaaS}{Infrastructure as a Service}
+\newacronym{faas}{FaaS}{Function as a Service}
+\newacronym{svm}{SVM}{Support Vector Machines}
+\newacronym{knn}{kNN}{k Nearest Neighbor}
+\newacronym{rest}{REST}{Representational State Transfer}
+\newacronym{vm}{VM}{Virtual Machine}
+\newacronym{nat}{NAT}{Network Address Translation}
+\newacronym{pv}{PV}{Persistent Volume}
+\newacronym{nfs}{NFS}{Network File System}
+\newacronym{yaml}{YAML}{YAML Ain't Markup Language}
+\newacronym{wsgi}{WSGI}{Web Server Gateway Interface}

src/content/overview.tex

@@ -1,30 +1,72 @@
 % !TeX root = ../thesis.tex
 %----------------------------------------------------------------------------
-\chapter{Áttekintés a perem és felhő rendszerekről}
+\chapter{Áttekintés a perem és \gls{felho} rendszerekről}
 %----------------------------------------------------------------------------
 
-\section{Tradicionális megközelítés} % Egy kis áttekintés a "tradícionális felhőről"
+
+% TODO: bevezetés
+
+\section{Klasszikus \gls{felho}s megközelítés} % Egy kis áttekintés a "tradícionális felhőről"
 \label{sec:tradicionalis_megkozelites}
 
-Általánosságban véve az informatikában akkor beszélhetünk felhőről, amikor egy adott alkalmazást általunk üzemeltetett infrastruktúra helyett egy távoli szolgáltató által fenntartott környezetben futtatunk\cite{what_is_cloud}. A tradicionális megközelítés szerint ezek a környezetek az üzemeltetéséhez szükséges infrastruktúra egy vagy több -- a szolgáltató által üzemeltetett -- \gls{adatkozpont}ban foglal helyet.
+\subsection{Általánosságban a \gls{felho}ről}
 
-A felhőszolgáltatások alkalmazásának több előnye is van, ezekből talán a legfontosabbak az
+Általánosságban véve az informatikában akkor beszélhetünk \gls{felho}ről, amikor egy adott alkalmazást általunk üzemeltetett infrastruktúra helyett egy távoli szolgáltató által fenntartott környezetben futtatunk\cite{what_is_cloud}. A tradicionális megközelítés szerint ezek a környezetek az üzemeltetéséhez szükséges infrastruktúra egy vagy több -- a szolgáltató által üzemeltetett -- \gls{adatkozpont}ban foglal helyet.
+
+A \gls{felho}szolgáltatások alkalmazásának több előnye is van, ezekből talán a legfontosabbak az
 általános hardverelemek használatára visszavezethető alacsonyabb beruházási költség és az automatizált
 folyamatok biztosította alacsonyabb üzemeltetési költség\cite{costofcloud}. Ezzel leveszi az üzemeltetés terhét és költségét az alkalmazás fejlesztőinek válláról.
 
-Gyakran a felhőszolgáltató egynél több \gls{adatkozpont}ot tart fenn, amelyeket a világ több pontján helyeznek el. Ezzel biztosítva redundanciát, magasabb rendelkezésre állást és hatékonyabb elérést\cite{geodist}.
+Gyakran a \gls{felho}szolgáltató egynél több \gls{adatkozpont}ot tart fenn, amelyeket a világ több pontján helyeznek el. Ezzel biztosítva redundanciát, magasabb rendelkezésre állást és hatékonyabb elérést\cite{geodist}.
 
-Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a felhő szolgáltatások nyújtotta előnyöket és alkalmazásaiknak már 83\%-a valamilyen felhő környezetben futnak\cite{cloudadpotation}.
+A felhő architektúráknak több modelljét is megkülönböztetjük. Ezeket pedig aszerint osztályozhatjuk, hogy mekkora kontrollt adnak a felhasználónak a futó alkalmazás felett. Ennek a kontrollnak a legalacsonyabb szintjén van az úgy nevezett \acrfull{saas} (Szoftver mint szolgáltatás) amely egy előre telepített szoftver eszközt biztosít a szolgáltató \gls{felho} környezetében amelyet általában a felhasználó az interneten keresztül ér el. Legmagasabb szintjén pedig a \acrfull{iaas} foglal helyet, ahol az alapvető infrastruktúrát készen kapjuk, de minden mást a szolgáltatás felhasználójának kell megterveznie, feltelepíteni, konfigurálni és üzemeltetni \cite{aas}.
 
-Amellett, hogy az felhőszolgáltatások adaptációja növekvő tendenciát mutat. Az internetre kapcsolt eszközök száma is szépen gyarapodik\cite{annualinternetreport}. Ehhez a felhasználói készülékek mellett jelentősen hozzájárul az utóbbi időben jelentős fejlődésnek örvendő \acrfull{iot} rendszerek egyre nagyobb mértékű alkalmazása\cite{iotadpotation}.
+Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a \gls{felho} szolgáltatások nyújtotta előnyöket és alkalmazásaiknak már 83\%-a valamilyen \gls{felho} környezetben futnak\cite{cloudadpotation}.
 
-Ezek alapján a felhő szolgáltatásokat nyújtó \gls{adatkozpont}ok kapacitásukat mind számítási teljesítményben, mind rendelkezésre álló sávszélességre való tekintettel egyre növekvő elvárással szembesülnek. Mindazonáltal a \gls{vegeszkoz}öket összekötő hálózatok is jelentősen növekvő igényeknek néznek elébe. Mindeközben pedig egyre nagyobb igény mutatkozik arra, hogy az alkalmazásaink jó válaszidővel, alacsony késleltetéssel működjenek\cite{stateofart}.
+Amellett, hogy az \gls{felho}szolgáltatások adaptációja növekvő tendenciát mutat. Az internetre kapcsolt eszközök száma is szépen gyarapodik\cite{annualinternetreport}. Ehhez a felhasználói készülékek mellett jelentősen hozzájárul az utóbbi időben jelentős fejlődésnek örvendő \acrfull{iot} rendszerek egyre nagyobb volumenű alkalmazása\cite{iotadpotation}.
+
+Ezek alapján a \gls{felho} szolgáltatásokat nyújtó \gls{adatkozpont}ok kapacitásukat mind számítási teljesítményben, mind rendelkezésre álló sávszélességre való tekintettel egyre növekvő elvárással szembesülnek. Mindazonáltal a \gls{vegeszkoz}öket összekötő hálózatok is jelentősen növekvő igényeknek néznek elébe. Mindeközben pedig egyre nagyobb igény mutatkozik arra, hogy az alkalmazásaink jó válaszidővel, alacsony késleltetéssel működjenek\cite{stateofart}.
+
+
+\subsection{Felhős alkalmazásüzemeltetési eszközök}
+
+\subsubsection{Alkalmazás Konténer}
+
+Egy alkalmazás konténer általánosságban egy önálló csomag, amely tartalmazza a futtatni kívánt alkalmazást és a futtatásához szükséges szoftver környezetet. A konténerek használata jelentősen megkönnyíti és meggyorsítja az alkalmazás fejlesztési és telepítési ciklust. Mivel magába foglalja a teljes környezetet, amely szükséges a futtatáshoz, így a szoftver  ugyanúgy fut a fejlesztők számítógépein, a tesztkörnyezetben és az éles környezetben is \cite{application_containers}.
+
+Az alkalmazás konténerek koncepciójának megvalósítására egy népszerű implementáció a \textit{Docker}, amely a \gls{linux} kernelben található izolációs szolgáltatásokra épít. Ezzel valósítja meg, hogy a konténerek egymástól független környezetben tudjanak futni. Egyetlen szoftver erőforrás, amin közösen osztoznak az a kernel maga.
+
+Dockerben az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépekhez képfájlaihoz képest kisebb méretűek. Ezeket a képfájlokat az alkalmazás fejlesztése után készítjük és az alkalmazás konténer indításához használjuk \cite{docker_docs}.
+
+\subsubsection{Kubernetes}
+
+Manapság egyre jobban terjed a konténer alapú szoftver fejlesztés és a felhő alapú megoldások\cite{containermarketshare}. Az egyik legnépszerűbb ilyen felhő implementáció a \textit{Kubernetes}. A \textit{Kubernetes} egy konténer orkesztrációs platform, amely felügyeli és kezeli az egyes alkalmazásokat vagy szolgáltatásokat megvalósító konténerek életciklusát egy multihoszt környezetben.
+
+Az életciklus kezelés mellett több hasznos szolgáltatást is nyújt. Ilyenek az automatikus szolgáltatás felderítés és terhelés elosztás, tárhely orkesztráció, konfiguráció kezelés. Bizonyos, megfelelően felkonfigurált helyzetekben a \textit{Kubernetes} képes alapszintű hibajavításra is, bizonyos szolgáltatások programozott újraindításával.\cite{kubernetes_docs}
+
+Kubernetes klaszternek nevezzük azt a multihoszt környezetet, ahol több -- egymással hálózatba kötött -- számítógép (fizikai vagy virtuális) valósítja meg a \textit{Kubernetes} környezetet.
+
+A klaszteren belül két jól elkülöníthető szerepkört definiálunk, ezek a master (mester) és a worker (munkás) szereprek. A master felel az erőforrások elosztásáért, a konténerek workerhez rendeléséért és összességében a klaszter irányításáért. A workerek felelnek a konkrét alkalmazásunkhoz tartozó konténerek futtatásáért. 
+
+Egy \textit{Kubernetes} környezetben különböző objektumokat definiálunk, amelyekkel le írhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezek az objektumok közül a legkisebb kezelhető egység a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos névtereken, ilyen a hálózati vagy a folyamatok névtere.
+
+Eggyel \enquote{nagyobb} objektum ezeknél a \textit{Deployment}, a \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le. A \textit{Kubernetes} klaszter törekszik a \textit{Deployment}ben megfogalmazott állapot elérésére és fenntartására.
+
+\subsubsection{Mikroszolgáltatások}
+
+A mikroszolgáltatás modell egy újkeletű architekturális megközelítés a szoftver fejlesztésben. Ebben a megközelítésben egyfunkciós modulokat tervezünk és fejlesztünk, amelyek jól definiált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával kommunikálnak egymással\cite{microservices}. Ennek hála, amíg egy komponens teljesíti az elvárt \acrshort{api} definíciót, addig szabadon kicserélhető
+
+Az egységek a fejlesztése, és tesztelése sokkal gyorsabb ütemben tud haladni a kisebb kódbázis miatt. A rajtuk eszközölt fejlesztések sokkal hamarabb kerülhetnek ki az éles rendszerbe, hiszen a változtatásuk nem érinti a teljes rendszert, ezért könnyebb őket frissíteni, vagy valamilyen szélsőséges esemény hatására visszaállni egy korábbi változatra.
+
+Mikroszolgáltatásokkal az alkalmazások skálázása is jelentősen leegyszerűsödik. Míg egy monolit rendszerben a teljes alkalmazást skálázni kellett, ha nagyobb teljesítményre volt szükség, itt -- feltéve, hogy tisztában vagyunk vele, hogy mely komponensek jelentik a szűk keresztmetszetet -- elég csak a megfelelő szolgáltatásokat.
+
+A mikroszolgáltatásoknak további előnyös jellemzője, hogy az egyes komponensek teljesen egyedül kezelik a saját belső adatstruktúrájukat. Az egyetlen kompatibilitási réteg, amelyet biztosítaniuk kell az az \acrfull{api} interfész. A mikroszolgáltatások teljesen szabadon változtathatják a belső struktúrájukat akár verziók között is. De nem csak az adatstruktúrával szemben van ekkora szabadságunk, hanem akár a különböző programnyelvekkel is.
 
 
 \section{Peremhálózati rendszerek} % Szóval itt felvezetem hogy van ez a perem meme
+\label{sec:peremhalozati_rendszerek}
 
-
+A \gls{felho}-számítástechnika tradicionális megközelítésben való alkalmazásában jelentős hatékonysági kérdések merülnek fel. Mint ahogy azt \aref{fig:overview_no_edge}.\ ábra is szemlélteti, ha az egyes \gls{vegeszkoz}ök közvetlenül kommunikálnak a \gls{felho}szolgáltatást nyújtó \gls{adatkozpont}tal, az lineárisan növekvő terhelést jelent, mind a köztes hálózatnak, mint az \gls{adatkozpont}nak. Emellett a megtett távolság miatt a késleltetés is növekszik.
-Az előző szekcióban ismertetésre került néhány probléma a felhő-számítástechnika tradicionális alkalmazásával. Mint ahogy azt \aref{fig:overview_no_edge}.\ ábra is szemlélteti, ha az egyes \gls{vegeszkoz}ök közvetlenül kommunikálnak a felhőszolgáltatást nyújtó \gls{adatkozpont}tal, az lineárisan növekvő terhelést jelent, mind a köztes hálózatnak, mint az \gls{adatkozpont}nak. Emellett a megtett távolság miatt a késleltetés is növekszik.
 
 \begin{figure}[h!]
 	\centering
@@ -39,92 +81,94 @@ A fent vázolt problémákra megoldást ígér a peremhálózati rendszerek alka
 
 \subsection{Használt fogalmak}
 
-A peremhálózat pontos definiálása egyelőre nem teljesen tisztázott mivel nem is egy egyszerű kérdés\cite{cureforedge, cloudflare_whatisedge}. Egyes források szerint a peremhálózatit számítástechnika az magukon a \gls{vegeszkoz}ökön futtatott alkalmazások\cite{verge_whatisedge}, míg más források a felhő és a \gls{vegeszkoz}ök között elhelyezkedő számítási környezetre hivatkoznak így\cite{ibm_whatisedge}, illetve vannak források amelyek a határokat teljesen elmosva mindkettőt értelmezik\cite{cb_whatisedge, dataplace_whatisedge}
+A peremhálózat pontos definiálása egyelőre nem teljesen tisztázott mivel nem is egy egyszerű kérdés\cite{cureforedge, cloudflare_whatisedge}. Egyes források szerint a peremhálózati számítástechnika az magukon a \gls{vegeszkoz}ökön futtatott alkalmazások\cite{verge_whatisedge}, míg más források a \gls{felho} és a \gls{vegeszkoz}ök között elhelyezkedő számítási környezetre hivatkoznak így\cite{ibm_whatisedge}, illetve vannak források amelyek a határokat teljesen elmosva mindkettőt értelmezik\cite{cb_whatisedge, dataplace_whatisedge}
 
-A fogalom -- és a kapcsolódó fogalmak -- tisztázására és egységesítésére a \textit{Linux Foundation} egy nyitott szójegyzéket hozott létre "\textit{Open Glossary of Edge Computing}" néven. Ezt a szabadon elérhető szójegyzéket egyre több gyártó ismeri el és használja\cite{openglossary}. 
+A fogalom -- és a kapcsolódó fogalmak -- tisztázására és egységesítésére a \textit{Linux Foundation} egy nyitott szójegyzéket hozott létre "\textit{Open Glossary of Edge Computing}" néven\footnote{\url{https://www.lfedge.org/openglossary/}}. Ezt a szabadon elérhető szójegyzéket egyre több gyártó ismeri el és használja\cite{openglossary}. 
 
 A szójegyzék jelenlegi (2.0-ás verzió) kiadása alapján néhány fontosabb fogalmat az alábbiak szerint definiálhatunk:
 \begin{itemize}
-	\item \textbf{Cloud Computing} (Felhő számítástechnika): Egy olyan rendszer, amely igény-vezérelt hozzáférést biztosít megosztott erőforrásokhoz, beleértve a hálózatot tárolást és számítási kapacitást. Tipikusan kevés számú de nagy méretű regionális \gls{adatkozpont}okat használva.
+	\item \textbf{Cloud Computing} (\Gls{felho} számítástechnika): Egy olyan rendszer, amely igény-vezérelt hozzáférést biztosít megosztott erőforrásokhoz, beleértve a hálózatot tárolást és számítási kapacitást. Tipikusan kevés számú de nagy méretű regionális \gls{adatkozpont}okat használva.
 	
 	\item \textbf{Edge Computing} (Perem számítástechnika): A számítási kapacitás eljuttatása hálózat logikai végleteibe, annak érdekében hogy ezzel növeljék a teljesítményt, csökkentsék a működtetési költségeket illetve növeljék a rendelkezésre állását a biztosított alkalmazásoknak és szolgáltatásoknak. [\dots]
 	
-	\item \textbf{Edge Cloud} (Perem felhő): Felhő-szerű képességek az infrastruktúra peremén amely -- a felhasználó perspektívájából -- hozzáférést enged \gls{elasztikus}an allokált számítási, adat tárolási és hálózati erőforrásokhoz. Többnyire észrevétlenül szolgál a centralizált privát- vagy publikus felhő kiterjesztéseként. A hálózat peremén telepített mikro-\gls{adatkozpont}okból épül fel. Időnként elosztott perem-felhőként hivatkoznak rá.
+	\item \textbf{Edge Cloud} (Perem \gls{felho}): \Gls{felho}-szerű képességek az infrastruktúra peremén amely -- a felhasználó perspektívájából -- hozzáférést enged \gls{elasztikus}an allokált számítási, adat tárolási és hálózati erőforrásokhoz. Többnyire észrevétlenül szolgál a centralizált privát- vagy publikus \gls{felho} kiterjesztéseként. A hálózat peremén telepített mikro-\gls{adatkozpont}okból épül fel. Időnként elosztott perem-\gls{felho}ként hivatkoznak rá.
 	
 	\item \textbf{Edge Data Center} (Perem-\gls{adatkozpont}): Olyan \gls{adatkozpont} amelyet a mennyire csak lehet a hálózat pereméhez lehet telepíteni szemben a hagyományos \gls{adatkozpont}okkal. Képes arra, hogy ugyanazokat a szolgáltatásokat nyújtsa, de önmagában egy sokkal kisebb skálán. [\dots] A \textit{perem} itt a telepítés helyére hivatott utalni. [\dots] Több perem-\gls{adatkozpont} egymással közvetlen kapcsolatban állhat, hogy ezzel biztosítsanak nagyobb kapacitást, migrációt meghibásodás elkerülés vagy terhelés elosztás céljából egy nagy virtuális \gls{adatkozpont}ként funkcionálva.
 	
-	\item \textbf{Infrastructure Edge} (Infrastruktúra pereme): Számítási kapacitás a peremen tipikusan egy vagy több perem-\gls{adatkozpont} formájában megvalósítva, amelyet a szolgáltatói \gls{lastmile}ön telepítenek. Számítási, adattárolási és hálózati előforrások, amelyeket az infrastruktúra peremére telepítenek lehetővé teszi a felhőszerű szolgáltatások nyújtását, hasonlóképp mint a centralizált központi \gls{adatkozpont}okban. Ilyenek például az erőforrások \gls{elasztikus} allokációja. De mindezt alacsonyabb késleltetéssel és csökkentett adat továbbítási költségekkel, a magas fokú lokalizációnak köszönhetően szemben a centralizált vagy regionális \gls{adatkozpont}okkal.
+	\item \textbf{Infrastructure Edge} (Infrastruktúra pereme): Számítási kapacitás a peremen tipikusan egy vagy több perem-\gls{adatkozpont} formájában megvalósítva, amelyet a szolgáltatói \gls{lastmile}ön telepítenek. Számítási, adattárolási és hálózati előforrások, amelyeket az infrastruktúra peremére telepítenek lehetővé teszi a \gls{felho}szerű szolgáltatások nyújtását, hasonlóképp mint a centralizált központi \gls{adatkozpont}okban. Ilyenek például az erőforrások \gls{elasztikus} allokációja. De mindezt alacsonyabb késleltetéssel és csökkentett adat továbbítási költségekkel, a magas fokú lokalizációnak köszönhetően szemben a centralizált vagy regionális \gls{adatkozpont}okkal.
 	
 \end{itemize}
 
 \textbf{A dolgozat további részeiben ezek a fogalmak a mérvadóak} (kivéve ahol ez külön jelölve van).
 
-\subsection{Architektúra}
+\subsection{Architekturális előnyök} % TODO: cite
 
-% Ez a fenn említett fogalmak alapján egy konkrét képet alkot az emeberek fejében.
+Az előbbiek alapján ez a dolgozat peremhálózati \gls{adatkozpont}oknak azokat tekinti, amelyek logikailag -- és valamilyen szinten fizikailag is -- a \gls{felho} és a \gls{vegeszkoz}ök között helyezkednek el. Ezen a tartományon értelmezve "közel" áll a \gls{vegeszkoz}höz.
 
-% egy ilyen architektúrát mutat be az ábra
+Ezt a fajta logikai "közelség" úgy valósul meg, hogy az úton, amelyet egy hálózati üzenetnek be kell járnia a \gls{vegeszkoz}től a \gls{felho}ig, a peremhálózati \gls{adatkozpont}ot a lehető legközelebb igyekszünk helyezni a \gls{vegeszkoz}höz. Következésképp egy hálózati csomagnak jelentősen rövidebb utat kell bejárnia a peremhálózati \gls{adatkozpont}ig, mint a központi megfelelőjéig. Egy ilyen architektúra vázlatát mutatja be \aref{fig:overview_with_edge}.\ ábra. Az \gls{adatkozpont} "közelebb" helyezése a végeszközökhöz számos előnnyel jár. 
 
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=0.7\textwidth]{figures/overview_with_edge.pdf}
-	\caption{A peremhálózati adatközpontok alkalmazásával egy kisebb skálájú, de teljes funkcionalitású \gls{adatkozpont}ot ékelődik a végfelhasználók és a központi felhő közé.}
+	\caption{A peremhálózati adatközpontok alkalmazásával egy kisebb skálájú, de teljes funkcionalitású \gls{adatkozpont}ot ékelődik a \gls{vegeszkoz} és a központi \gls{felho} közé.}
 	\label{fig:overview_with_edge}
 \end{figure}
 
+Az egyik ilyen jelentős előny a késeltetés javítása. A hálózati adattovábbításhoz szükséges időt jelentősen befolyásolja mind az, hogy fizikailag milyen távolságba kell eljuttatni az információt (a jelenlegi legerősebb limitáló faktor maga a fényebesség az optikai összeköttetések esetén) de sokkal inkább az, hogy hány csomóponton kell áthaladnia útközben a csomagnak\cite{server_location_matters}. Azzal, hogy a távolságot és a köztes csomópontok számát csökkentjük jelentős javulást tudunk elérni a késleltetésben.
 
-% ez jolesz ahol írom hogy mi az az edge es miert old meg gondokat
+Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetniük kell az egyes feleknek\cite{cloudflare_price_of_bandwidth}. Azzal, hogy az információnak kevesebb köztes csomóponton kell áthaladnia jelentős adatforgalmi költségeket lehet megtakarítani a köztes szolgáltatóknak. Különös tekintettel arra az esetre, ha az adatforgalom nem hagyja el a szolgáltatói hálózatot.
-\cite{7807196}
-
-% Le kell írni az elméleti példát, és hogy hoygan oldja meg a problémákat amit fenn felvetettem
-% Egy gyakorlati példát is szeretnék adni, ami a mobil hálózatokra igaz, hogy BS-en van a cucc meg az datacenter meg minden
-
-
-Végül fontos megjegyezni, hogy a peremhálózatok nem fogják és nem is tervezik kiváltani a tradicionális megközelítést, sokkal inkább azt kiegészítve szimbiózisban van értelme üzemeltetni.
-
-\section{Felhő és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók
-
-% alapvetően bármit ki lehet szervezni ebbe a rendszerbe, de nem mindennek van értelme
-% ahhoz, hogy megállapítsuk, minek van értelme, egyeztessük a szempontokaz az előnyökkel
-
-% Itt leírom, hogy aggregáció és késleltetés az két nagyon fontos szempont amin javítani tud a perem és felhő
-
-
-\subsection{Nagy mennyiségű adatok aggregálása}
-
-\subsection{Késleltetés érzékeny alkalmazások}
-
-\subsection{Egyéb szempontok}
-
-% Kevesebb áram? Nagyobb redundancia?
-% Valamelyik doksiban írtak egy csomó mindent
-
-\section{Keretrendszerek}
-
-% itt le lehet írni, hogy igazából mit is kell egy keretrendszernek tudnia
-% Keresni pár példát
-
-\subsection{Alkalmazás fejlesztési keretrendszerek}
-
-\subsection{Alkalmazás futtatási keretrendszerek}
-
-
-% El lehet mondani, hogy ezt a kubermeme tudja és az jó nekünk
-
-
-% Ez a másik chapterből lett iderakva:
-
-
-% Ez egy bevezetés lényegében
-
 
+% TODO: privacy
 
 % Villany használat
 % Privacy/Security
 
-\section{Megvalósított alkalmazások}
 
-% Itt leírom hogy a Birbnetes és az ursim miért jók és miért demózzák jól a két fenti megállapítást
+\section{\Gls{felho} és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók
-% A birbnetesnél a minta felismerés át fog mászni az edge-cloudba
 
-A választott alkalmazások megvalósítását \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
+Ugyan a peremhálózati adatközpontok alkalmazása önmagában sok előnnyel kecsegtet, fontos megjegyezni, hogy a peremhálózati rendszerek nem fogják és nem is tervezik kiváltani a tradicionális megközelítést. Sokkal inkább azt kiegészítve szimbiózisban tudnak igazán érvényesülni.
+
+% Itt le kell írni hogy van ez a két dolog
+Egy ilyen "szimbiózisban" a peremhálózati rendszerekre mint a felhős szolgáltatások kiterjesztéseként tekinthetünk\cite{7807196}. A peremhálózati rendszerek korábban említett két előnye, amelyek az alacsony késleltetés és csökkentett hálózati költségek kiegészítik a \gls{felho}s alkalmazásokat. A késleltetés érzékeny, vagy nagy adatot fogadó komponenseket kiszervezhetjük a peremre, ott akár még előfeldolgozást is végezhetünk az adatokon, így csökkentett mennyiségű és kevésbé késleltetés érzékeny adatokat kell csak eljuttatnunk a felhőbe, ezzel akár még a felhasználói élményt is javítva.
+
+A gyakorlatban a technológia adott arra, hogy szinte bármit a kiszervezzünk a központi \gls{felho}ből a peremhálózati rendszerekre. Viszont a fent említett előnyök általában véve csak az alkalmazás valamely részegységében ad értelmezhető hasznot. Fontos ezért a megfelelő architekturális tervezése az alkalmazásnak, illetve az alapos felmérése az igényeknek és a hasznoknak.
+
+
+\section{Gyakorlati alkalmazás}
+Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek alkalmazásával jelentős javítást lehet elérni a fenti szempontokban. 
+
+Jelenleg is már több alkalmazásnál is használják, vagy tervezik használni. Ilyenek például az önvezető járművek\cite{liu2019edge}, ipari rendszerek távfelügyelete\cite{hao2020cloud}, betegfelügyelet\cite{wang2020secure}, felhő alapú játék szolgáltatások\cite{edge_gaming}, okos otthonok és városok\cite{shi2016edge} és még sok minden más területen\cite{edge_companies}.
+
+A dolgozatom részeként a \gls{felho} és a peremhálózati rendszerek előnyeinek bemutatására két konkrét alkalmazást készítettem, amelyen jól demózhatóak az előnyök. Ezeknek a megvalósítását a  \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
+
+\section{Alkalmazás futtatási és fejlesztési keretrendszerek}
+
+% itt le lehet írni, hogy igazából mit is kell egy keretrendszernek tudnia
+
+A feladatom megvalósításához több keretrendszert is megvizsgáltam, ezeket az alábbiakban részletezem
+
+\subsection{EdgeX Foundry}
+
+Az \textit{EdgeX Foundry} egy mikroszolgáltatásokból felépülő környezet, amelynek a célja az, hogy a perem alkalmazások fejlesztésénél gyakran felmerülő feladatokat ellátó komponensek egységesek legyenek\cite{edgexfoundry_docs}.
+
+
+
+
+\subsection{Project EVE}
+
+\subsection{Akarino Edge Stack}
+
+\subsection{StarlingX}
+
+\subsection{KubeEdge}
+
+A \textit{KubeEdge} egy \textit{Kubernetes}re épülő rendszer, amely kiterjeszti annak képességeit, hogy konténerizált alkalmazásokat peremhálózati rendszerek kezelésével\cite{kubeedge_docs}.
+
+
+
+A \textit{KubeEdge} lehetővé teszi, hogy a hagyományos formában felépített mikroszolgáltatás alapú alkalmazások komponenseit kiszervezze a peremhálózatra. Viszont bizonyos helyzetekben az alkalmazásnak a felelőssége megoldani, hogy áthidalja az olyan helyzeteket, amikor nem áll rendelkezésre kapcsolat a központi felhővel.
+
+
+\subsection{AWS IoT Greengrass}
+
+\subsection{Azure IoT Edge}

src/content/ursim_impl.tex

@@ -11,13 +11,25 @@
 % Mivel ezt a dipterv alatt csináltam, ezért részletesebben fogok írni róla
 
 
-\section{... ismertetése} % Általánosan a robotkar cumók ismertetése
+\section{Környezet ismertetése} % Általánosan a robotkar cumók ismertetése
 
-\subsection{TODO} % Általános leírás a robotkarokról
+\subsection{Universal Robots}
+% Általános leírás a robotkarokról
 
-\subsection{RTDE interfész}
 
-\subsection{TODO} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost
+\subsubsection{Fizikai jellemzők}
+% Ide majd keresek valamit, lehet átnevezem valami okosra a címét
+
+\subsubsection{Kommunikációs interfész}
+% URTD Interface
+
+\subsubsection{Szimulátor}
+% Dockursim
+
+\subsection{Demo vezérlés}
+
+
+\section{Tervezés} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost
 
 % tervezés és a nehézségek nem tételesen de hasonlóan struktúrálva
 % Illetve a komoly megoldásaim

src/include/packages.tex

@@ -69,4 +69,5 @@
 \usepackage{soul}
 \usepackage{tabularx}
 \usepackage{rotating}
-\usepackage{mdframed}
+\usepackage{mdframed}
+\usepackage[autostyle]{csquotes}