-\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}
\subsection{Service Provisioning Sublayer}
Considering the application in deeply embedded systems and the special needs of
-the Internet of Things on the one hand, the protocol stack needs to fulfil
+the Internet of Things on the one hand, the protocol stack needs to fulfill
certain technical requirements.
-First, memory, computing resources and bandwith on embedded systems are limited,
+First, memory, computing resources and bandwidth on embedded systems are limited,
which demands for a lightweight protocol stack without too much overhead and
predictable memory consumption, while also retaining enough flexibility for
future development. The authors therefore provide only the most essential
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}
\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 \cite{xep0175}
\item a new publish-subscribe mechanism called Temporary Subscription for
- Presence (see \ref{sec:tsp})
+ Presence (see Section~\ref{sec:tsp})
\item XMPP Serverless Messaging (XEP-0174), using \term{uBonjour} as
underlying mDNS/DNS-SD implementation for Contiki.
\end{itemize}
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}
-
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 supply this login method in order
+for this approach to work.
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
join the chat with a standard XMPP client on her machine and interact with all
-devices of a topic, or she can also interact with them directly.
+devices of a topic, or she can also interact with single devices directly.
In scenarios without an XMPP server, the XEP-0174 module is activated and
devices talk directly with the user or with other devices. This method has the
drawback that Multi-User Chats cannot be used for topic filtering, since no
method is specified to do XEP-0045 and XEP-0174 at the same time. In this case,
a user must have an XEP-0174-compliant chat client, but it also gives her the
-opportunity to interact with things spontaneously on an ad-hoc basis (e.~g. when
+opportunity to interact with things spontaneously on an ad hoc basis (e.~g. when
entering a room) without need for any additional gateway on the application
level.
\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
+configuration is necessary: on the network layer, IP addresses can simply be
obtained using IPv4 Link-Local Addressing or IPv6 Stateless Address
Autoconfiguration. On the transport layer, all needed ports can be obtained over
DNS-Based Service Discovery. Finally, on the application layer, host names can
Bootstrapping a Chatty Thing therefore incorporates three steps:
\begin{enumerate}
- \item Activate uBonjour and try to discover an XMPP server
+ \item Activate uBonjour and try to discover an XMPP server.
\item If a server is found, connect to it using ANONYMOUS login, join
topic-based Multi-User Chats, deactivate the uBonjour client
- \term(Infrastructure mode).
- \item If no server is found, activate the XEP-0174 client \term{Ad-hoc mode}.
+ \term{(Infrastructure mode).}
+ \item If no server is found, activate the XEP-0174 client \term{(Ad hoc
+ mode)}.
\end{enumerate}
-During runtime, a device can then react to changes in network infrastructure:
+During runtime, a device can then react to changes in network infrastructure by
+changing from one mode to the other:
\begin{itemize}
\item In Infrastructure mode: when connection to the server is lost, enable
the uBonjour client, try to find a server, and when none is found, enable
Serverless Messaging.
- \item In Ad-hoc mode: if uBonjour detects a new XMPP server joining the
+ \item In Ad hoc mode: if uBonjour detects a new XMPP server joining the
network, try to connect to it. If this succeeds, disable Serverless
Messaging and uBonjour and join topic-based Multi-User Chats.
\end{itemize}
-\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 messages, 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