feat(tervezés): mqtt ismertető init

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}
 

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},
+}