+++ /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 / blobdiff