+++ /dev/null
-\subsection{Address allocation}
-Considering the TCP/IP protocol suite, in order to be able to communicate on the
-IP layer, a device needs to configure one of its network interfaces with
-an IP address that can be reached from the network that the device wants to connect
-to. There are several ways of achieving this:
-
-\begin{itemize}
- \item The IP address is pre-selected by a human and stored in the device
- configuration. This process is cumbersome when more than one device needs to
- be configured, and humans have to remember which addresses are configured on
- which device, and which addresses are still free to use on additional
- devices.
-
- \item Deploying a central server that assigns network addresses
- to the devices in the network, which in order query the server (for example
- via broadcast or on a lower layer) for a unique address before they use the
- IP layer for the first time. This technique supersedes the dependency of
- human memory for mapping IP addresses to devices, and can easily be combined
- with additional central configuration management, like the automatic
- assignment of a static gateway, or a DNS resolver.\\
- The DHCP protocol is one example of central IP address management.
-
- \item A third alternative is the use of a distributed protocol which enables
- the devices on the network to choose addresses in accordance with other
- devices on the same network, so no IP address is used more than once. In
- respect to the Internet of Things, this approach has the advantage that
- those devices can easily be used in different scenarios without needing
- central deployment at all, and also allowing them to change their addresses
- dynamically, therefore easily reacting to changes in the network. \\
- There are two major protocols which are used for dynamic configuration of IP
- addresses. In the IPv4 world, Link-Local Addressing~\cite{rfc3927} is often
- used, and in IPv6 networks, Stateless Address
- Autoconfiguration~\cite{rfc4862} is a fundamental feature built into every
- device.
-
-\end{itemize}
-
-\paragraph{IPv4 Link-Local Addressing}
-
-\term{Link-Local Addressing}, also known as \term{Automatic Private IP
-Addressing (APIPA)} or \term{Zeroconf}, uses the IPv4 subnet
-\code{169.254.0.0/16} for addressing. Every device first chooses a random
-address from that address space. Then it checks if the chosen address is used
-by any other device on the network by probing the chosen address, which is
-usually done using the ARP protocol. If the probing process results that the
-address is not used on the network (e.~g. no device returned an ARP response
-during a random time interval), the device claims its chosen address and uses it
-for communication on the IPv4 layer. If the chosen address is already used, the
- device continues the process, subsequently choosing a new random address and
- trying to claim it, until a free address has been found.
-
-\paragraph{IPv6 Stateless Address Autoconfiguration}
-
-Similar to IPv4 Link-Local Addressing, devices configured with \term{IPv6
-Stateless Addressing Autoconfiguration} use an IPv6 address from the subnet
-\code{fe80::/64}. First, an \term{interface identifier} is generated using the
-interface's MAC address. Since MAC addresses must be unique in the network, a
-unique IPv6 address is obtained by combining the subnet prefix and the interface
-identifier. To ensure that no other device exists with this generated IPv6
-address, the device performs \term{Duplicate Address Detection} on the network
-through \term{Neighbor Advertisement} messages and listening for \term{Neighbor
-Solicitation} messages. If such messages are received from other hosts, the
-configured address cannot be used by the device and must be discarded.
-Therefore, in order to use IPv6 effectively, it must be guarranteed that MAC
-addresses are unique on the network.
-
-In contrast to IPv4 Link-Local Addressing, IPv6 Stateless Address
-Autoconfiguration can also be used with a central server. In this case, a
-central server broadcasts \term{Router Solicitation} messages on the network
-which contain a global network prefix. The hosts on the network can then use
-that prefix instead to configure a global IPv6 address.
-
-% vim: set ft=tex et ts=2 sw=2 :
+++ /dev/null
-\subsection{Extensions to the Domain Name System}\label{sec:dns}
-
-In a distributed context, it is often not feasible to rely on a central,
-authoritative DNS server, and there is usually no easy way to discover services.
-The first problem is addressed with \term{Multicast DNS}, and since DNS is
-basically a key-value store, it can also be used for service discovery, which is
-achieved using \term{DNS-Based Service Discovery}. Both techniques were first
-developed by Apple as part of the \term{Bonjour} project, and are now maintained
-by the IETF Zeroconf working group.
-
-\subsubsection{Multicast DNS}
-
-\term{Multicast DNS}~\cite{rfc6762} (mDNS) describes an extension to the Domain
-Name System that allows DNS resource records to be distributed on multiple hosts
-in a network, therefore avoiding central authorities and enabling every host to
-publish its own entries. For that purpose, a special domain, usually
-named \code{.local}, is used.
-
-Software that supports mDNS listens on the reserved
-link-local multicast address \code{224.0.0.251} (for IPv4 queries) or
-\code{FF02::FB} (for IPv6 queries) on UDP port 5353 for incoming queries.
-Queries sent to those multicast address and port are standard DNS queries.
-If a host receives a query and knows about the queried resource, it responds to the
-querying host with a standard DNS response. The querying host can then simply
-finish and use the result, or wait until other hosts respond to its query. The
-latter is typically the case when a record can have multiple values, as it is
-the case with \code{SRV} and \code{PTR} records.
-
-Another feature of Multicast DNS is the reduction of traffic through
-\term{Known-Answer Suppression}. It allows a querying host to specify already
-known resources in its query when querying resources that could exist on more
-than one host (e.~g., SRV records). The hosts matching those resources then do
-not generate a response.
-
-Finally, hosts may also send unsolicited responses. This can be used to notify
-the network of new services available on a host.
-
-\pages{1}
-
-\subsubsection{DNS-Based Service Discovery}\label{sec:dnssd}
-
-As another recent extension for the Domain Name System, \term{DNS-Based Service
-Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of types
-\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}[top]
- \centering
- \includegraphics[width=0.9\textwidth]{dnssd-mock.jpg}
- \caption{DNS-SD: Service Instance Enumeration and Resolution
- \todo[XMPP is a bad example here, use IPP]}
- \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}, by querying for
-\code{\_ipp.\_tcp.\_example.org}, all printers supporting the IPP protocol 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 IPP server is running at host \code{gutenberg.example.org} on port 5222.
-Additionally, an optional \code{TXT} record with the same instance name can
-contain further information about the service (e.~g., information about the
-supported paper sizes).
-
-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 :
\cite{klauck-kirsche-chattythings}
-\input{address-allocation.tex}
-\input{dns-extensions.tex}
-\input{xmpp.tex}
+\input{sec-address-allocation.tex}
+\input{sec-dns-extensions.tex}
+\input{sec-xmpp.tex}
\input{sec-chatty-things.tex}
\section{Related Approaches}
--- /dev/null
+\subsection{Address allocation}
+Considering the TCP/IP protocol suite, in order to be able to communicate on the
+IP layer, a device needs to configure one of its network interfaces with
+an IP address that can be reached from the network that the device wants to connect
+to. There are several ways of achieving this:
+
+\begin{itemize}
+ \item The IP address is pre-selected by a human and stored in the device
+ configuration. This process is cumbersome when more than one device needs to
+ be configured, and humans have to remember which addresses are configured on
+ which device, and which addresses are still free to use on additional
+ devices.
+
+ \item Deploying a central server that assigns network addresses
+ to the devices in the network, which in order query the server (for example
+ via broadcast or on a lower layer) for a unique address before they use the
+ IP layer for the first time. This technique supersedes the dependency of
+ human memory for mapping IP addresses to devices, and can easily be combined
+ with additional central configuration management, like the automatic
+ assignment of a static gateway, or a DNS resolver.\\
+ The DHCP protocol is one example of central IP address management.
+
+ \item A third alternative is the use of a distributed protocol which enables
+ the devices on the network to choose addresses in accordance with other
+ devices on the same network, so no IP address is used more than once. In
+ respect to the Internet of Things, this approach has the advantage that
+ those devices can easily be used in different scenarios without needing
+ central deployment at all, and also allowing them to change their addresses
+ dynamically, therefore easily reacting to changes in the network. \\
+ There are two major protocols which are used for dynamic configuration of IP
+ addresses. In the IPv4 world, Link-Local Addressing~\cite{rfc3927} is often
+ used, and in IPv6 networks, Stateless Address
+ Autoconfiguration~\cite{rfc4862} is a fundamental feature built into every
+ device.
+
+\end{itemize}
+
+\paragraph{IPv4 Link-Local Addressing}
+
+\term{Link-Local Addressing}, also known as \term{Automatic Private IP
+Addressing (APIPA)} or \term{Zeroconf}, uses the IPv4 subnet
+\code{169.254.0.0/16} for addressing. Every device first chooses a random
+address from that address space. Then it checks if the chosen address is used
+by any other device on the network by probing the chosen address, which is
+usually done using the ARP protocol. If the probing process results that the
+address is not used on the network (e.~g. no device returned an ARP response
+during a random time interval), the device claims its chosen address and uses it
+for communication on the IPv4 layer. If the chosen address is already used, the
+ device continues the process, subsequently choosing a new random address and
+ trying to claim it, until a free address has been found.
+
+\paragraph{IPv6 Stateless Address Autoconfiguration}
+
+Similar to IPv4 Link-Local Addressing, devices configured with \term{IPv6
+Stateless Addressing Autoconfiguration} use an IPv6 address from the subnet
+\code{fe80::/64}. First, an \term{interface identifier} is generated using the
+interface's MAC address. Since MAC addresses must be unique in the network, a
+unique IPv6 address is obtained by combining the subnet prefix and the interface
+identifier. To ensure that no other device exists with this generated IPv6
+address, the device performs \term{Duplicate Address Detection} on the network
+through \term{Neighbor Advertisement} messages and listening for \term{Neighbor
+Solicitation} messages. If such messages are received from other hosts, the
+configured address cannot be used by the device and must be discarded.
+Therefore, in order to use IPv6 effectively, it must be guarranteed that MAC
+addresses are unique on the network.
+
+In contrast to IPv4 Link-Local Addressing, IPv6 Stateless Address
+Autoconfiguration can also be used with a central server. In this case, a
+central server broadcasts \term{Router Solicitation} messages on the network
+which contain a global network prefix. The hosts on the network can then use
+that prefix instead to configure a global IPv6 address.
+
+% vim: set ft=tex et ts=2 sw=2 :
--- /dev/null
+\section{System Architecture of ``Chatty Things''}
+\todo
+\pages{3}
+\subsection{Service Provisioning Sublayer}
+\subsection{Bootstrapping}
+\subsection{Presence Subscription}
+
--- /dev/null
+\subsection{Extensions to the Domain Name System}\label{sec:dns}
+
+In a distributed context, it is often not feasible to rely on a central,
+authoritative DNS server, and there is usually no easy way to discover services.
+The first problem is addressed with \term{Multicast DNS}, and since DNS is
+basically a key-value store, it can also be used for service discovery, which is
+achieved using \term{DNS-Based Service Discovery}. Both techniques were first
+developed by Apple as part of the \term{Bonjour} project, and are now maintained
+by the IETF Zeroconf working group.
+
+\subsubsection{Multicast DNS}
+
+\term{Multicast DNS}~\cite{rfc6762} (mDNS) describes an extension to the Domain
+Name System that allows DNS resource records to be distributed on multiple hosts
+in a network, therefore avoiding central authorities and enabling every host to
+publish its own entries. For that purpose, a special domain, usually
+named \code{.local}, is used.
+
+Software that supports mDNS listens on the reserved
+link-local multicast address \code{224.0.0.251} (for IPv4 queries) or
+\code{FF02::FB} (for IPv6 queries) on UDP port 5353 for incoming queries.
+Queries sent to those multicast address and port are standard DNS queries.
+If a host receives a query and knows about the queried resource, it responds to the
+querying host with a standard DNS response. The querying host can then simply
+finish and use the result, or wait until other hosts respond to its query. The
+latter is typically the case when a record can have multiple values, as it is
+the case with \code{SRV} and \code{PTR} records.
+
+Another feature of Multicast DNS is the reduction of traffic through
+\term{Known-Answer Suppression}. It allows a querying host to specify already
+known resources in its query when querying resources that could exist on more
+than one host (e.~g., SRV records). The hosts matching those resources then do
+not generate a response.
+
+Finally, hosts may also send unsolicited responses. This can be used to notify
+the network of new services available on a host.
+
+\pages{1}
+
+\subsubsection{DNS-Based Service Discovery}\label{sec:dnssd}
+
+As another recent extension for the Domain Name System, \term{DNS-Based Service
+Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of types
+\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}[top]
+ \centering
+ \includegraphics[width=0.9\textwidth]{fig-dnssd-mock.jpg}
+ \caption{DNS-SD: Service Instance Enumeration and Resolution
+ \todo[XMPP is a bad example here, use IPP]}
+ \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}, by querying for
+\code{\_ipp.\_tcp.\_example.org}, all printers supporting the IPP protocol 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 IPP server is running at host \code{gutenberg.example.org} on port 5222.
+Additionally, an optional \code{TXT} record with the same instance name can
+contain further information about the service (e.~g., information about the
+supported paper sizes).
+
+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 :
--- /dev/null
+\subsection{XMPP}
+\todo
+\pages{3-4}
+
+The \term{Extensible Messaging and Presence Protocol (XMPP)} is a distributed,
+XML-based protocol for real-time communication. Its core functionalities are
+specified in RFCs~6120~\cite{rfc6120} and RFC~6122~\cite{rfc6121}, while protocol
+extensions are usually defined by the XMPP community in \term{XMPP Extension
+Proposals (XEPs)}.
+
+\subsubsection{Addressing}
+
+Every user account in XMPP is addressed by a globally unique identifier, called
+the \term{Jabber ID (JID)}~\cite{rfc6122}. It has the form
+\code{localpart@domainpart/resource}, where \code{domainpart} is the DNS name of
+an XMPP server, and \code{localpart} is the name of a user account on that
+server. Since a user can be logged in from multiple clients, the \code{resource}
+part is a string chosen by the user to distinguish those clients. Only the part
+\code{localpart@domainpart} (the \term{bare JID}) is needed to identify a user,
+the resource is only needed for routing between client and server.
+
+\subsubsection{Architecture}
+\begin{wrapfigure}{r}{0.4\textwidth}
+%\begin{figure}[htop]
+ \centering
+ \includegraphics[width=0.4\textwidth]{fig-xmpp-architecture-mock.jpg}
+ \caption{XMPP architecture}
+ \label{fig:xmpparch}
+%\end{figure}
+\end{wrapfigure}
+
+The original architecture underlying XMPP strongly leans on the established
+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
+server then routes the messages to their recipients, using the JID to determine
+the correct server for a message to be sent to. Finally, the receiving server
+sends the message to a client where the receiving JID is logged in. If the user
+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.
+
+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, Presence and the Roster}
+
+\cite{xep-0060}
+
+
+\cite{rfc6121}
+
+\subsubsection{XMPP Serverless Messaging}
+\todo
+
+To overcome the need for a central server and authentication, XMPP Serverless
+Messaging~\cite{xep-0174} allows XMPP clients on a network to build a
+peer-to-peer mesh network and chat directly with each other. This feature was
+first introduced by Apple as part of their \term{Bonjour} project, and nowadays
+it is also available in many other XMPP clients.
+
+With XMPP Serverless Messaging, XMPP clients simply open a port on the host, and
+then rely on mDNS and DNS-SD (see Section~\ref{sec:dns})
+to publish instance names in the domain \code{\_presence.\_tcp.local}. For
+example, if Juliet uses her machine (named \code{capulet}) with serverless
+messaging, her client would publish the following four mDNS records:
+
+\begin{itemize}
+ \item an A record \code{capulet.local}, specifying her IP address,
+ \item an SRV record \code{juliet@capulet.\_presence.\_tcp.local}, specifying
+ the port on which her XMPP client listens, and refering to
+ \code{capulet.local} as the host name
+ \item a PTR record \code{\_presence.\_tcp.local} for service discovery,
+ pointing to \code{juliet@capulet.\_presence.\_tcp.local}
+ \item and a TXT record \code{juliet@capulet.\_presence.\_tcp.local} specifying
+ more information about her (e.~g. her online status, contact data, etc.)
+\end{itemize}
+
+When other clients in the same network enumerate the available services by
+querying \code{\_presence.\_tcp.local}, they notice Juliet's presence and add
+her to the roster automatically. In that way, XMPP users can see who is
+currently available for communication. To start a chat session, clients initiate
+a TCP connection over the advertised ports, open their XML streams, and send
+message or IQ stanzas like they would to an XMPP server. Presence is managed
+over the corresponding TXT record in the mDNS. To go offline, a client
+announces the deletion of its mDNS records.
+
+\pages{1}
+
+% vim: set ft=tex et ts=2 sw=2 :
+++ /dev/null
-\subsection{XMPP}
-\todo
-\pages{3-4}
-
-The \term{Extensible Messaging and Presence Protocol (XMPP)} is a distributed,
-XML-based protocol for real-time communication. Its core functionalities are
-specified in RFCs~6120~\cite{rfc6120} and RFC~6122~\cite{rfc6121}, while protocol
-extensions are usually defined by the XMPP community in \term{XMPP Extension
-Proposals (XEPs)}.
-
-\subsubsection{Addressing}
-
-Every user account in XMPP is addressed by a globally unique identifier, called
-the \term{Jabber ID (JID)}~\cite{rfc6122}. It has the form
-\code{localpart@domainpart/resource}, where \code{domainpart} is the DNS name of
-an XMPP server, and \code{localpart} is the name of a user account on that
-server. Since a user can be logged in from multiple clients, the \code{resource}
-part is a string chosen by the user to distinguish those clients. Only the part
-\code{localpart@domainpart} (the \term{bare JID}) is needed to identify a user,
-the resource is only needed for routing between client and server.
-
-\subsubsection{Architecture}
-\begin{wrapfigure}{r}{0.4\textwidth}
-%\begin{figure}[htop]
- \centering
- \includegraphics[width=0.4\textwidth]{xmpp-architecture-mock.jpg}
- \caption{XMPP architecture}
- \label{fig:xmpparch}
-%\end{figure}
-\end{wrapfigure}
-
-The original architecture underlying XMPP strongly leans on the established
-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
-server then routes the messages to their recipients, using the JID to determine
-the correct server for a message to be sent to. Finally, the receiving server
-sends the message to a client where the receiving JID is logged in. If the user
-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.
-
-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, Presence and the Roster}
-
-\cite{xep-0060}
-
-
-\cite{rfc6121}
-
-\subsubsection{XMPP Serverless Messaging}
-\todo
-
-To overcome the need for a central server and authentication, XMPP Serverless
-Messaging~\cite{xep-0174} allows XMPP clients on a network to build a
-peer-to-peer mesh network and chat directly with each other. This feature was
-first introduced by Apple as part of their \term{Bonjour} project, and nowadays
-it is also available in many other XMPP clients.
-
-With XMPP Serverless Messaging, XMPP clients simply open a port on the host, and
-then rely on mDNS and DNS-SD (see Section~\ref{sec:dns})
-to publish instance names in the domain \code{\_presence.\_tcp.local}. For
-example, if Juliet uses her machine (named \code{capulet}) with serverless
-messaging, her client would publish the following four mDNS records:
-
-\begin{itemize}
- \item an A record \code{capulet.local}, specifying her IP address,
- \item an SRV record \code{juliet@capulet.\_presence.\_tcp.local}, specifying
- the port on which her XMPP client listens, and refering to
- \code{capulet.local} as the host name
- \item a PTR record \code{\_presence.\_tcp.local} for service discovery,
- pointing to \code{juliet@capulet.\_presence.\_tcp.local}
- \item and a TXT record \code{juliet@capulet.\_presence.\_tcp.local} specifying
- more information about her (e.~g. her online status, contact data, etc.)
-\end{itemize}
-
-When other clients in the same network enumerate the available services by
-querying \code{\_presence.\_tcp.local}, they notice Juliet's presence and add
-her to the roster automatically. In that way, XMPP users can see who is
-currently available for communication. To start a chat session, clients initiate
-a TCP connection over the advertised ports, open their XML streams, and send
-message or IQ stanzas like they would to an XMPP server. Presence is managed
-over the corresponding TXT record in the mDNS. To go offline, a client
-announces the deletion of its mDNS records.
-
-\pages{1}
-
-% vim: set ft=tex et ts=2 sw=2 :
projects / skm-ma-ws1314.git / commitdiff
