-\section{System Architecture of ``Chatty Things''}
+\section{System Architecture of ``Chatty Things''}\label{sec:arch}
-After the underlying techniques have been explained, we can have a look at the
-system architecture which Klauck and
+After the underlying techniques have been explained, we can now have a look at
+the system architecture which Klauck and
Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
\pages{3}
realized as separate modules to allow enabling and disabling them at runtime,
thus further reducing the memory footprint of a running system:
-\todo[minimize space between list items]
+\todo{minimize space between list items}
\begin{itemize}
\item support for IPv6
\item support for Multi-User Chats (XEP-0045), which are used for information
filtering
- \item support for SASL ANONYMOUS login for XMPP servers \ref{xep-0175}
+ \item support for SASL ANONYMOUS login for XMPP servers \cite{xep0175}
\item a new publish-subscribe mechanism called Temporary Subscription for
Presence (see \ref{sec:tsp})
\item XMPP Serverless Messaging (XEP-0174), using \term{uBonjour} as
ROM and 0{.}63\ kBytes of RAM, which was about the size of the original,
unoptimized uXMPP implementation while also implementing new features.
-\todo[figure of example network structure with and without central server]
+\todo{figure of example network structure with and without central server}
In order to react to different network infrastructures, their implementation
allows both communication with a central XMPP server as well as peer-to-peer
communication over XMPP Serverless Messaging. When a central XMPP server is
-detected over uBonjour, it is used instead with the ANONYMOUS login method, and the
-XEP-0174 module is disabled. The ANONYMOUS login method is chosen since TLS
-encryption is not yet implemented, and it assigns random JID to the client,
-which do not need to exist on the server. However, a server must exist and must
-be configured in order to use this method.
+detected over uBonjour, it is used instead with the ANONYMOUS login method, and
+the XEP-0174 module is disabled. The ANONYMOUS login method is chosen since TLS
+encryption is not yet implemented, and with this method, the server assigns a
+random JID to the client, which does not need to exist on the server. However, a
+server must exist and must be configured to use this login method in order to
+use this method.
With a server, information filtering is achieved by creating topic-based
Multi-User Chats where multiple devices can be grouped. A user can then simply
\subsection{Bootstrapping}
-In a distributed context like the Internet of Things, devices need to be ready
-to use out of the box. Users often do not want to set up configurations for each
-device they use, and when using several of those devices, it is often not
-reasonable having to configure every single one.
-
With the given approach, bootstrapping new Chatty Things is easy and no
configuration is neccessary: on the network layer, IP addresses can simply be
obtained using IPv4 Link-Local Addressing or IPv6 Stateless Address
Messaging and uBonjour and join topic-based Multi-User Chats.
\end{itemize}
-\todo[short conclusion?]
+\todo{short conclusion?}
\subsection{Temporary Subscription for Presence}\label{sec:tsp}
-To further reduce the message overhead and allow more fine-grained controls over
+To further reduce the message overhead and allow more fine-grained control over
information filtering, \term{Temporary Subscription for Presence} is introduced.
-This technique builds on top of presence stanzas as defined in core XMPP. These
-presence stanzas are sent without a \code{to} or \code{from} attribute, and
-therefore fit into a single TCP/IP packet over IEEE~802.15.4. However, to be
-able to receive these stanzas, a client must manually subscribe to those
-information in their roster, which requires further communication between nodes. As the network
-can change rapidly, subscriptions would be often outdated, and there would be
-much overhead of subscriptions and unsubscription packets, which would inhibit
-the flow of the actual information.
+This technique builds on top of presence stanzas as defined in core XMPP, which
+are sent by default without a \code{to} or \code{from} attribute, and therefore
+fit into a single TCP/IP packet over IEEE~802.15.4. However, a drawback of the
+presence mechanism defined by core XMPP is the fact that a client must manually
+subscribe to presence information of another client in order to receive it,
+which requires further communication between the clients. Since the network can
+change rapidly, and clients can frequently join and leave the network,
+subscriptions would often be outdated and must be renewed, leading to overhead
+of subscriptions and unsubscription packets, which would inhibit the flow of the
+actual information.
To solve this problem, a dynamic, topic-based roster is implemented on top of
Multi-User Chats (XEP-0045). Every topic corresponds with a chat room, and nodes
projects / skm-ma-ws1314.git / blobdiff