X-Git-Url: http://git.rohieb.name/skm-ma-ws1314.git/blobdiff_plain/a1c81dce7c7d4e3a0e6e1f446eaeb893845fd680..28a82327c7952cf1bad8680ae7b408e57ef70615:/sec-chatty-things.tex diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex index 5be64d4..01f0bb2 100644 --- a/sec-chatty-things.tex +++ b/sec-chatty-things.tex @@ -1,7 +1,127 @@ \section{System Architecture of ``Chatty Things''} + +After the underlying techniques have been explained, we can have a look at the +system architecture which Klauck and +Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things. + + \todo \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 +certain technical requirements. + +First, memory, computing resources and bandwith 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 +functions of XMPP (presence and message exchange, multi-user chats) to achieve +basic communication, grouping of devices, and information filtering to prevent +information overflow. + +Their solution builds on the \term{Contiki} operating system on an MSP430 board, +and uses the \term{uXMPP} project, which already implements core XMPP features +and serves as a starting point for implementing further XEPs. However, as the +uXMPP project was still in early development, they first needed to enhance its +functionality to comply with the limited resources. In particular, they +optimized the message flow and enabled uXMPP to fully use the available payload +instead of sending one TCP packet per message and reduced the code footprint +through compiler flags and refactoring. + +Furthermore, Klauck and Kirsche implemented new features for uXMPP, which were +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 item] +\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 a new publish-subscribe mechanism called Temporary Subscription for + Presence (see \ref{sec:tsp}) + \item XMPP Serverless Messaging (XEP-0174), using \term{uBonjour} as + underlying mDNS/DNS-SD implementation for Contiki. +\end{itemize} + +The resulting implementation (uXMPP and uBonjour) gets by with 12{.}2\ kBytes of +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. + +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. + +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. \todo[temporary subscription presence here?] +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 +entering a room) without need for any additional gateway on the application +level. + +%low bandwith in IEEE~802.15.4 (less than 250 kib/s at a maximum of 122 byte per +%packet\footnote{according to the maximum MAC payload size in the IEEE~802.15.4-2011 +%specification} + \subsection{Bootstrapping} -\subsection{Presence Subscription} +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 +Autoconfiguration. On the transport layer, all needed ports can be obtained over +DNS-Based Service Discovery. Finally, on the application layer, host names can +be resolved over Multicast DNS; and for the actual communication between devices +it is possible to use auto-generated JIDs with the ANONYMOUS login method on an +existing XMPP server, or if no server is found, use peer-to-peer communication +over XMPP Serverless Messaging. + +Bootstrapping a Chatty Thing therefore incorporates three steps: + +\begin{enumerate} + \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}. +\end{enumerate} + +During runtime, a device can then react to changes in network infrastructure: + +\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 + 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 + +% vim: set ft=tex et ts=2 sw=2 :