diff --git a/src/contents/6-tervezes.tex b/src/contents/6-tervezes.tex
index 37b2c6b565ed5e716b521221c21b5db3213de73f..6d899c9a44142feb6c30fa0a615ba8d4a02c6267 100644
--- a/src/contents/6-tervezes.tex
+++ b/src/contents/6-tervezes.tex
@@ -88,11 +88,11 @@ széleskörű támogatást élvez, sőt egy hivatalos kiegészítőként is műk
nem vonatkozik esetünkre az állítás. A telepítés lépései könnyűek és rövidek.
\cite{hass-mqtt-broker} Miután elindul a broker, és a rendszer csatlakozik
rá, azonnal láthatóvá fog válni a Home Assistantban. Ez \aref{kereskedelmi}.
-fejezetben látottakban kimagasló előnyt jelent a DIY rendszerekhez képest,
-mert az onboarding élmény elméletben megbízható lesz a vezetékes kommunikáció
-miatt, és a kifejlett protokoll és integráció miatt. A hibafaktor az a saját
-implementáláson fog leginkább múlni, melyet a gyakorlatban fogunk tudni
-felmérni.
+fejezetben látottakban kimagasló előnyt jelent a DIY rendszerekhez képest, mert
+az onboarding élmény elméletben megbízható lesz a vezetékes kommunikáció miatt,
+és a kifejlett protokoll és integráció miatt. A hibafaktor és a használhatóság
+az a saját implementáláson fog leginkább múlni, melyet a gyakorlatban fogunk
+tudni felmérni.
Végezetül, a megtervezett rendszert és a megválasztott komponenseket
\aref{diag:rendszer}. ábrán illusztráltam. A megválasztás során felületesen
@@ -108,6 +108,7 @@ részletesen adok ismertetést azokról.
\section{Választott megoldások ismertetése}
\subsection{ESP32 platform}
+\label{esp}
\paragraph{} Az Espressif más megközelítéssel tervezi a hardvereit, mint hasonló
platfomok. Egy alacsony fogyasztású beépített rendszer általában minimális számú
@@ -269,7 +270,57 @@ csökketve az emberi hibából fakadó helytelenségeket.
\subsection{MQTT protokoll}
-% A riasztórendszer és az okosotthon közötti protokoll. Ismertető, mire jó és mire nem + ide miért jó.
+\paragraph{} Az MQTT protokoll az OSI réteg tetején ül, az Application Layer-en,
+TCP/IP hálózatok felett. \textsl{``Az MQTT célja, hogy egyszerű, nyílt,
+ könnyű és nagy sávszélesség-hatékonyságú legyen, így jó választás a gépek
+ kommunikációjára korlátozott környezetben.''} \cite{mqtt-vs-coap} Az MQTT egy
+publish/subscribe modellre építő üzenetküldő protokoll, ami az IoT világában
+jól alkalmazható. Egyetlen nagy előnye a megbízhatósága, mivel TCP felett
+van implementálva. Emiatt minden átvitt adat rendezett és veszteségmentes.
+\cite{mqtt-vs-coap}
+
+A publish/subscribe vagy röviden pub/sub modell egy hierarchikus rendszer.
+Minden üzenet egy adott kategóriába (``topic'') van sorolva. Ha egy üzenetet
+küldünk (publish) egy adott topic-on belül, akkor az arrra feliratkozott
+(subscribe) kliensek mind megkapják az üzenetet. Egy kliens akárhány topic-ra
+iratkozhat fel, illetve küldhet üzenetet. A protokoll megköveteli azt az
+architektúrai elemet, hogy a kliensek között legyen egyetlen szerver, elnevezés
+szerint a ``broker''. A broker fogadja a kliensek csatlakozási, feliratkozási,
+üzenetküldési, leválasztási és egyéb kérelmeit. Nyilván tartja a klienseket,
+azok jogosultságait és a topic-ok továbbítását végzi. Számos implementációja van
+mind kliens oldali és broker oldali szerepeknek. \cite{mqtt-vs-coap}
+
+Az architektúra előnye, hogy a komplex feldolgozás feladata az a broker-re van
+hagyva és egy kliens működtetése minimális erőforrásokat igényel. További előnye
+más megoldásokkal szemben, hogy beépített Quality of Service (QoS) megoldást
+kínál az átvitt üzenetek fogadásának és célba érkezésének garanciájához. A TCP
+önmaga ilyen garanciát nem tud adni -- csak integritás és rendezettséget --
+illetve csomagok újraküldéssel tud próbálkozni de ez még nem garancia az adott
+üzenet célba érkezésére, hiszen alacsonyabb absztrakciós szinten tartózkodik.
+Ezért ez a feladat magasabb egy szintű protokollra marad. \cite{tcp} Az MQTT
+három szinten definiál QoS-t:
+
+\begin{itemize}
+ \item \textbf{QoS 0} (``At most once delivery''): Az üzenetek átviteléről kvázi
+ nincs garancia, tehát itt nincs semmilyen újraküldésre tett kísérlet.
+ \item \textbf{QoS 1} (``At least one delivery''): Az üzenetküldést jóvá kell hagyni,
+ ellenben az üzenet újra küldésre kerül. Ez a szint garantálja hogy
+ az üzenet célba fog érni, de lehetséges, hogy többször is.
+ \item \textbf{QoS 2} (``Exactly once delivery''): Az üzenetküldés maga egy
+ négy utas kézfogás (``four-way handshake'') első üzenete, ami
+ garantálja, hogy az üzenet pontosan egyszer fog célba érni.
+ \cite{mqtt-vs-coap}
+\end{itemize}
+
+\Aref{esp}. fejezetben megismert ESP-IDF környezet beépített implementációt
+kínál MQTT kliens szerepben, Rust nyelven is. Az integrációt ezzel tervezem
+megvalósítani. Minden QoS szintet támogat, illetve aszinkron (async, nem
+blokkoló) változatú implementáció is van hozzá. Darabolt adatfogadásra
+is van lehetőség, amivel nagyobb mennyiségű adatot is fel lehet dolgozni
+kevés memóriával is. \cite{esp-idf-svc} Ez jól fog jönni firmware frissítés
+implementálásakor, amivel potenciálisan azonnal a flash memóriába lehet majd
+írni az újabb binárist. Bár ez nem az alapfeladat része, de jó alapokat ad a
+framework; előre tervezés szempontjából hasznos tudásnak tartom.
\subsection{Home Assistant okosotthon}
diff --git a/src/hivatkozasok.bib b/src/hivatkozasok.bib
index eb51d18cfde4abc5cc04bddd7e36bc9f8480e4e0..0e95b28d0658c0c2b9e4c2e2787ca6d1af8aed72 100644
--- a/src/hivatkozasok.bib
+++ b/src/hivatkozasok.bib
@@ -545,3 +545,73 @@ urldate = {2025-04-22},
},
urldate = {2025-04-25},
}
+
+@article{mqtt-vs-coap,
+ title = {Performance evaluation of CoAP and MQTT with security support for
+ IoT environments},
+ journal = {Computer Networks},
+ volume = {197},
+ pages = {108--338},
+ year = {2021},
+ issn = {1389-1286},
+ doi = {https://doi.org/10.1016/j.comnet.2021.108338},
+ url = {https://www.sciencedirect.com/science/article/pii/S1389128621003364},
+ urldate = {2025-04-25},
+ author = {Victor Seoane and Carlos Garcia-Rubio and Florina Almenares and
+ Celeste Campo},
+ keywords = {Internet of Things, CoAP, MQTT, Security, Performance evaluation
+ },
+ abstract = {World is living an overwhelming explosion of smart devices:
+ electronic gadgets, appliances, meters, cars, sensors, camera and
+ even traffic lights, that are connected to the Internet to extend
+ their capabilities, constituting what is known as Internet of
+ Things (IoT). In these environments, the application layer is
+ decisive for the quality of the connection, which has
+ dependencies to the transport layer, mainly when secure
+ communications are used. This paper analyses the performance
+ offered by these two most popular protocols for the application
+ layer: Constrained Application Protocol (CoAP) and Message Queue
+ Telemetry Transport (MQTT). This analysis aims to examine the
+ features and capabilities of the two protocols and to determine
+ their feasibility to operate under constrained devices taking
+ into account security support and diverse network conditions,
+ unlike the previous works. Since IoT devices typically show
+ battery constraints, the analysis is focused on bandwidth and CPU
+ use, using realistic network scenarios, since this use translates
+ to power consumption.},
+}
+
+@misc{tcp,
+ series = {Request for Comments},
+ number = 9293,
+ howpublished = {RFC 9293},
+ publisher = {RFC Editor},
+ doi = {10.17487/RFC9293},
+ url = {https://www.rfc-editor.org/info/rfc9293},
+ author = {Wesley Eddy},
+ title = {{Transmission Control Protocol (TCP)}},
+ pagetotal = 98,
+ year = 2022,
+ month = aug,
+ abstract = {This document specifies the Transmission Control Protocol (TCP).
+ TCP is an important transport-layer protocol in the Internet
+ protocol stack, and it has continuously evolved over decades of
+ use and growth of the Internet. Over this time, a number of
+ changes have been made to TCP as it was specified in RFC 793,
+ though these have only been documented in a piecemeal fashion.
+ This document collects and brings those changes together with the
+ protocol specification from RFC 793. This document obsoletes RFC
+ 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that
+ updated parts of RFC 793. It updates RFCs 1011 and 1122, and it
+ should be considered as a replacement for the portions of those
+ documents dealing with TCP requirements. It also updates RFC 5961
+ by adding a small clarification in reset handling while in the
+ SYN-RECEIVED state. The TCP header control bits from RFC 793 have
+ also been updated based on RFC 3168.},
+}
+
+@online{esp-idf-svc,
+ title = {Crate esp\_idf\_svc - Rust},
+ url = {https://docs.esp-rs.org/esp-idf-svc/esp_idf_svc/index.html},
+ urldate = {2025-04-25},
+}