todonotes are no longer needed

[skm-ma-ws1314.git] / sec-chatty-things.tex

diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex
index 01f0ed0..6acde0c 100644 (file)
--- 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.
 
 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
 \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.
 
 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
 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:
 
 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
 \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}
   \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.
 
 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
 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
 
 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
 
 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.
 
 entering a room) without need for any additional gateway on the application
 level.
 


@@ -79,13 +76,8 @@ level.
 
 \subsection{Bootstrapping}
 
 
 \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
 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
 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}
 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
   \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}
 
 \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.
 
 \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}
 
     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}
 
 \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.
 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
 
 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