X-Git-Url: http://git.rohieb.name/skm-ma-ws1314.git/blobdiff_plain/ce4c9f88cbf50fc383af61d1131f706b0f1e5446..f0fb3f3f678d8fe10cad4ff3920a60248a93a077:/sec-chatty-things.tex diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex index d748494..25b1426 100644 --- a/sec-chatty-things.tex +++ b/sec-chatty-things.tex @@ -1,10 +1,9 @@ \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 +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. -\todo \pages{3} \subsection{Service Provisioning Sublayer} @@ -33,12 +32,12 @@ 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] +\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 @@ -49,16 +48,17 @@ 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] +\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 @@ -68,8 +68,7 @@ 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, +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 entering a room) without need for any additional gateway on the application @@ -81,11 +80,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 @@ -117,20 +111,22 @@ 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?] +\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