\subsubsection{Architecture}
\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,
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=1.2cm]{icon-\icon.pdf} };
+ \node (\name) at \pos { \includegraphics[width=1cm]{icon-\icon.pdf} };
\node[\tpos=of \name,iconlabel] (\name text) { \text };
}
- \draw[<->,dashed] (juliet) -- node[anchor=east]{s2c} (examplenet);
- \draw[<->] (examplenet) -- node[anchor=south]{s2s} (imexampleorg);
- \draw[<->,dashed] (imexampleorg) -- node[anchor=west]{s2c} (romeo);
+ \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
\caption{XMPP architecture, showing server-to-server (s2s) and
- server-to-client (s2c, dashed) connection types}
+ server-to-client (s2c) connections}
\label{fig:xmpparch}
\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
+up the always-on backbone of the network used for message routing, 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.
+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
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
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
+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.
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 classic Observer pattern.
+implements the well-known Observer pattern.
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
\subsubsection{Multi-User Chats}
-Besides one-to-one messaging, XMPP also allows users to create multi-user
-chat rooms, which is specified in \cite{xep0045}. Each chat room is given a
+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 to which the users send their messages to. Each incoming message is
then dispatched to all users which have joined the room.
To overcome the need for a central server and authentication, XMPP Serverless
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.
+first introduced by Apple as part of their \term{Bonjour}\footnote{see
+\url{https://developer.apple.com/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})
\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
projects / skm-ma-ws1314.git / blobdiff