X-Git-Url: http://git.rohieb.name/skm-ma-ws1314.git/blobdiff_plain/a937e7aa8fcc17fb98a80bd0a9362d11b188087f..747e9d2a6f3468676b5e60d20e488e9a7891b06d:/xmpp.tex diff --git a/xmpp.tex b/xmpp.tex index 56ed185..7bef910 100644 --- a/xmpp.tex +++ b/xmpp.tex @@ -1,20 +1,121 @@ \subsection{XMPP} \todo -\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} - \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{} tag. The server then responds also with +an opening \code{} 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{} 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 -\cite{xep-0174} \pages{1} + +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 :