X-Git-Url: https://git.rohieb.name/skm-ma-ws1314.git/blobdiff_plain/cd6ed40d1dc83be550dc941d629663419f7c53e7..5d1cfb85e07daea1874f3753ab6ca31437efe869:/sec-chatty-things.tex diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex index 01f0ed0..6acde0c 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 +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 @@ -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 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} @@ -48,28 +46,27 @@ 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 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. @@ -79,13 +76,8 @@ 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 @@ -97,38 +89,40 @@ 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 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