*.fdb*
*.log
*.pdf
+*.out
@misc{xep-0174,
abstract = "This specification defines how to communicate over local or wide-area networks using the principles of zero-configuration networking for endpoint discovery and the syntax of XML streams and XMPP messaging for real-time communication. This method uses DNS-based Service Discovery and Multicast DNS to discover entities that support the protocol, including their IP addresses and preferred ports. Any two entities can then negotiate a serverless connection using XML streams in order to exchange XMPP message and IQ stanzas.",
author = "Saint-Andre, Peter",
- howpublished = "http://xmpp.org/extensions/xep-0174.html",
+ howpublished = "\url{http://xmpp.org/extensions/xep-0174.html}",
month = nov,
organization = "{XMPP Standards Foundation}",
series = "{XMPP Extension Protocols}",
author = "Gulbrandsen, A. and Vixie, P. and Esibov, L.",
howpublished = "RFC 2782 (Proposed Standard)",
month = feb,
- note = "Updated by RFC 6335",
number = "2782",
organization = "Internet Engineering Task Force",
publisher = "IETF",
@misc{draft-ietf-core-coap-18,
author = "Shelby, Z. and Hartke, K. and Bormann, C.",
edition = "18",
- howpublished = "https://tools.ietf.org/html/draft-ietf-core-coap-18",
+ howpublished = "\url{https://tools.ietf.org/html/draft-ietf-core-coap-18}",
month = jun,
organization = "Internet Engineering Task Force",
publisher = "IETF",
@misc{mqtt,
author = "{IBM}",
edition = "{v3.1 Specification}",
- howpublished = "http://www.ibm.com/developerworks/webservices/library/ws-mqtt/",
+ howpublished = "\url{http://www.ibm.com/developerworks/webservices/library/ws-mqtt/}",
organization = "{IBM}",
title = "{MQ Telemetry Transport}"
}
@misc{xep-0060,
abstract = "This specification defines an XMPP protocol extension for generic publish-subscribe functionality. The protocol enables XMPP entities to create nodes (topics) at a pubsub service and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node. Pubsub therefore adheres to the classic Observer design pattern and can serve as the foundation for a wide variety of applications, including news feeds, content syndication, rich presence, geolocation, workflow systems, network management systems, and any other application that requires event notifications.",
author = "Millard, Peter and Saint-Andre, Peter and Meijer, Ralph",
- howpublished = "http://xmpp.org/extensions/xep-0060.html",
+ howpublished = "\url{http://xmpp.org/extensions/xep-0060.html}",
month = jul,
organization = "{XMPP Standards Foundation}",
series = "{XMPP Extension Protocols}",
@misc{xep-0045,
abstract = "This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc.",
author = "Saint-Andre, Peter",
- howpublished = "http://xmpp.org/extensions/xep-0045.html",
+ howpublished = "\url{http://xmpp.org/extensions/xep-0045.html}",
month = feb,
organization = "{XMPP Standards Foundation}",
series = "{XMPP Extension Protocols}",
\subsection{Extensions to the DNS protocol}
\subsubsection{Multicast DNS}
-\term{Multicast DNS}~\cite{rfc6762} (mDNS) describes an extension of the Domain Name
-System that allows DNS resource records to be distributed on multiple hosts in a
-network, therefore avoiding the need of a central server.
+
+\term{Multicast DNS}~\cite{rfc6762} (mDNS) describes an extension of the Domain
+Name System that allows DNS resource records to be distributed on multiple hosts
+in a network, therefore avoiding the need of a central server.
Software that supports resolution of mDNS records listens on the reserved
link-local multicast address \code{224.0.0.251} (for IPv4 queries) or
not generate a response.
Finally, hosts may also send unsolicited responses. This can be used to notify
-the network of new services available on the host.
+the network of new services available on a host.
\pages{1}
-\subsubsection{DNS-Based Service Discovery}
-\todo
-\term{DNS-based Service Discovery} \cite{rfc6763}
-\begin{itemize}
- \item allows flexible mapping of available services to ports
- \item utilization of SRV \cite{rfc2782}, TXT and PTR records
- \item case study for IoT in \cite{Klauck:2012:BCC:2352852.2352881}
-\end{itemize}
+\subsubsection{DNS-Based Service Discovery}\label{sec:dnssd}
+
+As a recent extension for the Domain Name System, \term{DNS-Based Service
+Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of type
+\code{SRV}~\cite{rfc2782} and \code{PTR} in a way that allows hosts to browse
+for services in a domain. As an example, Figure~\ref{fig:dnssd} shows the
+process of browsing for all XMPP clients in the domain \code{example.org}.
+This is a two-step process, consisting of \term{Service Instance Enumeration}
+and \term{Service Instance Resolution}.
+
+\begin{figure}[htop]
+ \centering
+ \includegraphics[width=0.9\textwidth]{dnssd-mock.jpg}
+ \caption{DNS-SD: Service Instance Enumeration and Resolution}
+ \label{fig:dnssd}
+\end{figure}
+
+\paragraph{Service Instance Enumeration} At first, to enumerate the available
+services in a domain for a given protocol, a DNS-SD-enabled client queries
+resources of type \code{PTR} of the form \code{\_service.\_proto.domain}. The
+result of this query is then a list of \term{instance names} of the form
+\code{name.\_service.\_proto.domain} which provide the specified service. For
+example, in Figure~\ref{fig:dnssd}, all XMPP clients in the domain
+\code{example.org} are enumerated, and as a result, the instance names of three
+hosts are returned.
+
+\paragraph{Service Instance Resolution} As a second step, the returned instance
+names are resolved as \code{SRV} records to retrieve the actual host names and
+port numbers of a service. In the example, resolution of one instance name shows
+that an XMPP client is running at host \code{juliet.example.org} on port 5222.
+
+Through the usage of \code{SRV} records, it is easily possible for a service to
+inform clients about non-standard port numbers, and especially in connection
+with Multicast DNS makes it easy to deploy decentralized systems for the
+Internet of Things~\cite{Klauck:2012:BCC:2352852.2352881}.
\pages{1}
% vim: set ft=tex et ts=2 sw=2 :
\usepackage{color}
\usepackage{graphicx}
\usepackage{wrapfig}
+\usepackage{hyperref}
\newcommand{\pages}[1]{\marginpar{#1 pages}}
\newcommand{\todo}{\textcolor{red}{TODO} \\}
short overview, not too long: what do we want, what are we
going to do
+basically: how do we talk to our smart home?
%% Prerequisites
\section{Prerequisites}
\todo
overview to the techniques used in the paper by Klauk and Kirsche
-basically: how do we talk to our smart home?
\cite{klauck-kirsche-chattythings}
\input{address-allocation.tex}
Middleware, Application protocol gateways:
\begin{itemize}
\item Constrained Application Protocol \cite{draft-ietf-core-coap-18}
+ \begin{itemize}
+ \item machine-to-machine
+ \item everything-built-in
+ \item discovery over multicast, service discovery over /.well-known
+ entry-point
+ \item maps to HTTP => stateless
+ \item low protocol overhead and parsing complexity (binary messages)
+ \item only draft status
+ \item UDP with Ack and IDs instead of TCP... (limited state machine)
+ \item proxies
+ \item asynchronous messages
+ \end{itemize}
\item MQ Telemetry Transport \cite{mqtt}
+ \begin{itemize}
+ \item TCP/IP
+ \item small overhead: 2 byte header + variable header length
+ \item publish-subscribe with topic names
+ \item binary protocol
+ \item discovery?
+ \end{itemize}
\item Devices Profile for Web Services \cite{zeeb-moritz-ws4d}
+ \begin{itemize}
+ \item TCP/IP -> HTTP -> SOAP -> Web Services. Overhead!
+ \item but very extendable and composable
+ \item discovery as a service
+ \item focused on multiple platforms, deeply embedded and servers
+ \item IPv6 partly experimental
+ \item ROM usage of uDPWS: 45 kByte
+ \end{itemize}
+
\end{itemize}
\section{Discussion}
\subsubsection{Architecture}
\begin{wrapfigure}{r}{0.4\textwidth}
%\begin{figure}[htop]
+ \label{fig:xmpparch}
\centering
\includegraphics[width=0.4\textwidth]{xmpp-architecture-mock.jpg}
\caption{XMPP architecture}
\end{wrapfigure}
The original architecture underlying XMPP strongly leans on the established
-design of Internet Mail. The distributed network is formed by \term{XMPP
-servers} on one hand, which make up the always available backbone of the network
-and manage user accounts and statuses, and \term{XMPP clients} on the other
-hand, which represent a single logged-in user and make up the interface for
-communication with other users.
+design of Internet Mail, and an example is depicted in Fig.~\ref{fig:xmpparch}.
+The distributed network is formed by \term{XMPP servers} on one hand, which make
+up the always-on backbone of the network used for routing message, and manage
+user accounts and statuses. On the other hand, \term{XMPP clients} represent a
+single logged-in user and are the interface for communication with other users.
Every client communicates only with the server that manages the respective user
account which is configured in the client, as given in the user's JID. The
is not logged in at the time the message is sent, the server can store it for
the user and deliver it on the next login.
-\todo{use of DNS-SD?}
+XMPP strongly relies on DNS Service Discovery (see Section~\ref{sec:dnssd}) to
+determine the server being in charge of a domain. For example, the server who
+manages the users for the domain \code{example.org} is given by the SRV record
+\code{\_xmpp-server.\_tcp.example.org}.
\subsubsection{Communication primitives}
+All communication over XMPP is based on XML. To minimize communication overhead,
+only fragments of XML, called \term{stanzas}, are sent between hosts. A stanza
+is always well-formed as a whole; it consist of a root element, which also
+includes routing attributes (\code{to} and \code{from}), and its optional child
+elements.
+
+On top of that, living connections between hosts are represented by \term{XML
+streams}. The client initiates a connection by sending an XML declaration
+followed by an opening \code{<stream>} tag. The server then responds also with
+an opening \code{<stream>} tag. The client then performs SASL authentication and
+binds its stream to a resource for proper addressing. If this process succeeded,
+both client and server can send an unlimited number of stanzas, until the
+connection is closed by one side by sending an closing \code{</stream>} tag. The
+other side then has the chance to send all outstanding stanzas and likewise
+closes its stream. If both streams are closed, the underlying TCP connection is
+terminated.
+
+\todo{Example stream}
+
\subsubsection{Multi-User Chats}
\cite{xep-0045}
\subsubsection{Publish/Subscribe and the Roster}
-is this really needed?
-
\cite{xep-0060}
\subsubsection{Presence}
\cite{rfc6120}
-\begin{itemize}
- \item architecture: client-server, use of DNS-SD
- \item addressing: JIDs, resources
- \item XML-based communication primitives, stanzas and streams
- \item presence
- \item publish/subscribe \cite{xep-0060}, roster
- \item multi-user chats \cite{xep-0045}
-\end{itemize}
-
-
\subsubsection{XMPP Serverless Messaging}
\todo
projects / skm-ma-ws1314.git / commitdiff
