X-Git-Url: http://git.rohieb.name/skm-ma-ws1314.git/blobdiff_plain/bbf634a989779b4193d927a3f0046ba61e19f1c7..94cb4638c0b154bba68386a18eb63dfa12460a25:/sec-chatty-things.tex diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex index fe69f94..9ac3428 100644 --- a/sec-chatty-things.tex +++ b/sec-chatty-things.tex @@ -1,17 +1,16 @@ -\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 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 @@ -32,14 +31,13 @@ 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 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} @@ -48,21 +46,20 @@ 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. +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 @@ -79,11 +76,6 @@ 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 obtained using IPv4 Link-Local Addressing or IPv6 Stateless Address @@ -97,14 +89,16 @@ 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 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 @@ -115,20 +109,20 @@ During runtime, a device can then react to changes in network infrastructure: 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