X-Git-Url: https://git.rohieb.name/skm-ma-ws1314.git/blobdiff_plain/a1c81dce7c7d4e3a0e6e1f446eaeb893845fd680..refs/heads/reviews:/sec-xmpp.tex?ds=sidebyside
diff --git a/sec-xmpp.tex b/sec-xmpp.tex
index 451a317..213f3c2 100644
--- a/sec-xmpp.tex
+++ b/sec-xmpp.tex
@@ -1,40 +1,56 @@
\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
+specified in RFC~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}
+\enlargethispage{2\baselineskip}
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.
+\code{localpart@domain/resource}, where \code{domain} 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 at the same time, the
+\code{resource} part is a string chosen by the user to distinguish those
+clients. Only the part \code{localpart@domain} (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]
+\begin{wrapfigure}{r}{0.5\textwidth}
+ \tikzstyle{iconlabel}=[text width=3cm, align=center, font=\footnotesize]
+ \tikzstyle{label}=[font=\footnotesize]
+ \begin{tikzpicture}[node distance=0pt,scale=1.5,>=stealth,thick]
+ \def\nodelist{
+ juliet/{(-1,-1)}/XMPP client \code{juliet@example.net}/below/computer,
+ examplenet/{(-1,1)}/XMPP server \code{example.net}/above/server,
+ imexampleorg/{(1,1)}/XMPP server \code{im.example.org}/above/server,
+ romeo/{(1,-1)}/XMPP client \code{romeo@im.example.org}/below/computer%
+ }
+ \foreach \name/\pos/\text/\tpos/\icon in \nodelist {
+ \node (\name) at \pos { \includegraphics[width=1cm]{icon-\icon.pdf} };
+ \node[\tpos=of \name,iconlabel] (\name text) { \text };
+ }
+ \draw[<->,dashed] (juliet) -- node[anchor=east,label]{s2c} (examplenet);
+ \draw[<->] (examplenet) -- node[anchor=south,label]{s2s} (imexampleorg);
+ \draw[<->,dashed] (imexampleorg) -- node[anchor=west,label]{s2c} (romeo);
+ \end{tikzpicture}
\centering
- \includegraphics[width=0.4\textwidth]{fig-xmpp-architecture-mock.jpg}
- \caption{XMPP architecture}
+ \caption{XMPP architecture, showing server-to-server (s2s) and
+ server-to-client (s2c) connections}
\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.
+up the always-on backbone of the network used for message routing, and which
+manage user accounts and statuses. On the other hand, \term{XMPP clients}
+represent a single logged-in user and make up 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
@@ -53,9 +69,9 @@ manages the users for the domain \code{example.org} is given by the SRV record
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.
+is always well-formed as a whole; it consists of a root element, which in most
+cases 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
@@ -63,48 +79,94 @@ 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
+connection is closed by one side by sending a closing \code{} tag. The
+other side then has the chance to send all outstanding stanzas and then likewise
closes its stream. If both streams are closed, the underlying TCP connection is
terminated.
-\todo[Example stream]
+\subsubsection{Publish/Subscribe and Presence}
-\subsubsection{Multi-User Chats}
+Typically, a user wants to chat with a more or less fixed set of other users,
+whose JIDs she needs to know, so she needs some kind of ``address book'' that
+remembers the JIDs for her. In XMPP, this address book is called
+\term{roster}, and it also shows the users' willingness to chat (``presence'').
+In order to see their chat status (which can be one of ``online'', ``offline'',
+and several ``away'' or ``do not disturb'' states), a user needs to subscribe to
+the other user's status. The mechanism behind this is called
+\term{Publish-Subscribe} and is specified in XEP-0060~\cite{xep0060}. It can
+be used to notify interested users about changes in personal information, and
+implements the well-known Observer pattern~\cite{GOF95}.
-\cite{xep-0045}
+A user publishes information by creating a \term{node} on the XMPP server, which
+acts as a handle for the data. Interested users can then query the server for
+nodes, and request subscription to them. When the owner of the node confirms the
+subscription request, subscribers get notified whenever the owner updates the
+respective node.
-\subsubsection{Publish/Subscribe, Presence and the Roster}
+All communication takes place between the client and the server over \code{}
+(``information query'') stanzas.
-\cite{xep-0060}
+\subsubsection{Multi-User Chats}
+Besides one-to-one messaging, XMPP also allows users to create multi-user chat
+rooms, which is specified in XEP-0045~\cite{xep0045}. Each chat room is given a
+unique JID on the server managing the room to which the users send their
+messages to. Each incoming message is then dispatched to all users which have
+joined the room.
-\cite{rfc6121}
+To join a room, the user sends a \code{} stanza to the room JID, where
+the resource part of the room JID specifies the desired nick name.
-\subsubsection{XMPP Serverless Messaging}
-\todo
+\subsubsection{XMPP Serverless Messaging}\label{sec:xsm}
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
+Messaging~\cite{xep0174} 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{wrapfigure}{R}{0.4\textwidth}
+ %\tikzstyle{iconlabel}=[text width=2cm, align=center, font=\footnotesize]
+ %\tikzstyle{label}=[font=\footnotesize]
+ %\begin{tikzpicture}[node distance=0pt,scale=1.2,>=stealth,thick]
+ %\def\nodelist{
+ %juliet/{(-1,-1)}/\code{juliet@\ balcony.local}/below/computer,
+ %tybalt/{(-1,1)}/\code{tybalt@\ montague.local}/above/computer,
+ %mercutio/{(1,1)}/\code{mercutio@\ capulet.local}/above/computer,
+ %romeo/{(1,-1)}/\code{romeo@\ romeo.local}/below/computer%
+ %}
+ %\foreach \name/\pos/\text/\tpos/\icon in \nodelist {
+ %\node (\name) at \pos { \includegraphics[width=1cm]{icon-\icon.pdf} };
+ %\node[\tpos=of \name,iconlabel] (\name text) { \text };
+ %}
+ %\draw[<->,dashed] (juliet) -- (tybalt);
+ %\draw[<->,dashed] (juliet) -- (romeo);
+ %\draw[<->,dashed] (juliet) -- (mercutio);
+ %\draw[<->,dashed] (romeo) -- (mercutio);
+ %\draw[<->,dashed] (romeo) -- (tybalt);
+ %\draw[<->,dashed] (mercutio) -- (tybalt);
+ %\end{tikzpicture}
+ %\centering
+ %\caption{XMPP architecture with Serverless Messaging}
+ %\label{fig:xmpparch2}
+%\end{wrapfigure}
+
+With XMPP Serverless Messaging, XMPP clients simply open a port on their 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
+ the port on which her XMPP client listens, and referring 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.)
+ more information about her (e.~g. her online status, contact data, etc.) in
+ standardized key-value pairs.
\end{itemize}
When other clients in the same network enumerate the available services by
@@ -116,6 +178,4 @@ 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 :